In programming, however, the mouse can be one of the greatest productivity sinkholes. Time is wasted each time you lift your hand from the keyboard to grab the mouse, and more time is wasted when you move your hand back to home row in preparation for more typing.

So what’s the solution? Keep your hands on the keyboard! To do this use the SlickEdit^® command line and bind commonly used commands to keys.

Launching Operations
SlickEdit provides three ways to launch operations: key bindings, commands, and menus. OK, there are actually four, if you include icons. Since the focus of this article is how to keep your hands on the keyboard, I was going to skip that one.

Key Bindings
Key bindings are the fastest way to launch an operation. They can be pressed at any time while editing. A key binding associates a key sequence with a command. A key sequence is a series of key strokes. Anything you do frequently should be bound to an easily remembered key sequence.

For example the key sequence Ctrl+A means hold down the Control key, typically labeled “Ctrl” on most keyboards, and press the A key. The letter A is represented as an uppercase letter, but this does not mean that you are to press the Shift key. If you are supposed to press the Shift key, the sequence will be written as Ctrl+Shift+A.  We use the uppercase A to match the letter on the keyboard.

Commands
Commands are useful for less frequently used operations or operations that take arguments. They are executed from the SlickEdit command line and are nearly as fast as key bindings. Press the Escape key (in most emulations) to activate the command line, which is displayed at the bottom of the SlickEdit application window. 

  Figure 1, SlickEdit with Command Line

It offers a full command history and completions for command names and arguments. Use the arrow keys or the mouse to scroll through previous commands. As you type, a list of possible completions is displayed. Use the arrow keys or mouse to select a completion. SlickEdit stores recorded macros as commands. You can also use Slick-C to write new commands. Use the _command keyword to identify a macro as a command. Any command can be bound to a key sequence for faster launching. 

Menus
Menus are accessed via the mouse or a keyboard shortcut. Menus are great for infrequently used items that may not be worth a key binding. They are also helpful to learn about new capabilities. But if you use an operation frequently, you will be more productive by binding it to a key sequence or launching it from the command line. Many menus list a keyboard shortcut to launch the operation. This is just the key binding for the associated command. So when you use a keyboard shortcut, you are really just using a key binding.

You can also operate the main menu through hotkeys. Enable the use of hotkeys by selecting Tools > Options > General, selecting the General tab, and putting a check in “Alt menu hotkeys”. This will be selected by default in many emulations. Once enabled, pressing the Alt key will display an underscore beneath each menu option, indicating the letter to press to activate that option. This is not as fast as key bindings, but it does keep your hands on the keyboard and is much faster than using the mouse. In some cases the menu hot key sequence is a good mnemonic for the command. For example, Alt+P, E (to bring up Project > Properties) may be easier to remember and type than binding project-edit to Ctrl plus some function key. 

Icons
SlickEdit presents icons in a series of toolbars related to different tasks. Toolbars can be customized with an extensive set of additional icons. Icons are useful for die-hard mouse users or for setting up infrequently used operations for which you have a hard time remembering the associated command or key binding. 

The Golden Triangle
The three methods (excluding icons) to launch an operation are related, forming the Golden Triangle of operation launching. If you know how to execute an operation with one of these, you can easily configure SlickEdit to launch the operation using the other two methods. Commands form the base for the other two…which is why it is shown as the apex of the triangle (Damn it, Jim, I’m an engineer, not an artist!). Maybe I should have used a Golden U or something. 
 

Figure 2 the Golden Triangle; behold its majesty!

From Key Binding to Command
Sometimes you may want to change the key sequence to which an operation is bound. You first need to find the command associated with that key sequence. Use the what-is command from the SlickEdit command line or select Help > What Is Key from the main menu. The command line will be replaced with the prompt, “What is key:” Enter the key sequence in question, like Ctrl+A (hold down the Control key and press A), and SlickEdit displays the associated command. In CUA emulation, SlickEdit will output, “Ctrl+A runs the command select-all”. You can use the same approach to determine the commands associated with mouse events. After you run what-is, click any mouse button and you will be prompted with a list of mouse events. Select one from the list and SlickEdit displays the associated command. For example, if you select mbutton-down in CUA emulation, SlickEdit will output, “MButtonDn runs the command mou-paste”. 

From Command to Key Binding
To find the key binding for a command, use the where-is command or select Tools > Options > Key Bindings from the main menu. The where-is command works just like what-is, except you type in the command name and it outputs the key sequence. The Key Bindings dialog displays a list of the commands. You can scroll through the list or search for a command by typing the command in the text box at the top. The key binding for the selected command is displayed in the dialog.  

Figure 3, Key Bindings Dialog   

Modifying Key Bindings
The Key Bindings dialog can also be used to set a key binding. Type the command in the Command field, or select one from the list. Then click the “Add Key or Mouse Click” button. Now type the key sequence you want to use. For example, to bind a command to Ctrl+A, hold down the Control key and press A. To bind a command to a mouse event, click any mouse button and then select the appropriate event from the list. When you are finished, click the Bind button. To exit the dialog, click Done.

From Menu to Command
If the menu entry displays a keyboard shortcut, you can quickly find the associated command using what-is and entering the key sequence. If the menu entry does not display a shortcut, then finding the command for an entry involves a little more work.

SlickEdit provides a convenient UI under Macro > Menus that allows you to view and modify menus in SlickEdit. To find commands for the items on the main menu, select “_mdi_menu” from the list and then click the Open button. You are presented with a menu hierarchy that you can expand to find the menu entry in question. Once selected, information about the entry is displayed including the command executed. You can use this menu to add or change the shortcut for a menu item. Doing so has the same effect as using the Key Bindings dialog to bind the menu entry’s command to a key sequence.   

Figure 4, Menu Editor

Some menu entries are added dynamically by SlickEdit, so you may have to search the code to find the associated command. One example of this is Build > Java Options, which is only present when a Java project is active. Unfortunately, finding the associated commands for these entries can be very difficult and not easily covered in an article like this.

Context Menus
It is also easy to find the commands in the context menu for the editor window. The context menu, itself, contains an entry to “Edit This Menu”. Selecting this option brings up a dialog that lists the menu entries and associated information, including the command. Use this dialog to modify the context menus. Note that there are two context menus for the editor window: one when a selection is made and one when no selection is made. You can view or change the function that is used for these menus by selecting Tools > Options > File Extension Setup and selecting the Advanced tab.

From Key Binding to Menu and Back
Menu entries map to key bindings through commands, so key bindings are not directly associated with menu entries. To map from a key binding to a menu or vice versa, you need to look up the associated command. That Golden U is looking better all the time!

Customizing Toolbar Icons
The focus of this article has been to help you keep your hands on the keyboard, so icons weren’t included in the Golden Triangle. Besides, then I would have needed a Golden Square or some other form of rhombus, and that just doesn’t sound cool. You may find it helpful to change the set of displayed toolbars, add or remove icons, or change the behavior for an icon. SlickEdit uses the term “toolbar” to refer to both icon bars and tool windows. To change the set of displayed toolbars, select View > Toolbars and check/uncheck one of the listed toolbars.

The list is divided into two groups. The top group is comprised of tool windows, like the Symbol view and the Projects view. The bottom group is made up of icon bars.

Additional options are available on the Toolbar Customization dialog by selecting View > Toolbars > Customize. The Toolbars tab provides a way to control the visibility of the toolbars. The Toolbars tab allows you to set options for which toolbars are visible, whether they are dockable, etc.

The Categories tab displays the complete set of available icons. These can be added to any icon toolbar by dragging them to the desired location. All of the icons have pre-defined behaviors, except the set in the “User Definable Tools” category. Use these to add your own functionality.

Each icon has an associated command that defines what happens when it is clicked. To view or change that command, right-click on the icon and select Properties. The icon needs to be located in a toolbar to do this. You cannot access the properties for an icon in the Toolbar Customizations dialog.  

“Exit, Stage Left”
OK, that one is a Snagglepuss reference[ii]. Whatever angst I previously expressed for mice has now been transferred to the Golden Polygon of Unspecified Dimensions. Regardless of the shape, you now have the tools you need to configure SlickEdit to work the way YOU think it should, using the key bindings you find natural. This is one of the essential steps in being a true power programmer.
 

[i] Mr. Jinks, sometimes called “Jinks the cat”, appeared in the “Pixie and Dixie” cartoons as part of “The Huckleberry Hound Show”, by Hanna and Barbera.

[ii] Snagglepus is another of Hanna-Barbera’s cartoon characters.

Sometimes when you have a project with a large number of makefiles, you may notice that menus are slow to respond. This happens because SlickEdit collects the names of all the targets in each makefile and adds them to menus for build purposes (whether or not you are using SlickEdit to build). To resolve this issue, change the def_show_makefile_target_menu configuration variable to either 0 or 2. The default value, 1, specifies that all makefile submenus are enabled. A value of 0 disables all makefile submenus (Build menu and Project tool window), and a value of 2 enables makefile submenus only in the Project tool window (Build menu makefile targets are disabled).

To change the value of a configuration variable, from the main menu, click Macro > Set Macro Variable. Select the variable to change from the drop-down list, enter the value in the Value field, then click OK.

NOTE This behavior will be changed in the next release so that despite the number of makefiles in your project, there will not be a slow-down in menu response times.

If you’re constantly opening files from certain directories, create aliases for those directories to save time. To create a directory alias, from the main menu, click Tools > Options, expand Editing and select Global Aliases. Click New, enter a short text snippet that you can easily remember for the Alias Name, then click OK. Back on the Options dialog, select the new alias, then enter the complete directory path for the alias in the text box on the right.  Click OK on the Options dialog. Now you can use the alias in directory fields on various dialogs in SlickEdit (like File > Open): simply type the Alias Name and press Ctrl+Space to expand it.

Language-Specific Aliases

Language-specific aliases are similar to directory aliases except they can be used in edit windows for any frequently used text, like comment headers and language structures.

To create a language-specific alias, from the main menu, click Tools > Options > Languages, expand your language category and language, then select Aliases. On the Alias option page, click New and enter a short text snippet that you can easily remember for the alias name, then click OK. Back on the Options dialog, select the new alias, then enter the text substitution for the alias in the text box on the right. Click OK on the Options dialog.

Now when you have a buffer or file open in that language, you can use the alias by typing the identifier and pressing Ctrl+Space.

Alias from Selection

A quick way to create a language-specific alias is to create it from a selection. Select some text in the editor, then right-click and select Create Alias from the context menu. Enter a name for the alias and click OK. The Options dialog appears, open to the Language-Specific Alias Options for the current language, and showing the new alias. Click OK on the Options dialog.

In the article he discussing some of his favorite features of SlickEdit and why SlickEdit is his code editor of choice for programming.

On objections on switching editors

If your current editor works well enough for you, why switch? The answer depends on how you define “well enough.” Your current editor probably handles every editing command you think you need now, but consider the possibility that something could make you far more productive. You’ll see a few examples in a moment, but first, here are some of the reasons you might decide not to switch editors.

Regular Expression Search and Replace

This isn’t an exclusive SlickEdit feature, some other editors have it too; but if you haven’t had the opportunity to experience regular expression searches, you should really consider switching to an editor that supports the feature.

Macro Record/Playback

SlickEdit carries out many of its commands through its slick-C programming language (note that both Brief and Emacs have their own languages as well). SlickEdit lets you write your own macros, or do a simple record / playback. This comes in handy when the syntax for find and replace gets too dicey.

Other Features

As you might imagine, because SlickEdit’s been around for 20 years, this article just scratches the surface.

Continue reading Hey, Check Out My Slick New Editor! here: http://www.devx.com/enterprise/Article/42874/0/page/1

SlickEdit’s Slick-C macro language should be no stranger to our users, but many folks aren’t aware that macros can be called when SlickEdit is started. In this tutorial, I’ll demonstrate how to use Automator to create a simple text service for SlickEdit, using this macro call facility.

First, launch the Automator application and create a new service using the Service template. At the top of the new workflow, it should say Service receives selected text in any application. Make sure Replaces selected text is not checked.

From the library’s actions panel, select the Text > New Text File action, and drag it into the workflow as the first item. Pick a name and location for the temporary file to be saved, and make sure Replace existing files is checked, or else you’ll receive an Automator error the second time you use the service. Select the Encoding to be (UTF-8).

From the library’s action panel, select the Utilities > Run Shell Script action, and drag it into workflow as the second item. The shell should be set to the default of /bin/bash. Change the right-hand drop-down to read Pass input as arguments.

Delete any existing text in the shell script editor. Add the following text as the first line.

export VSLICKXNOPLUSNEWMSG="1"

Switch to Finder, and navigate to the Applications directory. Highlight your SlickEdit application, and Control-Click the application, and select Show Package Contents from the context menu. Drill down to the Contents/slickedit/bin, highlight the vs executable, and drag this into the shell script editor. This will insert the full path to the executable in the script editor. Make sure it’s on a new line after the export line you just typed.
Append the following right after vs, making sure the command is all one line.

-#new-file "-#get $1"&

The full script should look like the following:

export VSLICKXNOPLUSNEWMSG="1"
/Applications/SlickEditV1402.app/Contents/slickedit/bin/vs -#new-file "-#get $1"&

Automator Service

Don’t forget the ampersand at the end of the second line. Save the service, (⌘+S), and give it the name “New SlickEdit File”.

Switch to another application, like Safari or TextEdit, highlight some text, and pull down the application’s services menu. Your new service should now be available in the menu in the Text category.

The SlickEdit “magic” is done with the -# arguments. These specify macros to be called when SlickEdit in invoked. Any SlickEdit macro command (defined with the _command keyword in Slick-C) can be called. Surround the entire -# argument with quotes if the Slick-C command takes any parameters, like the get macro in this example.

You can create a similar service that will insert the text into the currently active document by simply removing the -#new-file argument.

By default, service workflows are saved under $HOME/Library/Services. You can remove the service by removing this file.

To rename a Service, select the workflow file under $HOME/Library/Services, Control-Click to bring up the context menu, and select Show Package Contents. Look for the Contents/Info.plist file, and open it in the Property List Editor application. Change the value of the Services/Item/Menu/Menu item title entry. You do not need to rename the workflow file itself.

Boy: Mr. Turtle, how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
Mr. Turtle: I’ve never even made it without biting. Ask Mr. Owl.
Boy: Mr. Owl, how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
Mr. Owl: Let’s find out. A One… A two-HOO…A three.
(crunch sound effect)
Mr. Owl: Three!

This illustrates two common problems in oral communication. The first is the iterative process of finding someone who might know the answer to your question. In software development, the questions are typically of a more concrete nature, relating to a specific design or implementation choice.

Most software projects depend on a great deal of local knowledge. This is knowledge that is specific to the project, something you couldn’t know prior to working on the project. This include things like architectural and design details. The local knowledge is rarely written down in an organized manner but is contained in the collective experience of the development team. Because it isn’t written down and cataloged it cannot be searched, except through the iterative query process.

The other problem that this commercial illustrates is that of false experts. Like Mr. Owl, you will find people who will give you a definitive answer but one that is, unfortunately, wrong. In software development, it can be very difficult to spot these wrong answers–you don’t get to see someone just bite into the Tootsie Pop to come up with it.

In some cases, the person may truly believe the answer they give, and we’ll assume that until we have proof to the contrary. At other times, people just don’t like to admit that they don’t know something. So, they make up an answer. In either case, the damage to your work is just as bad.

Folklore is typified by this kind of oral communication. It is the main method for communicating important information in primitive cultures. Knowledge is passed from one person to another. Often, because of miscommunication, the knowledge is corrupted by each successive telling.

It’s like that party game where you start off with a sentence and have each person whisper it to another person. This is repeated several times and then the last person writes down the sentence. In the end, the meaning of the sentence is often radically changed with comical results. The same thing happens in software development, but the results are far less comical.

The solution to both of these problems is to document local knowledge. One form of that is code comments. So much has been written on that topic, that I don’t feel the need to add more. However, many things are not appropriate to store in code comments. It’s that kind of knowledge that is most often passed along as folklore.

Fortunately, technology has given us a solution. A wiki provides a centralized knowledge repository that is edited by the group. This allows for the information to be easily reviewed for accuracy. It also eliminates the need to wander around and find someone who might know the answer to your question.

It also addresses another problem. Many people are hesitant to go ask questions. Either they are afraid of looking stupid, or they don’t want to trouble their coworkers. So, they will often flounder around trying to figure it out on their own, wasting time, or they will try to make due without the answer. A wiki allows people to find an answer without the potential embarrassment of exposing their ignorance.

To be successful, a wiki needs to be searchable and browseable. The search capability is needed to find the answer to specific questions. Browseability allows someone to view a set of topics and delve deeper to get more information. This is important to allow someone to gain the initial knowledge on a topic, particularly for getting new team members up to speed. Most packages do a good job providing the search capability. But very few provide a good mechanism to build a browseable knowledge structure.

At SlickEdit, we use MediaWiki for our shared knowledge. It provides both an excellent search and a convenient means to organize topics. The side menu allows you to structure your top-level categories, and each page automatically includes a table of contents if it contains 4 or more subsections. This makes it simple to build a logical knowledge decomposition. It’s this capability to create a browseable structure that sets MediaWiki apart from other wiki software we tried.

Finding the right wiki software and setting up an initial structure is only the first step, though. The main challenge is getting the team to populate it. You face a couple of common problems here.

The first is the normal reluctance of programmers to document things. Many programmers despise any activity that is not directly related to producing code. This is a tough nut to crack, since this attitude is often deeply ingrained in the developers psyche. How you overcome this depends on the person and the arguments that they will listen to. You can appeal to their sense of professionalism and explain that this is part of professional development. You can appeal to their sense of teamwork and explain how this helps make the team more effective. You will need your full set of management skills to get everyone contributing.

Even if everyone is willing to contribute, one problem that often prevents a wiki from reaching its true potential is that of obviousness. Once you know something, it seems obvious to you. If it’s obvious, then why document it? This same problem plagues code comments. The best solution is to make the wiki an essential part of the problem solving process. When someone is trying to answer a question, they should look in the wiki. If they don’t find the answer, they should make a note to come back and add this information to the wiki after folklore has delivered an answer.

So, how does having a wiki alter the scenario depicted in the commercial?
Boy: Hmm, I wonder how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
(Boy looks in wiki for the answer and finds an entry by Mr. Owl: “How many licks does it take to get to the Tootsie Roll center of a Tootsie Pop? Three.”)

Well, at least he didn’t have to go bother curmudgeonly, old Mr. Turtle.

In terms of economic stimulus, this could have a much greater effect on the nation. Consider that many programmers use minimalist editors that provide little help to analyze and navigate their code, don’t include powerful completions, or features to cut the number of keystrokes necessary to type their code. If these programmers switched to a more powerful editor, like…oh, let’s say, SlickEdit…their productivity would go way up.

As the productivity of the individual programmers goes up, their projects would get done earlier or include more capabilities. This increases the productivity of the people using that software, which would then increase the profitability of those companies. Since software underlies almost every industry, this could lead to a potential boom, the likes of which hasn’t been seen since the post-WWII expansion. Suddenly, there’s a surge in the US GDP. We pay off the national debt in a few years and have money left over for a comprehensive public health care system.

And it all begins with getting people to switch to a more effective editor.

Unfortunately, SlickEdit isn’t big enough to warrant a special government program like this. We’re not one of those too-big-to-fail kind of companies. But that doesn’t mean you can’t experience your own little economic stimulus.

Look at your coding practices and see if a more powerful editor wouldn’t help you write more code faster with fewer errors. Though the government won’t pay you for switching, the boost in productivity surely will.

SlickEdit is Giving Cash for your Clunky Editor!
Cash for Clunky Editors Program:

If the editor you purchased is lacking the speed, power, and flexibility SlickEdit provides…trade it in for CASH towards SlickEdit.  Call 1-800-934-EDIT (3348) or email sales@slickedit.com, and mention the Cash for Clunky Editors Program to learn about the savings.

The program expires on September 30^th, 2009, so act quickly.

Happy coding,
The SlickEdit Team

The basic reason for this is that each feature was written in isolation without finding and reusing the capabilities of the other features. This is a very common problem on most software projects. To address this issue, I believe that software development should be broken down into two different workflows: mechanism application and mechanism creation.

We can define a mechanism as a component with a cohesive set of functionality, like the wheel. In most cases, mechanisms are meant to be reusable, though it is possible that there will be only one use for that mechanism in a particular program. Common mechanisms in software include login processors, calendar widgets, and sorted lists. These elements perform a specific function that is independent of what they are used for.

Mechanisms can also be specific solutions to common design problems, like error logging, object persistence, and thread synchronization. Ideally, these would be encapsulated in a library that is used by other developers, but in some instances it is more a matter of following a specified convention.

For example, one project I worked on specified that each function would contain #ifdefs for tracing and logging with specific information that each function should output. This still represents a mechanism that defines a cohesive functionality, in this case, tracing. But instead of writing a reusable library, the mechanism was primarily a set of conventions we all followed when writing our functions.

During mechanism application, the specialized functionality of a feature is built using existing mechanisms. You can work on your own unless you have a question about the specs or need assistance from another developer. The code being written is unique to the feature, so little attention is given to reuse unless a new mechanism is needed. Then you enter mechanism creation.

During mechanism creation, you are developing a generalized capability that is specifically intended to be reusable. This requires a totally different workflow. You have to stop and do a degree of analysis before you create the new mechanism. Several questions need to be answered. Are you sure there isn’t already a mechanism for this? If not, what are the essential behaviors of this mechanism? Where should it be stored?

These questions are best addressed with other members of the team. The goal is to produce a mechanism that can be used by everyone, not just by you. So, you need to get their input to make sure it does more than meet your immediate needs, or at least doesn’t prevent someone from extending it in the future.

When a developer tackles the new mechanism as part of their normal development, two common problems occur. Often the programmer includes the mechanism as part of the feature-specific code, rather than placing the mechanism into the library where others can find it. Even when they do put the code in the proper place, it often is written in such a way that it is only useful for this feature. You can’t make it reusable without breaking the feature that already depends on it.

In most applications, mechanism application is very straightforward, simple programming and requires little creativity. Mechanism creation, on the other hand, requires a great deal of creativity and design effort. You have to think more about algorithms and efficiency.

So why don’t programmers naturally break their work into these separate workflows? I think there are a number of explanations.

First, I think programmers get very focused on completing a feature. If they have to interrupt that work to enter the slower and more deliberate workflow required to create a new mechanism, then it delays the attainment of their goal.

Secondly, programmers like to program. Designing reusable components requires meetings, documentation, and reviews–all of which get in the way of programming.

Thirdly, most programmers aren’t too keen on collaboration. When you talk things over in a group, you have a chance of not getting your way. If you just build it yourself, you can do it the way you think it should be done.

Finally, by separating the two workflows, the creation of a needed mechanism might be assigned to a different programmer. Since the creation of these mechanisms is often more challenging and, therefore, more fun; developers are hesitant to initiate a workflow that would potentially deprive them of this fun.

Basically, it’s more fun to reinvent the wheel than to determine whether a suitable wheel already exists. If the wheel does need to be invented, it’s less fun to do it with a committee of your peers who may disagree with your vision for the wheel.

• The next_sexp (Ctrl+Alt+Right) and prev_sexp (Ctrl+Alt+Left) commands can be compared to next_word and prev_word, except that they treat blocks as words.
•  The backward_up_sexp (Ctrl+Alt+Up) command is the shortcut for navigating to the start of the immediately enclosing block (in Lisp, this would be the open paren).
• The forward_down_sexp (Ctrl+Alt+Down) command is used to drill into a block. If the cursor is at the start of a block, it moves the cursor to the first S-expression within the block; otherwise, it behaves like next_sexp.
• The commands select_prev_sexp (Ctrl+Alt+Shift+Left) and select_next_sexp (Ctrl+Alt+Shift+Right) extend a character selection from the cursor position to the start of the next or previous S-expression, respectively. Like the Shift+Cursor commands do to CUA style selections, if executed repeatedly, they will extend the current character selection.
•  The cut_prev_sexp (Ctrl+Alt+Backspace) command will delete the S-expression to the left of the cursor and copy it to the clipboard. Again, if called repeatedly, this will prepend the subsequent deletions to the clipboard.

SlickEdit provides an emulation mode for the Vim text editor. If you want to learn Vim, or need to hone your skills, you can use the vimtutor command. Most Vim installations come with this command, which displays a special “learn-by-doing” practice file in the editor that you can can actually edit as you learn how to use the Vim commands. This file has been customized for SlickEdit users.

To use the command, open the SlickEdit command line, then type the command and press Enter. The practice file is displayed in the editor. Each time you use the vimtutor command, SlickEdit creates a fresh copy of this file.

Tip

Slick-C is a macro programming language upon which the SlickEdit code editor is based.  Slick-C allows developers to modify the look and feel of the editor, write macros to perform custom operations, add new language support, and essentially extend the editor’s functionality until it is completely customized according to your preferences.

From his first post:

Here you’ll find Slick-C macros of all kinds, from overly simple to fairly complex. I’m a writer/editor/journalist by trade, not a professional developer. Slick-C programmers should find something 0f interest here, including plenty of code that can be tweaked or fixed.

The purpose of this blog is to address the shortage of Slick-C code on the Web, while stimulating discussion and encouraging code sharing.

I’ve used Slickedit in my daily work since approximately 1998. Currently I have 388 _command macros in my vusrmacs.e file. I’m sure there are other Slickedit users whose macro folders are wishing to burst free and benefit the larger community.

My professional roles are technical writer; editor and researcher of print and electronic publications; desktop publisher; journalist. My programming experience has generally been limited to high-level scripting languages. I’ve spent a lot of time using numerous text editors and macro languages. Of the two kinds of Slickedit users named in the subtitle of this blog, I’m a Wordsmith rather than a Code Maven.

Cast your mind back to the days of the tall ships, great wooden vessels that plied the oceans under wind power. Imagine one of those majestic ships sailing along when suddenly it hits a reef, tearing a large hole below the waterline. All hands scramble to save the ship. They bail and bail, but the ship continues to sink. As the ship sinks lower, they bail more furiously until finally the ship is lost. The survivors are washed ashore on a nearby island.

As they stare out at the masts of the ship, still visible above the waves, the Captain asks, “Why weren’t we able to plug the leak?”

One of the crew pipes up, “Captain, sir, we were too busy bailing to plug the leak.”

OK, this is a contrived example, and it’s very hard to believe that it could occur in real life. However, very similar situations frequently arise in software development.

Bad Codebase

The most typical way I’ve seen this occur is on projects where the early work has set us up for failure. The infrastructural code is so full of bugs or badly designed that it has become a stumbling block to get the rest of the system built. The team furiously pounds away at the code, driving toward a critical milestone fixing bugs as they can. But with every iteration, things take longer to do and the codebase gets harder to work with.

In this case, the leak is the poor codebase. The only way to plug the leak is to rewrite that part of the system. Often, the programming team is unable to recognize that this code is a lost cause, particularly if they participated in its development. More commonly, the programmers know that this code is the problem, but they can’t talk management into the schedule slip that is necessary to fix it. In the end, the project takes longer to complete than if we had stopped and rewritten the offending code.

Unfortunately, a leak in software is rarely as visible or as easy to appreciate as a gaping hole in a hull. However, the programmers’ work to patch the system instead of fixing it is just as futile as the sailors who just keep bailing. And the result is nearly as predictable.

Poor Process

Another way this phenomenon is manifested is in adherence to bad processes. I worked on a project that used very poor configuration management techniques. The approach to version control was sloppy, and there were no controls for how integration servers were configured or how code was deployed for testing. Consequently, even though we would get successful tests on the integration server, we continually faced problems in production. These problems stemmed from several causes. Sometimes it was because of files that were edited on the integration server and not checked into source control, so they never got deployed to production. Or someone would set up the directory structure differently so that it would work on one machine but not the other.

When these problems appeared, the proffered solution was that people should be more careful. This case might be slightly different. Instead of thinking that you’re too busy bailing to plug the leak; in this case you believe that bailing may be all that’s needed.

I’m a firm believer that your test machines should mirror your production environment in every way possible and that you should deploy your code for testing exactly as it will be deployed to the production environment. And if I ever catch someone editing a file on a test or integration server, I’ll keel haul them!

No Time for Personal Development

I also see the “too busy bailing” mentality at work in peoples’ careers. As a hiring manager, I have interviewed hundreds of candidates for jobs over the years. I’m frequently amazed to learn how little people invest in their careers and the knowledge necessary to advance.

For example, most of my work has been on Object-Oriented projects. So, I typically ask OO questions of the candidates. One question is about how they learned OO programming. What books did they read? How did they hone this knowledge? Typically, I find that most candidates learned OO in college and have done nothing to build on that knowledge, other than their normal work experience.

I’ve also interviewed candidates for web development. So, I’ll get a resume from a bright young college student who is about to graduate. They tell me they want to be a web developer.

“Great!” I say. “So, have you ever built a website?”

“No.”

“Do you know HTML and JavaScript?”

“We had that in a class once.”

“Well, then what have you done to become a web developer?”

“I’m real busy with class right now.”

So, basically, this guy is looking for someone to pay him to become a web developer. I’ll always consider a new grad without formal experience, but I want someone who has done more than just sit through classes on their way to a degree. Show me some passion or interest in your area by working on something outside of class. Or at least have knowledge in the basic tools.

Tool Selection

The final way I see people being too busy bailing is through adherence to less effective tools. I often interact with people who have been using vi their whole career, or some other minimal editor, and just can’t be bothered to change. No amount of telling them how you can save them time will convince them to switch. They may even admit that they know they could be more productive if they switched, but they don’t want to take the time to learn a new tool.

Truthfully, this could be a case of the tool becoming the job rather than being too busy bailing. In that situation, a person spends so much time, say, hammering that they lose sight of why they are hammering: to build houses. So when a new way of driving nails comes along, they stick to their current way of working. “I’ve been hammering for 20 years. I’m not about to switch.”

Switching tools will always involve an investment in time. But if you pick the right tool, that investment will pay off rapidly.

So watch for signs of bailing in your own work and career. Consider whether there is a leak that needs to be plugged first. If not, then bail for all your worth. If you have spotted a leak and no one will listen, maybe you need to do a different kind of bailing.

At this point, we’re pretty far along in the evolution of version control development. However, there’s a fundamental problem with all of these version control systems.  Even though they set out to do the pretty much the same thing, there’s no common interface to any of them.  Even worse, the interpretation of common concepts are completely different.  It’s not noticeable if you’ve only used one.  The more you use, though, the more obvious it becomes.  The only attempt at such a thing that I can recall is Microsoft’s SCC interface.  Unfortunately, it served a very specific purpose and aimed for the lowest common denominator.

If you have ever tried to switch from one version control system to another, you have suffered through this.  If you’ve ever had to port the version history from one system to another, then you likely gave up and stuck with the old system or lost all of your history.  The interoperability of version control systems is horrendous.

Standardized interpretation

Let’s start with version numbers, the ID that identifies a particular version of a file… how basic is that?  CVS has it’s own dot notation.  SVN and Team Server keep a global number that gets incremented when any file is checked in.  This difference in interpretation leads to fundamental differences in how these systems implement labeling and branching.

How could these common concepts be interpreted so differently? It means that in order to move from one version control system to another, you not only have to learn the new commands, but you must understand that system’s interpretation of what they mean.  Labeling and branching in CVS and SVN are very different, even though the basic concept is the same.  It would be nice to see some a standardization of the implementation of these concepts between version control systems.

Standardized commands

Imagine a world where databases each had their own proprietary language that was completely unrecognized by any other database.  Alright, maybe that’s not so far off from reality, but beyond PL/SQL, T-Sql and others, there’s ANSI SQL, which is the common language of all relational databases.  It theoretically (note the italics) allowed developers or DBAs to write SQL that could be understood by any database that supported ANSI SQL.  It’s the idea of polymorphism at work outside the code, creating a common interface to the functionality, yet allowing each database engine implement that functionality as they wanted.

Version control would be such a happier place if there was a common command language for it, that each version control system was required to implement. On a ground floor level, it would make the simple day-to-day operations consistent.  Update, commit, compare and revert would all be standard.  Once you learned how to use one version control system, you knew how to use ten version control systems.  Is this so hard?

Import/export standardized formats

A huge point of pain in version control is having to switch from one system to another.  It sounds crazy… who would switch version control systems at the same company?  However, it’s happened to me three times in my career.  Companies and departments merge, where both sides used different version control systems.  Sometimes your needs require a version control system with more functionality.  There are lots of reasons for switching systems.

Unfortunately, each time I’ve had to switch version control systems, it’s resulted in a complete loss of history. Therefore, there needs to be a standardized import/export format.  Many applications make use of XML as a way to import and export their data to share with other applications.  RSS is probably one of the best examples of this.  Version XML would allow you to export your version history for all files in the repository.  That history, as well as the files or deltas, could then be archived in tar or zip format into a single file.  The corresponding import functionality would be able to read this standard format and structure, and would be able to import that version history. This would completely remove the pain of having to switch from one version control system to another.

Version Query Language

Basic file check in and check out is the core of any version control system.  However, aside from being able to diff two specific versions of a file there is very little cross version analysis in most systems, despite the fact that the source control repository inherently contains this information. Going back to the SQL analogy used before, a version control repository is a database and users should be able to query it.

I would love to see a standard version query language and table structure that allowed you to run any query you wanted through the version control system’s engine.  You might be able to write queries like the following (pseudo-queries only):

Who wrote the code at a specific location in a source code file?
select author where file = “x” and line = y
where x is the file and y is the file line number.

Across all files, which version’s check in comments contain a specific string pattern?
select revision_number, file where comment like “x”
where x is the check in comment to look for.

What check ins has a particular person made in the last 10 days?
select file, revision_number where author = “x” and checkin_date >= y
where x is the user and y is the date 10 days ago.

Which check ins had the biggest effect on a particular file?
select top 5 revision_number where file = “x” order by lines_changed desc
where x is the file.

We took a stab at that in our Tools for Visual Studio product with the Find Version feature.  It allows you to find the versions of one or more files that match specific criteria, such as the ones above.  It does so with a GUI interface, not a query language like I proposed, though.  The most difficult part about this feature was finding a way to do this across several different version control systems, yet maintaining a consistent interface.

In an industry like software development, where most people understand the concept of one interface and many implementations, it’s amazing to me that this hasn’t caught on yet in the area of version control.  Maybe some day that will happen, and moving to a new version control system won’t waste time that could otherwise be used writing code.

Unfortunately I discovered this technique after we finished the documentation and shipped the plug-in, but hopefully me pointing it out here may help some users. 

Also, don’t forget the “Activate Editor” command in Eclipse (F12 by default).  If you are using _eclipse_execute_command to jump into different Eclipse Views and search around mouse-less, hitting F12 will jump you back into the last active editor.

<update> 

Check out this thread of the SlickEdit Forums for adding a generic Eclipse Pass-through Command: http://community.slickedit.com/index.php?topic=3549.0

From the post:
If you are evaluating 3.4.0 for your company, you can make this happen easily.  One of the best features in Core 3.4.0 is the introduction of _eclipse_execute_command, which is discussed in the user guide/readme, and also a little more in my post here: http://community.slickedit.com/index.php?topic=3816.0 .  This is the idea that Rob suggests in this thread.

I’ll take this opportunity to give a brief tutorial on how to integrate that “Activate Task” shortcut into the SlickEdit environment.

First you need to know the command id of what you are trying to execute.  I used the method described http://evans-stuff.blogspot.com/2007/10/it-seems-that-im-not-only-one-still.html , in which you create a Simple Cheat Sheet and use the Command Browse button (see first screenshot).

Then I just used the search field to find the command (see second screenshot).

Now that I had the command/parameter info, I opened up the Slick-C macro file where I write my custom commands (ryan.e), and added functions for Activate Task and Deactivate Task using _eclipse_execute_command (see third screenshot).  Remember to load your macro file with F12 after writing the functions.

Then I used the SlickEdit Keybindings dialog to bind eclipse_activate_task to Ctrl + F9 (see fourth screenshot), and voila.  Hitting Ctrl + F9 in a SlickEdit editor will launch the Mylyn Activate Task dialog.

It may seem like a lot of steps, but it’s really not.  This whole process took me less than 10 minutes including the time I took to capture/crop/annotate the screenshots.  You can use this method to execute almost any Eclipse command from any plug-in from the SlickEdit environment.

- Ryan

Using Code Annotations to Write Review Comments
The Code Annotations feature in the Editing Toolbox is extremely useful for writing code review comments because it lets you attach comments to specific locations in the code without altering the code itself. You can bring up the Code Annotations tool window by clicking SlickEdit > Show Code Annotations.

[Click for full size image]

The first step when writing code review comments is to create an annotation file to store all of your code review comments. You can then send this file to the code review organizer when you’re done. You can use the Annotation File Manager to create a file called “Code Review – Bob” (or whatever your name may be).

Writing Comments About the Code
After applying the “Scott’s code” visualization scheme that we made in the first article, we can navigate through the sections of code that Scott has written. On line 497 of PackageBaseWhidbey.cs, we see that he’s doing a GUID comparison using a literal string. This goes against coding standards, so we’ll log a comment that the string literal needs to be defined as a constant. Put the cursor on that line and click the New Annotation button on the Code Annotations toolbar. This will bring up the New Annotation dialog.

We’ll create a review comment, which is one of the standard annotation types. We’ll also select the “Global : Code Review – Bob” scope, or category, which will put the annotation into the code review file we created earlier. After filling out the fields and clicking OK, a purple highlighted marker is placed on the line of the new comment.

[Click for full size image]

Once you create an annotation, it gets an entry in the annotation list. You can select that entry to see a summary of the annotation, or you can double click on it to jump directly to the code it is assigned to. This makes it easy to get to the code that you’ve commented on.

We also found a bug on line 431 of FileUtility.cs, so a bug annotation can be logged for that. This new annotation has a red highlight to indicate that it’s a bug type.

[Click for full size image]

It’s helpful to only show annotations that you have created for the code review, without the clutter of others in the list. You can filter out all non-code review annotations by using the Annotation Filter Configuration dialog, available on the code annotations toolbar. Select Filter by Scope and select the “Global : Code Review – Bob” item. Now, only your code review annotations will be visible in the list.

Wrapping Up Your Review
Once all of your code review comments have been completed, they will all be contained in the file “Code Review – Bob.sca“, which we created at the beginning of the article (code annotation files have an extension of .sca by default). That file can then be sent to the code review organizer.

All of the received code annotation files can then be imported by the organizer during the code review meeting, where they can be discussed. Reviewing code this way maintains a tight link between the code review comments and the actual source code, and is far better than trying to manage the process with pen and paper, or a set of text documents.

You can also create a report of the annotations to print before the meeting, or to send to other developers. To do this, click the View annotation Detail toolbar button. The Code Annotation Details dialog will be shown and each annotation in the list will be shown in the report. A small red document icon will appear by each annotation that may be clicked to navigate to that annotation in the source code. The report can be exported to HTML or printed.

[Click for full size image]

The next step will be the actual code review meeting, which will be the focus of part 3 of this series. Once the code annotation files are pulled together from all of the reviewers, those comments can be discussed and updated. After the code review meeting, they can be exported to a single code annotation file and emailed back to the group. The developer being reviewed then has a clear set of action items as a result of the meeting.

I can’t say that I’ve met too many developers that eagerly looked forward to reviewing code. Most developers understand the importance of code reviews, but many have experienced the pain of poorly run code reviews. Although SlickEdit Tools does not have a “code review” feature, it provides several features that can be used together to make a code review run smoothly. A well done code review process can be the difference between developer loathing and developer buy-in.

Because code reviews are such a big topic, this article will focus on some of the steps that lead up to a code review. Code reviews typically focus on the work of a single developer, so we’ll start there. We are going to be code reviewing the developer with ID SLICKEDIT\shackett (or Scott) in source control, and we’ll be reviewing his work since March 3, 2008, which is the date of our last (fictional) release.

Finding the Best Files to Review
Our first challenge involves finding the set of files that Scott has worked on since March 3, 2008. We’ll use the Find Version feature of the SlickEdit Tools Versioning Toolbox as our starting point.

Find Version allows you to query versions of the source code files in your solution. The code review organizer can use this feature to find an ideal set of files to review. Simply click SlickEdit > Find Version to bring up the Find Version tool window. For this example, we’ll find versions with the following criteria:

• Since date: Finds all versions checked in since a particular date, such as the last release.
• Developer name: Finds all versions checked in by one or more specific developers.

These two criteria are used to find all versions checked in by Scott during the latest development cycle (March 3, 2008 – present).

No development team has the resources to code review every file in that list, so it’s important to find the best candidate files to review. Therefore, the next task is to look through the results and find a sampling of files that represent the most important or complex code. You might also include some files that have a high number of check-ins by that developer, which indicates high rate of change, or churn. These are the ideal candidate files to be reviewed. Email the names of those files to all developers who will be participating in the code review.

[Click here for the full size image]

In this example, PackageBaseWhidbey.cs has had several changes and is a very important file, so we’ll include that in our code review process.

Loading the Files to Review
When a developer is ready to prepare their review comments, they should close all other files and open the files in the list sent by the code review organizer. This can be done quickly using the Load Files feature in the Editing Toolbox, which allows you to quickly filter the list of files in your solution and open the ones you’re looking for. Click SlickEdit > Load Files to use this feature.

By typing “basew” in the filter, we narrow down the files in the list to only those that include that text in their file name. We’ll select PackageBaseWhidbey.cs and open it.

Isolating a Developer’s Work
One of the most difficult things to do when reviewing the code of another developer is actually identifying the work that that developer did, especially if it was done as part of a team. Once you have PackageBaseWhidbey.cs open, we’ll use the Version Visualizer feature of the Versioning Toolbox to see which parts Scott has worked on. Click SlickEdit > Version Visualizer to show this tool window. Next, select “Default User Scheme” in the drop down at the top of that tool window.

The versions of the file will be processed and the tool window will list the names of all developers who have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify who wrote each line of the file.

[Click here for the full size image]

You can find Scott’s name (SLICKEDIT\shackett) in the tool window list and double click on it to go to the first line of code he contributed. You can then use the next and previous button on the tool window to navigate through the blocks of his work.

To make Scott’s work stand out more distinctly, select his name (SLICKEDIT\shackett) in the list and click the “Toggle Selection Visibility” toolbar button. When toggled on, Scott’s work will stand out, and all other developer’s work will be dimmed out. This allows you to quickly see what code is Scott’s and what code isn’t. You can click this button again to toggle it back off.

[Click here for the full size image]

Another option is to assign a unique color to Scott. To do this, click the Configure Visualization Schemes button on the Version Visualizer toolbar. This will bring up the Scheme Builder dialog. We’ll create a new scheme to highlight all areas of code worked on by Scott. Click the Add new scheme button and give the scheme a name of “Scott’s code”. We can now add a scheme item for Scott and give it a color of bright red.

[Click here for the full size image]

We can save this visualization scheme and then apply it by selecting it in the Version Visualizer drop down. This same scheme can be applied to any file to highlight areas of the code written by Scott.

[Click here for the full size image]

If you find a block of code written by the developer being reviewed that looks questionable, you may want more context about the developer’s intent, such as the check in comment made when that section of code was checked in. This information is very important for creating meaningful code review comments. The easiest way to do this is to see which version that code was checked in as, and look at the comment associated with that version. To do this, select “Default Relative Age Scheme” in the drop down at the top of the Version Visualizer tool window.

[Click here for the full size image]

Again, the versions of the file will be processed, but now the tool window will list the IDs of all versions that have contributed to the current state of the file. The editor also becomes colorized into segments of lines that identify which version last updated each line of the file. The colorizing of each segment corresponds to the age of the version it was checked in with (dark is oldest, light is most recent).

You can find the version associated with the questionable code and take a look at the comments associated with it. You can also use the next and previous button as before to see all of the code in the file that was updated as a result of that check in. For instance, we may have disagreed with the AddMenuCommandHandler function being public. We can see that change was part of version 762. By hovering over that version in the Version Visualizer tool window, we get a better understanding of why the function was made public. All of these features assist the team in making judgments about which code to review. They also provide some insight into the motivation the developer being reviewed might have had when checking a set of code in.

Next is the task of actually commenting on the code. This task is always best done in electronic format, in a way that can be pulled together as part of the code review meeting. The next article in the series will go through some of the features of SlickEdit Tools that facilitate writing comments about code and tying them directly to the source, without modifying the files.

I believe that all teams need management. That’s not to say that they all need a manager; some teams do manage themselves. Effective management gets the most out of a team by setting clear goals and minimizing time lost to indecision. A good manager bridges the gap between the business team and the technical team, making sure that both viewpoints are properly considered. A strong development manager can bring a process-centric view to the development team that seeks to improve daily workflows and operations.

So, what’s wrong with “management”?

I think the core reason that software management is so reviled is that it is so rarely done well. In my programming career, I can divide my previous managers into 3 categories:

1. Benevolent, useless, harmless—this is the category into which fall most of my previous managers. They did a reasonable job of passing along information and managing schedules, but I never really felt they were helping me get my job done. I spent a great deal more time giving them status reports than receiving guidance.
2. Malevolent, clueless, harmful—fortunately this category contains only a few of my previous managers. These are the ones who made the job much harder than it needed to be. Sometimes it was done to further their individual goals, like the manager who stuck us with an unreachable milestone so he could get a 30% bonus. Others, it was because they had no idea what we were doing and didn’t have the courage to admit it.
3. Effective, purposeful, supportive—by far the smallest population, this is the category we wish all managers fell into but so few actually do. These are the ones who truly help you get your work done by providing the kind of guidance and environment you need to succeed. Tom R., you were the best!

How did we get here?

There are so many contributory causes for this problem. The first group, above, is composed of good people who just don’t know what to do. The second group shouldn’t be in charge of themselves, let alone others. I can offer little help to the second group, so let’s focus on the first.

There are two kinds of development managers: those with a strong programming background and those without one (henceforth called “programmers” and “non-programmers”). Even if you have some programming experience, it may not be enough to qualify you as a programmer. You have to have done enough to be considered as a peer on your programming team. I divide managers into these groups because they face different challenges. I’ve worked for managers from both backgrounds and neither is a guarantee of success or failure. My best manager learned his craft managing supermarkets before he went into software development.

To be a successful development manager, you need to know how to manage and enough about software engineering to make appropriate choices. Oddly enough, both groups seem to struggle with the first item. Though the non-programmers tend to have better communication skills than the programmers (if they didn’t, what the heck were they hired for since they’re not programmers?), few of them in my career were skilled managers.

Unique Challenges

The unique challenge faced by the non-programmers is their lack of knowledge about software development. This often hinders their decision-making. A common sign of this is an insistence on keeping to the schedule when a minor slippage could make a huge difference later. When you’ve been around software development long enough, you learn that schedules are fluid. What you do today can make your work tomorrow easier, or harder, depending on the quality of the design and implementation. It takes experience and insight to know when to make these tradeoffs.

Another common problem for the non-programmer manager is not being able to call shenanigans when a developer is snowing you. Even as a programmer, you will never know someone’s code like they will, but you will know from your experience when a developer is likely doing something wrong. My background has helped me to sniff out cases of “design by resume”, where developers chose a particular approach in order to get a trendy new technology on their resume. A non-programmer manager would have a hard time asking the appropriate questions to recognize this.

The programmer managers also face unique challenges. The first is the temptation to code and manage at the same time. I read where others actually recommend this as the desired situation. In my experience, the two activities are incompatible. Effective coding is about immersion, getting into a state of flow, and being very productive. Effective management involves being available to your team to tackle their issues when they arise. Even when I wanted to try to keep coding, I’ve never had a position where the management responsibilities didn’t crowd out any time I allocated for coding. As a manager, my favorite means of being involved with the code is to participate in design discussions and code reviews. This keeps things at a high level and still allows you to contribute your knowledge and experience.

Another problem for the programmer manager is trying to be “one of the guys”. This is manifested as a manager who is hesitant or unable to provide negative feedback. Often, these kinds of managers are promoted from within the team, making this even more of an issue. These managers still view themselves or want to be considered to be a member of the development team rather than its leader.

As a manager, your primary allegiance must be with the business team. Your job is to take their goals and translate them into effective plans to accomplish them. Where you think these goals will lead to problems, you need to point that out. However, if you can’t get them to change the goals, then you need to sign up to them and do your best to accomplish them. Programmer managers sometimes have a difficult time making this change.

Shared Challenges

The most common shared challenge is a lack of knowledge about how to manage. Most of the managers I have worked for had no formal training in management. At best they had a seminar or two. Few ever read any books on management or software development management. Since they, too, have had few truly effective managers, they have no guidance on how to manage. They just don’t know what to do.

An example where this shows up is the weekly status meeting. Most managers have one. They have one because their previous managers had one. In its most typical form, the status meeting lasts for an hour or so while the manager has a conversation with each member of the team, discussing what they are doing. The theory is that having this as a team fosters teamwork and helps everyone to know what everyone else is doing. In reality, the rest of the team already knows or doesn’t care. So this ends up being a large waste of time as the manager has a one-on-one conversation with each team member in front of the rest of the team.

Don’t get me wrong, I’m not saying that status meetings are wrong. But you need to choose to have one because of the benefits the team will get from it, because it is right for this team. Instead, most choose to have one because that’s how they’ve been managed in the past, and it is a visible sign that they are in charge. One of the primary goals of management should be to achieve stated goals with as little interruption in the daily work as possible.

The Solution

What we need to solve this is the same thing we need for all leaders: wise, beneficent individuals with a commitment to goals and compassion for their team. In software development, you need to add in enough knowledge to be mindful of the unique challenges in our field. To erase the pointy-haired boss from our minds or at least remove him as the dominant figure in engineering management, we need enough developers crossing over to become committed managers or enough business managers to gain an appreciation for software development.

April Fool’s Day was last week.  We had a pretty good April Fool’s Day post here, but I am not certain how many people got it.  This got me thinking about some of the better office pranks I have seen in my long tenure here at SlickEdit.  Actually, I do not think any of them happened on April Fool’s day.  But then its always April Fool’s Day here…

• Fun with peanuts – We’ve all seen the emailed pictures of this sort of thing.  A cubicle “door” is closed off with cardboard, and the cubicle is filled with packing peanuts.  There weren’t enough peanuts to completely fill the area, but I felt this performance was special for a couple of reasons:
  • This an open area with multiple cubicles, so rear walls (whose sole purpose was to hold in the peanuts) had to be constructed.
  • The Enter key was removed from the keyboard and dropped into the peanuts.  This part, was just plain mean.  A Starbucks gift card was also dropped in to soften the blow.
• Fun with Shrink wrap – An office classic.  Various times multiple items on a co-worker’s desk have been shrink wrapped.  There are a few fun variations:
  • Shrink wrap the telephone, and call the prankee as they are unwrapping the items on their desk.
  • When a member of the support staff left for some time to get married, everything accessible on his desk was shrink wrapped.  Since we had the occasional office cookout that day, foil was available and the shrink wrapped items were then wrapped in foil.  Finally, the desk was wrapped in foil.  The look on the face when first foil was removed to reveal shrink wrap: priceless.
    • We have not figured out how to shrink wrap an LCD display.
• Rickrolling – Rickrolling was all the rage around the office a while back.  This is where a link in an e-mail appears to be one thing, but is actually a link to a Rick Astley video.
• The ol’ Box On the Desk – I no longer remember who or when, but one time after a vacation somebody came back to find their desk packed into a box.  I always felt this was a little too mean.
• Moe’ing a Cube – One time a coworker returned from a few days off to find his cube covered in wrappers from Moe’s.  For good measure, a CD player was hidden under his desk playing the “Welcome to Moe’s” sound clip over and over.  I still have the CD.
• Mac on the Desk- At some point a co-worker had some Mac experience, but was hoping he would not be asked to work on a SlickEdit Mac port.  He returned from vacation to find a Mac SE30, a Mac OSX CD, and note “We need to talk – <managername>”.  Obviously, it looked ridiculous.
• A Call From a User- When a member of the support staff was leaving to take another job, we arranged for a user who had called support a lot to call and claim he had an absolutely ridiculous problem.  The subterfuge lasted until we could be heard laughing around the corner.

That is all I have.  Let’s hear yours.

Learn to write well. [*]

“But that’s not a programming skill!” you’re probably saying. Or maybe you’re disappointed because you thought I was going to be talking about the very latest cutting-edge API you can’t live without. Good writing skill is probably one of the most useful talents you can develop as a software engineer, and ignoring it is one of the biggest mistakes most programmers make.

Working in a cave

I used to work with a programmer who we jokingly referred to as a “walking MSDN”. He knew all the Win32 APIs, he could tell you the int values of const definitions and could enumerate the parameter lists to functions overloaded 30 times over. As a programmer, when given an assignment, he would go into his cave, hammer out a solution and would re-emerge from his cave with something that worked. I mean that in the most serious way… he would hammer his code into submission until it worked. There was no such thing as elegant code to him; it worked or it didn’t.

His manager both loved and feared him because he would do everything required on time, but he had no idea what happened in that cave. There was no visibility at all into what he was doing, and his manager had to blindly rely on the fact that he had a history of getting stuff done on time.

Programmers loved and feared him because he was incredibly knowledgeable and could answer any question about how this or that API worked. But whenever someone had to get inside his code, it was a pure mystery. There was no documentation, no models, no code comments… nothing but the raw code itself. For mister MSDN, this was no problem, because it was all in his head. For everyone else, it was like being lost in a big city with no map.

Was he a good programmer? Most people that worked with him would say yes… he was technically proficient and met his deadlines. But most of those same people would also say that they had a very difficult time working with him. That element of fear that he generated was a direct result of not being able, or willing, to communicate. He couldn’t communicate his plans or designs to other programmers. He couldn’t communicate his status with his managers. He couldn’t communicate his interfaces with other teams. Eventually when he left, his code left a wake of terror felt by those that had to pick up where he left off.

The lifespan of a tech skill

Technologies come and go. Seven or so years ago, I felt like I was completely on top of my game when it came to programming technology, at least in the Microsoft world. I had a very deep understanding of COM and ATL, thanks to Chris Sells, Brent Rector and Richard Grimes, and I coupled that with VB6 on the front end. This was a really potent combination and I thought I’d be working with that for years and years. But, as with most technical skills, it didn’t last long… .Net came along a year later, ATL became outdated and VB6 just disappeared into the sunset. Now that I’ve mastered C#, I find that I haven’t even touched the new stuff in .Net 3.5. The point is, no matter what technology you learn, with very few exceptions, it will disappear or be overshadowed by newer technologies (and probably sooner than later).

Writing skills will last you a lifetime, though. You will always benefit from it, regardless of what language or technology your use, or whether you’re even a programmer or not. Good writing skills are universal and will never be replaced.

The golden rule of documenting software design

Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:

Describe your design to others as you would have others describe their design to you.

When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.

If that wasn’t enough, consider the fact that someday you may be looking for another programming job. You’ll sit down with other developers and managers in an interview and try to describe how great your technical abilities are. You are now one of the vast sea of programmers trying to get that job. With your resume alone, a company has only your answers during the interview to base their decision on. With your documentation in hand, though, you can show them in full detail the type of work you’ve done and give them deeper insight into your thought process than they could ever get from interview questions alone. Your documentation serves as a body of work that travels with you, long after you’ve stopped working on this or that code, and speaks for your experience.

Of course, these skills won’t write code for you. But think about how much time you’ve devoted to learning programming based skills. Think about how many books you’ve purchased and read about programming. It’s a huge investment in time and money to keep up with. The next time you have some free cycles to sit down and pick up something new, consider skipping the software development section of the bookstore and pick up a book about technical writing. Here are some good books on this subject:

• Writing White Papers: How to Capture Readers and Keep Them Engaged
• Developing Quality Technical Information: A Handbook for Writers and Editors
• Documenting Software Architectures: Views and Beyond

Today, I want to discuss a common problem that occurs after the estimate is delivered. Often, the estimate is considered to be too high and management tells you how long you have to complete the task. Sometimes this is motivated by important business goals. Other times it’s motivated by a manager who wants to look good or has a bonus tied to a delivery date.

Regardless of the reason, when the team is given the new timeframe they have to scramble to meet it. Often, teams cut corners to try to hit what is, otherwise, an impossible deadline. This has happened to me on a couple projects with what I know now as predictable results. To illustrate it, I offer:

The Parable of the Loaf of Bread

In a land far away lived a king who was terribly fond of bread. He ate bread at every meal and would often request it as a snack. One day the king requested some bread, but he was told by the royal baker that they were out. Apparently, one of the apprentice cooks had used all the remaining bread to make croutons.

“Off with his head,” yelled the king, not at all pleased that he couldn’t have some bread. “Now, how long will it take you to get me some bread?”

“Good King,” replied the royal baker, “I can have a nice, hot loaf of bread for you in about 2 and half hours.”

“Two and half hours!?! Not good enough! I want bread sooner. Bring some bread in an hour or you will share the fate of your apprentice.”

The royal baker returned to his kitchen, determined to meet the king’s deadline. But how could he do it? Every good baker knows that it takes 10 minutes to mix the ingredients for the dough, 15 minutes to knead the dough, an hour to let it rise, and then another hour to bake. How could he finish in an hour?

“There’s nothing I can do to mix the ingredients faster,” he thought. “But maybe I can let it rise for a shorter time. And maybe I can bake it quicker if the oven is hotter.”

So he set about to make the loaf of bread, cutting corners wherever possible. He placed the bread in the oven after letting it rise only 20 minutes. He thought to himself that that loaf looked small, but hoped it would come out OK. After 30 minutes he removed the loaf from the oven. The outside was too dark from the higher temperature, but it didn’t look burned. Maybe this will be fine.

The royal baker rushed the hot loaf up to the king without a minute to spare. The king sliced open the bread to find that the crust was way too hard and the inside too dense and not at all cooked.

Thoroughly displeased, the king looked at the royal baker and asked, “What is this? This is not a decent loaf of bread!”

The royal baker replied, “Good King, I did my best to bring you a loaf of bread in the time you allotted, but this is the best that could be done.”

“How long will it take,” inquired the king, “to bring me a decent loaf of bread?”

The baker thought for a moment, but there is nothing he can do to shorten the amount of time. “I can have a nice loaf of bread for you in about two and a half hours,” he replied.

“Two and a half hours!?!” yelled the king. “I already gave you an hour. So bring me some bread in an hour and a half or I’ll cut your head off.”

The baker returned to his kitchen, highly motivated to give the king what he wanted. Try as he might, he could think of no way to bake a perfect loaf in the amount of time given. So, he took the uncooked center from the first loaf and added in a bit more dough. He didn’t have time to let it fully rise and he had to cook it for less time than it should, but it was the only way he could produce a loaf in the allotted time.

At the end of the hour and a half, the baker returned to the king with the new loaf of bread. Again, it was overly done on the outside. The inside was a mixture of dry, dense dough and underdone dough.

The king was furious and called the guards to have the baker executed. He had the assistant baker brought before him and asked him how long it would take to bake a nice loaf of bread. The assistant baker, clearly unnerved by the fate of the former head, now headless, baker responded, “Your Majesty, I am aware of your desire for some nice bread. However, there is nothing I can do to speed the process and produce a loaf that is worthy of your Highness. I can bring you a nice loaf of bread in about two and a half hours, but I could make you some delicious rolls in about half that time.”

The king mulled it over for a few moments and said, “Very good. Some rolls would be nice.”

The End.

In software development, this cycle is all too common. A deadline looms and we eliminate steps that we know are essential to producing quality code. We throw out unit testing or greatly reduce the number of tests produced. We eliminate design and code reviews so we can spend more time writing code. I’ve even seen projects curtail analysis and design thinking they can adapt as they figure out the fine points later.

The problem with this is that cutting corners produces poor software, often with a high rate of defects or a design that can’t be extended or modified to meet changing requirements. As the code base grows and has more of this low-quality code, every subsequent unit of development takes longer than the ones before it. Rather than providing the basis to speed subsequent development, it slows it down as you are forced to trace problems and limitations in work that was previously “done”.

It’s hard to get non-developers to understand the impact of using poorly written code. But it is as clear and obvious to developers as attempting to use a half-backed loaf of bread to jump-start the creation of a new loaf. So it’s important to push back and try to educate your partners about what they are asking you to do.

Explain the risks involved and why essential steps can’t be skipped. I’m not saying that you should be a purist. Be pragmatic and willing to bend. When your back is against the wall, you should look for ways to perform steps, like unit testing, as quickly and efficiently as possible. You may find that the business need warrants the risk of skipping unit testing on infrequently used or less complex code paths.

Try to get them to reduce the scope of what is planned, just as in the parable when the assistant baker offered rolls instead of a loaf of bread. Cutting features is the surest way to shorten a schedule. Even if you don’t get permission to drop features, work on the code in an iterative and incremental manner. Get the essential functionality finished before adding bells and whistles, even if you’re told you can’t ship without them. When they’re given the option of shipping without them or shipping nothing, you’d be surprised how often they are willing to leave them off.

Hopefully, your project is a team effort and not a monarchy. Just as there are development considerations that they may not understand, there may be business considerations that you don’t understand. Work together to define an acceptable level of risk and then perform your development accordingly.

1. Gas oven
   1. If the gas is on, but the pilot light is out, you could asphyxiate and die
   2. If the gas is on, and the pilot light is on, the oven will be hot.  You could be badly burned, and breath in heated air which will damage your lungs, and you could die
2. Electric oven
   1. If the oven is on, the oven will be hot.  You could be badly burned, and breath in heated air which will damage your lungs, and you could die
3. In general
   1. If you stick your head in an oven that is on you will be badly hurt
   2. Ovens tend to be dirty.  You will get dirty.
      1. If you have long hair, it will get dirty and that’ll be a real mess.
         1. If you are a man with long hair right now, you are recognized by pretty much everybody around you as somebody who is stuck in 1987.  I’m not saying this is a bad thing, just that if you choose to have your hair cut every other political administration, you’ll stand out in a crowd

When you come right down to it, there just isn’t a really good reason to put your head in an oven.  I know they need to be cleaned from time to time, and you have to reach in to get the back, but really you don’t have to put your head in, you can just reach your arm out.

I never had to be told not to stick my head in the oven, I managed to figure it out on my own.  I’m not sure at what age I had this revelation, but I’m sure it was early (to be fair, my mother may actually have mentioned it at some point, but I’m confident I would have figured it out).

Here are some other things I learned:

1. Initialize variables
   1. When you declare a variable, it takes an extra few seconds to initialize it.  Always do this.  If you don’t, you will just find yourself going “I should have initialized that” when you fix a bug related to it not being initialized later
      1. Uninitialized variables are a pain to track down
   2. Static variables in C are guaranteed to be set to 0 at startup.
      1. Initialize them anyway.  It makes the code more clear and saves you the let down when you think you found an uninitialzed variable problem before you remember that they will be initialized to 0 at startup.
2. Check in code
   1. While it is really unpopular to check in code that might break a build, and you might be ridiculed by your peers for it, it will be much more uncomfortable to explain that you lost a week of work because your hard drive crashed.
   2. Sometimes you lose stuff.  Code that was not checked in is no exception.  Not in my case at least. 
   3. Hard drives crash (see 2.1).

Most of these lessons somebody did tell me somewhere along the line.  But I find that a lot of the smaller lessons in life I have to learn the hard way (sometimes more than once).  Of course some of those lessons should be as obvious as not sticking your head in the oven.

I am going to go continue to work on a feature for SlickEdit 2008.  While I am working on it, I will try to remember not to stick my head in the oven.

I could understand if dexplore were processing SETI data on startup, crunching genome data, or possibly computing sophisticated weather patterns. But let’s be honest, it’s a glorified web browser. All of the help it provides can be found online, and chances are, it’s more up to date online than it is dexplore.

Apparently, I’m not the only one that completely hates the help system. AprilR reports in her blog that Microsoft is overhauling MSDN help based on user feedback. That’s great, but why has it taken so long? The only conclusion I can come to is that Microsoft must simply not use it. If anyone on the Visual Studio development team actually used it, it would have been overhauled a long time ago. It’s a shame too, because the actual MSDN content is, in general, very good.

Maybe someday we can go back to chm. It just worked and did the same job that MSDN does, just a million times faster. Well, everything except online content, but… that’s why I have Firefox installed on my computer (yes, Firefox). I set up my own help launcher macro to spawn a web browser, take the selected text and do a Google search on MSDN and the selected text.

Here’s the macro:

Now, if you go into Tools > Options and select Environment / Keyboard, you can bind Macros.MyMacros.HelpModule.LaunchWebBrowser to the F1 key (or whatever you like). Now, when you press F1, it will go right to Google and search for “MSDN [selection]” where [selection] is any selected text in your active document. It’s faster than launching dexplore and gets better results, at least for my purposes. The one thing it can’t do is determine the type context of your selection, but that can be fixed by by adjusting the search query.

Help is one of the most basic needs of every programmer. It’s an “I use it every day” kind of tool. Give Microsoft your feedback, because if there’s one thing that needs help in Visual Studio, it’s the help.

I normally start the day with Opie and Anthony on XM radio.  This is fine first thing in the morning, but when the coffee kicks in and my brain reaches operating temperature, I switch to music.

I have always been a big Van Halen fan, but I find that the only time I really listen to them anymore is when a need a couple of hours of incredible focus.  I can turn those old albums up to unsafe levels, and usually get some work done.  Occasionally I will do the same thing with Metallica, but only the early albums.  I’ve never felt the same about their music since I saw Some Kind of Monster.

I also find that times that I get stressed out, I tend to revert to the soundtrack of my early youth.  This involves a lot of Simon and Garfunkel, Jim Croce, John Denver, and Glenn Campbell.  It was the 1970s - the decade that brought us the leisure suit, lawn darts, and Ken Olson of Digital Equipment Corporation told us “There is no reason anyone would want a computer in their home” (To be fair, this far from the most short-sighted quote out there about the future of the computer industry, it was just the first one I found from the 70s).

Note 1: If anybody has a picture of a leisure suit, would they please contribute it to the Wikipedia article on leisure suits.

Note 2: I have no idea when lawn darts were invented.  It seems to me that it would have to be the 1970s.

Right now, I am listening to “The Weight” by The Band.  What are you listening to?

If you’re familiar with Quake, or pretty much any other FPS, then you know about the deathmatch. It’s my single favorite type of game and, in it’s own way, is really therapeutic when the stress of development, or testing, gets you down. A lot of the other developers I worked with at one point also loved to deathmatch and we used to play during lunch. When testing time came around, we found a way to make it fun… QA Deathmatch.

Here are the rules for QA Deathmatch:

1. Scoring works on a point system: the points correspond to your company’s severity levels for bugs. If you find a bug, you score that bug’s severity level in damage. The person who owns that bug sustains that many points of damage. If your severity level goes in reverse order, then you score ([max severity] – [bug severity] + 1) per bug. For instance, assume your company has a severity level of 1 for critical bugs, and 5 for cosmetic bugs. If you find a bug with a severity of 2, then you score (5 – 2 + 1) or 4 points of damage and the bug’s owner sustains 4 points of damage.
2. Damage can be recovered: by fixing a bug that caused the damage. When a bug is fixed, you reduce your damage sustained by the point total for that bug. However, the person who found the bug does not reduce their damage total.
3. All features are fair game: there are points to be won everywhere in the code base, don’t limit yourself. The more you try all of the features, the more chance you have of scoring big.
4. First to find a bug gets the points: If you find a bug that’s already been logged, you score nothing.

All players have three running stats:

• Damage delivered: The sum of the bug scores found by you.
• Damage sustained: The sum of the scores of the bugs found by other players against your features.
• Damage recovered: The sum of the damage reduced by you by fixing bugs.

At the end of each day, the point totals are taken and five medals of honor are awarded:

• Sniper medal: The person who delivered the most damage
• Stealth medal: The person who sustained the least damage
• Tactics medal: The person who had the best delivered:sustained ratio
• Medic medal: The person who recovered the most damage
• Commander medal: The person with the greatest overall score as calculated by [delivered - sustained + recovered].

The point of all of this is that it makes testing fun. It gives you motivation to find bugs, fix bugs and make your features as solid as you can. It’s amazing what winning one or two medals at the end of the day can do to make you feel great about going into testing for another day. And if you think winning a medal is motivating, wait until you lose a medal to someone else.

Another great thing that QA deathmatch encourages is getting everyone to test all aspects of the system. Too often, developers only test their features and don’t go outside that box. However, there are bugs to be found everywhere, and when you are in scoring mode, you’ll take the time to check out all the new features to see what you can break to score big. It’s also a great facade for getting competitive about finding bugs. Nobody likes the guy that finds a lot of bugs in their features, and even fewer like to be that guy. It’s easy to feel bad about finding a lot of bugs. You’re essentially adding work to other people’s plates. But in QA deathmatch, you are playing a role and it’s a great way to detach personal feeling from the process.

There are other variations of the game too:

1. Team play: Development is split into two or more teams, divided by feature sets. Point totals are not by individual, but by team.
2. Capture the flag: Just like team play, but instead of end-of-day totals, points are calculated when bugs are found or fixed. Instead of medals, flags are used that can be stolen by any team at any time. It feels great to find or fix a bug, then be able to steal a flag from another team.
3. Mercenaries: Testers that aren’t involved in fixing bugs are mercenaries. They may not participate on a team or get any of the normal medals. Instead, a special Mercenary award is given to the one who scores the most damage in a day.

Again, the whole point is to make testing fun. All you need is a whiteboard, a calculator and some gadgets to be used as medals. Of course, you can always add to the game by printing a bunch of these then taping one to a developer’s cube with the bug number and severity penciled in whenever a bug is found. It can only be removed when the bug is fixed. The possibilities for expansion are endless.

QA is a painful process and some days, when 8+ hours of QA work lay ahead of you, it’s just hard to get out of bed in the morning. Don’t let boring work be boring. Not only will you have more fun during the day, but I can guarantee that when you turn QA into a competitive deathmatch, the quality of the final product going out the door will be better than if you are finding and fixing bugs for the sake of quality alone. Happy sniping!

The more a task resembles a previously completed task, the easier it is to estimate. Ideally, metrics kept about the previous task will include time spent on various activities and the total time overall. When estimating the new task, you could analyze which activities are likely to change based on completing the previous one and derive an estimate for the new task.

In order to best illustrate the challenges of software estimates, I will use the time-proven technique of the parable.

The Parable of the Cave

Two people stand before a cave. One is the sagely manager of a cave exploring company who’s wisdom is only exceeded by his wit, charm, and humility. Let’s call him, oh, “Scott”. The other is a cave explorer of indeterminate gender who bears no resemblance to any programmers past or present that this author may have worked with and whose size may be big or little. Let’s call him/her “Endian”.

“Endian,” said Scott in a sagely voice that was both commanding and compassionate, “I need you to explore this cave. But before you do, I need to know how long you think it will take, so that I may build a schedule and tell the sales team when the cave will be ready.”

“Great Scott,” replied Endian using the title bestowed upon Scott by his admiring employees, “how can I give you an answer when surely you know I have never been in this cave before? The cave may be vast, with deep chasms. It may contain a labyrinth of underwater passages. It may contain fearsome creatures that must first be vanquished. How can I say how long it will take to explore?”
Scott pondered Endian’s words and after a thorough analysis that might have taken days for others but was completed in but a moment for him, he replied, “Surely this is not the first cave you explored. Are there no other caves in this district? Use your knowledge of those caves to form an estimate.”

Endian heard these words and still his doubt prevailed. “Your words are truly wise,’’ said Endian, “but even within a district the caves may vary, one from another. Surely, an estimate based on the size of another cave cannot be deemed accurate.”

“You have spoken truly, good Endian,” replied Scott in a fatherly, supporting tone that lacked any trace of being patronizing as certain cynical readers may think. “Here, take from me this torch and this assortment of cheeses that you may explore the cave briefly. Return ere the morrow and report what you have learned.”

The parable continues like this for pages, as parables are known to do. Let’s see, Endian enters the cave…something about a wretched beast of surpassing foulness…he continues on…hmm, that’s what the assortment of cheeses were for. Ah! Here we go.

Endian returns to Scott, his t-shirt ripped and his jeans covered in mud. Being always concerned with the well-being of his employees, Scott offers Endian a cool drink, then asks, “Endian, what news of the cave? Have you an estimate that I can use for my schedule? What shall I tell the sales team?”

Endian considers all that he has seen and builds a decomposition containing the many tasks necessary to explore the cave based on his earlier reconnoitering. He factors in variables for risk and unknowns, and then he responds, “Two weeks.”

Applying this Wisdom

To truly appreciate the punch line, you do need to check out The Perfect Estimate.

The point I’m trying to illustrate is that estimating software development is like estimating the time needed to explore a cave you’ve never been in. You don’t really know until you get in there. Still, there are techniques that can help.

First, draw on your experience. Even though technologies may be very different, few automation problems are empirically new. They bear resemblance to other things we’ve done in the past.

Expect the unexpected! Make sure you factor time in for the unknowns. If your schedule only contains the things you can think of, then it’s certainly going to fall short when the unexpected arises. There will always be things you don’t know to put into the schedule.

Provide estimates that are ranges rather than just a single duration. If a task can take 2 to 4 weeks, provide it in that manner. If your project planning software cannot accomodate date ranges, enter the task as 2 weeks and then put in a secondary task for another 2 weeks to account for this. I like to name these tasks, “risk factors”. So, if I have a task called, “Integration Testing”, I would add another called, “Integration Testing, Risk Factor”. This way, I can specifically see how much time has been set aside for this variability, and I can see what happens to the schedule if I increase or decrease that amount of time.

Make your estimates as fine-grained as possible. An estimate for a task that only needs a few hours is far more likely to be accurate than an estimate for one that will need a couple weeks. By making your estimates as detailed as possible you not only improve accuracy but the work necessary to create a detailed estimate will often turn up tasks you might otherwise overlook.

Even if your manager only wants an overall estimate, you should do a detailed decomposition to make sure you build the best estimate possible. This decomposition will also serve as a guide during your work, both as a checklist to make sure you haven’t forgotten something and as a status check to see if you are on time. This can help you timebox activities, applying the available time to a task. Projects can run over due to time spent waffling on design decisions. Timeboxing tells you when it’s time to make a decision and move on.

Build your decompositions with tasks that are either complete or incomplete. When tracking progress, don’t fall into the trap of recording activities as some percentage complete. A task is either finished or not finished. Showing partial completion leads to a false sense of security.

Use incremental and iterative processes. As in the parable, sometimes it’s useful to make a quick, preliminary exploration in order to build a more comprehensive estimate. Continue to refine your estimates and the overall plan. The closer you get to the end, the more accurate your schedule should be.

Work on the riskiest part of the system first. Too often projects run over when someone discovers a large problem in the final stages of the work. Assess the risk of each portion of the work and tackle first those parts that are most likely to exceed their estimates or induce changes in the rest of the system.

Lastly, it is absolutely critical that an environment of trust exists between the development team and the rest of the company. Your job should be to deliver the best estimate you can with appropriate risk factors identified. Too often estimates are inflated to make sure that we can hit them. Equally often, due dates are set artificially early to allow for overages. Both of these strategies prevent the company from building an effective plan for this project and developing appropriate contingencies. Worse, these constraints sometimes lead to poor choices and compromises during development that add further risk.

The Coors Brewing Company of of Golden, Colorado, USA, had a fairly profound impact on the thirty-somethings in the world like myself.  You see, we have been led to believe for thirty years or so that it was once illegal to transport Coors beer East of Texas.  As far as I can tell, this was never true (although it was not nationally available until sometime in the 1990s).  Nonetheless it was the plot of the hit 1977 movie Smokey and the Bandit.  And when I say “hit 1977 movie”, it was the second highest grossing movie of that year.  Star Wars was number one.  It is not Scorcese or [fill in name of artsy director you like here], but it was a big deal.

I don’t want to get off on a big tangent here, but a small one is necessary, stick with me.  For anybody who did not get basic cable over the last thirty years, the basic plot is as follows:

• It is illegal to ship Coors beer East of Texas
• Burt Reynolds and Jerry Reed are paid a large some of money to get 400 cases Coors beer from Texarkana, Texas to Atlanta, Georgia in twenty-eight hours
• Burt Reynolds distracts cops from the speeding eighteen wheeler carrying the 400 cases of beer by performing really cool stunts in a 1977 Trans Am
  • In order to keep a low profile, the eighteen wheeler is painted with a mural of a masked bandit robbing a stagecoach.
• Jerry Reed sings his hit song, “East Bound and Down”
• Hillarity insues

Sounds ridiculous right?  Well, it does lack the realism of “Die Hard”, but it is actually not a bad movie provided that:

1. You are a guy
2. When you watch a movie you want to be entertained and don’t question things too much.

But the point here is that history was changed:

• The mystique of Coors beer was further boosted to those who could not get it East of Texas.  Here I need to emphasize that people thought it was really illegal to take Coors beer East of Texas.
• The Trans-Am became as cool as the (then recently jailed) Evel Knievel with suburban pre-teens across America.
• Jerry Reed had a hit single.

As much as I love old Trans-Ams, and that song, what I want to focus on is the first item in that list: People believed that it was illegal to take Coors beer East of Texas.  This is one of the standout facts people in the United States know about Coors beer.  What they do not know is this: in 1959 Coors was the first beverage in America to be packaged in a two-piece aluminum can.  These cans are a part of common life today.  There are two on my desk right this minute (diet soda, not beer).  They are so common place people my age really cannot picture a world without them.  A world where I am told you had to use a can opener (one of the pointy triangluar ones, not the rotating ones with a blade) simply to drink a beverage.  I imagine the people at The Coors Brewing Company of of Golden, Colorado are proud of having introduce this convenient, and recyclable, can.  But far more people remember that it was illegal to ship Coors beer East of Texas (and when I say “far more people”, I  mean “me”).

What could this possibly have to do with software development?  It can be difficult to figure out what people will latch onto.  In my tenure at SlickEdit, I have seen a lot of sleep lost over features that did not make quite the splash we hoped they would.  Thankfully none of these turned out to be as big a blunder as the Edsel.  I will share the one that personally hit me the hardest though:

1. Launch SlickEdit’s DIFFzilla® setup dialog (Tools>File Difference)
2. Fill in “Path 1″ and “Path 2″ with any two files that SlickEdit tags
3. Click the “Symbols” radio button at the top left



4. Clicking OK will yield output that actually show changes on a symbol level, including modified functions and added/deleted functions.



5. Selecting an item from this list and clicking “Diff” will actually compare just those two functions in the DIFFzilla output dialog.

This can be convenient for a number of reasons.  Sometimes a function moved, and the file itself has changed so much diffing two whole files just confuses matters.  This feature will shine in those cases.

I thought this would be a hit.  Everybody here thought it was a neat idea, and I worked feverishly to sneak this into the 8.0 release.  It was not a hit.  In fact, I am not certain that a user has ever actually used this feature.  It is generally good for a “wow” or two at a trade show though.

The moral of the story?  Be careful when you choose to add features.  The two-piece aluminum can may not look nearly as flashy as a 1977 Trans-Am, but people will still be using it 50 years later.

Anyone who knows me well, knows that I am really into programming languages. Like editors, a programming language is a tool which is supposed to make your programming task easier.

Unlike the typical programmer, I have experience designing and implementing languages. Slick-C, the macro language in SlickEdit, is the third fairly major programming language I’ve been involved with. My experience and passion for programming languages gives me quite a bit more insight into performance and elegance.

I started learning Python because SlickEdit needed better support for the language. Unlike Ruby, I never heard a lot of hoopla about Python. The programming world has many, many scripting languages, most of them poorly designed. I figured that Python was probably just another poorly designed language with little or no technical merits.

I’ve been puzzled by the popularity of Perl since it has so many flaws. By the way, just because I dislike some elements of Perl doesn’t mean I will direct SlickEdit not to provide great support for it. SlickEdit language enhancements are based on popularity, and currently Perl is more popular than Python. However, that doesn’t mean I won’t rank on it a bit. Heck, I rank on C/C++ and it’s the language I use most (beware of sharp knife). To date, we have spent WAY more time on Perl and Ruby support than Python. This will always be the case, because it is WAY easier to implement Python support.

I have done my best to make these comparisons unbiased. The only code that I have written for these languages is sample code to better understand these languages. I do have good experience in parsing these languages either for color coding or tagging symbols for SlickEdit. My opinions are based on what I think make a state-of-the-art language. My next article “A Deeper Look at Python”, will talk more about Python and what things make a language state-of-the-art.

This comparison of Python, Perl, and Ruby is from a grammar perspective and does not cover the run-times of these languages. There are often cases where you end up choosing a language due to its run-time features. I’m not going to cover run-time features here. A detailed chart of reasons to choose one or the other which includes run-times would be very useful though.

Python Versus Perl

Python beats Perl by a mile. In a nut shell, Python and Perl have similar language features but Python is way easier to learn and use than Perl. Here are some specific examples:

Perl

Python

Python is a big improvement over Perl. I would provide more reasons why Python is much better but I’d like to keep this article short. I will say that Perl has a very large and arguably cryptic grammar. Perl is hard for others to quickly read and understand. I find Perl hard to write as well. Because Perl has a lot of syntax which is so different from other programming languages, you quickly forget it and must read the language documentation again.

Python Versus Ruby

Comparing Python and Ruby is not as simple as showing some small snippets of code as I did above. For me, Python is clearly a better language than Ruby but I can understand why some people might like Ruby better. Ruby took the “kitchen sink” approach. It has language syntax for pretty much all the features of Perl, Python, and then some. Ruby embraces many of Perl’s complex features, which may make Ruby seem more familiar to the Perl fanatic than Python. There are loads of “shorthands” and optional syntax. To the naive person, lots of features give the false impression that the language is better or somehow more powerful.

While more can mean better, it definitely doesn’t in Ruby’s case. Due to the very large grammar, Ruby is way more difficult to learn than Python. The comment on the Ruby web site about Ruby being easy to learn is definitely not true. Reading Ruby code written by someone else is a problem too since others will use constructs you are not familiar with or don’t like. The ambiguities in the language make it much harder for editing tools to provide smart editing features. I’m not willing to give up smart editing features for shorthands which save a few characters. If you are using a dumb editor, then you might see this differently.

In order to keep this article short, I will not show all the constructs in Ruby which make it a large ambiguous grammar. So this may look like I’m nit picking.

Poor Ruby Syntax Choices

Here are some poor Ruby syntax choices:

Ruby

Python

Ruby should have chosen a syntax which allows for a more conventional single line statement like one of the following:

Function Pointers or Function Objects

Ruby really messed up with function pointers (or function objects):

Ruby

Python

Ruby

The first Ruby example uses syntax which none of us should ever have to learn. To make matters worse, the keyword “yield” is used which means something totally different in C# and Python. I haven’t yet found a way to pass a predefined function as an argument to a Ruby function. Ruby does support passing method pointers using the “method” feature (ex “variable.method(:methodName)”), but again Python provides a much simpler syntax. To pass a method pointer in Python you just specify “variable.methodName” like you would in C#.

Ruby’s grammar is riddled with multiple ways of doing things. Adding to the confusion, it often unnecessarily chooses syntax different from popular languages we are familiar with. As a result, Ruby is much more difficult to learn, read, and write.

Not everything is better in Python. For example, Ruby’s class/member syntax is better than Python. For me, this doesn’t help Ruby nearly enough to make it a better language.

Summary

Both Ruby and Perl have large ambiguous grammars (Perl’s grammar is worse). They often disambiguate syntax based on context. For example, the slash symbol (/) can mean divide or perform a search depending on the context. In the search case, the slash is used to delimit the string. This is an unnecessary complexity since this is just another way to call a function with string parameters.

There will never be a case where having a very large and ambiguous grammar makes a language better. This is one of the flaws in C++. I’m an excellent C++ programmer and I’ve had to stare at some C++ statements for way too long. Note that Java and C# have very small unambiguous grammars with only a few shorthands. Modern languages have so many features that they must keep the grammar small in order to reduce the learning curve. I guarantee that the best state-of-the-art languages of the future will do the same. For this reason alone, Python is clearly better than Ruby or Perl. Keep in mind that I have not compared the run-times of these languages and there are often cases where you end up choosing a language due to its run-time features.

There are other ways that scripting languages can speed the programming process without creating a large grammar with excessive shorthands. For example, unqualifying names with import/using statements and choosing short name space names for standard run-times (Python does both of these). Also, if the grammar is small and unambiguous, editing tools like SlickEdit can provide more assistance.

My next article “A Deeper Look at Python”, will talk more about Python and what things make a language state-of-the-art.

Prerequisites

• Visual Studio 2005
  You can alternately use the free Visual C++ Express Edition or the VC++ 8 compiler in the Windows SDK v6.0 if you’re a makefile master. Visual Studio 2003 (VC++ 7) will probably work just fine, but some of the project configuration steps will be different than what is explained here
• A web server
  For this article I used Sambar Server 7.0. Any HTTP server that can run the PHP 5.x ISAPI extension (php5isapi.dll) will do
• PHP 5 binaries, installed and configured for your server
  I used PHP 5.2.4. Using the windows installer package (.msi file) makes configuration easier
• PHP 5 source code
  DONT PANIC! You do not need to build PHP from source, just get the source that matches your binary version. You will need an extraction utility like WinRAR or ZipGenius that can handle .tar archives.

Conventions

Italics denote file paths and names. C:\Server\PHP\dev
Screenshot icons provide links to images showing how dialogs are configured.
Document icons provide links to sample code files.

Configuring the Environment

I will not discuss installing and running the HTTP web server. If you do not already have IIS available on your machine, I recommend the Sambar Server.

If you do not already have PHP 5 installed, download it from php.net. If you download and run the MSI installer package, it will configure your web server.

After you’ve got PHP 5 installed and configured for your server, download and extract the complete PHP 5 source code, also from php.net. Caution: Do NOT extract the source archive over top of your existing binary installation. This article’s example setup includes the PHP 5 binaries installed to C:\Server\PHP5, and the source code extracted to C:\Server\PHP5Src.

Creating the Project

In Visual Studio 2005, create a new Visual C++ Win32 project using the project template. For this example, I named the project CustomExt. When the Win32 Application Wizard appears, click Application Settings (on the left) and select DLL as the application type. Click Finish to create the project.

I recommend following along step-by-step, but you can also download the complete project source (zipped). You’ll still need to follow the instructions for changing the directories to match your system.

Change Default C++ Options

Bring up the Project Properties dialog, and make sure the Debug configuration is active. Under Configuration Properties > General, change the Character Set to “Use Multi-Byte Character Set”.

Then under Configuration Properties > C/C++ > Code Generation, change the following options:

• Enable String Pooling to “Yes (/GF)”
• Enable Minimal Rebuild to “No”
• Basic Runtime Checks to “Default”
• Runtime Library to “Multi-threaded Debug (/MTd)”

Under Configuration Properties > C/C++ > General, change the following:

• Debug Information Format to “Program Database (/Zi)”
• Detect 64-bit Portability Issues to “No”

Be sure to click Apply to save the settings.

Set the INCLUDE Paths

Still on the Project Properties dialog unders Configuration Properties > C/C++ > General, in the Additional Include Directories, add the following paths, replacing C:\Server\PHP5Src with the location on your machine where you extracted the source code.

C:/Server/PHP5Src/main
C:/Server/PHP5Src/Zend
C:/Server/PHP5Src/TSRM
C:/Server/PHP5Src/regex
C:/Server/PHP5Src

Again, be sure to click Apply to save the settings as you go along.

Set the Preprocessor Definitions

On the Project Properties dialog, under Configuration Properties > C/C++ > Preprocessor, add the following definitions:

ZEND_DEBUG=0    

ZTS=1    

ZEND_WIN32    

PHP_WIN32

Note: Do not be tempted to change ZEND_DEBUG to 1, even for this Debug build, as this will prevent your extension from being loaded into the pre-built PHP binaries installed on your system.

Set the Linker Options

On the Project Properties dialog, under Configuration Properties > Linker > General add the path to the C:\Server\PHP\dev directory to the Additional Library Directories. This is the directory underneath your installed PHP binaries (not the extracted source). This directory should contain php5ts.lib.

Under Configuration Properties > Linker > Input, add php5ts.lib to the Additional Dependecies.

By convention, php extensions start with php_, so under Configuration Properties > Linker > General, for the Output File option, I changed the output name to php_custom_ext.dll. This is entirely optional.

The Extension Code

Replace the contents of stdafx.h with the following, or download it :

#pragma once
/* PHP Extension headers */
/* include zend win32 config first */
#include "zend_config.w32.h"
/* include standard header */
#include "php.h"

Replace the contents of ProjectName.cpp (in this example CustomExt.cpp) with the following (or download it ):

#include "stdafx.h"/* declaration of functions to be exported */
ZEND_FUNCTION(DoubleUp);
/* compiled function list so Zend knows what's in this module */
zend_function_entry CustomExtModule_functions[] = {
   ZEND_FE(DoubleUp, NULL)
    {NULL, NULL, NULL}
};    

/* compiled module information */
zend_module_entry CustomExtModule_module_entry = {
    STANDARD_MODULE_HEADER,
    "CustomExt Module",
    CustomExtModule_functions,
    NULL, NULL, NULL, NULL, NULL,
    NO_VERSION_YET, STANDARD_MODULE_PROPERTIES
};    

/* implement standard "stub" routine to introduce ourselves to Zend */
ZEND_GET_MODULE(CustomExtModule)
/* DoubleUp function */
/* This method takes 1 parameter, a long value, returns
   the value multiplied by 2 */
ZEND_FUNCTION(DoubleUp){
    long theValue = 0;
    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
                              "l", &theValue) == FAILURE){
        RETURN_STRING("Bad parameters!", true);
    }
    theValue *= 2;
    RETURN_LONG(theValue);
}

You should now be able to build the project without any errors. Be careful when renaming CustomExtModule or DoubleUp, and you must replace every instance in the file, or the Zend macros will yield nearly indecipherable compiler errors.

Enable the extension

The first step is to locate the \ext directory beneath your PHP 5 binaries (not the directory where you extracted the PHP source code). On my sample system this is C:\Server\PHP\ext. Copy the DLL that you just built to this directory. If you are going to attach a debugger to your extension, you will also want to copy the .pdb files.

The second step is to configure PHP to load your extension DLL. You do this by modifying PHP.ini, adding a

line to the Dynamic Extensions section, like the following.

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
[CustomExt]
extension=php_custom_ext.dll

Verify that the extension can be loaded

Once you’ve edited and saved php.ini, you may need to restart the HTTP server in order to pick up the new module. After the server is restarted, browse to the phpinfo.php web page. If you do not already have a phpinfo.php page, create one using the following text, and save it to one of your virtual directories:

<?php
phpinfo();
?>

Now browse to http://localhost/virtualpath/phpinfo.php, and look for the Additional Modules section. Your new extension should now be seen in the listing. If your extension is not listed, you may need to resave php.ini and restart the server. Also, make sure that the php.ini file that your server is using is the same ini file that you just edited. On most servers, php.ini is located in the PHP 5 installation directory, but your server may be different. To make certain, look at the information at the top of the page for the Loaded Configuration File entry, which shows the full path to the ini file PHP is currently using.

Write a test page

Copy the following code to testext.php (or download it ) , save it under one of your web server’s virtual directories.

<?php
$value = 14;
$result = DoubleUp($value);
print "Calling DoubleUp($value) returned $result";
?>

You can now browse to http://localhost/virtualpath/testext.php.

Debugging the extension

In order to debug the extension you need to attach the debugger to the running instance of the web server process. For IIS, this is w3wp.exe. For the Sambar server, this is sambar70\bin\server.exe. On the Project Properties dialog, under Configuration Properties > Debugging , set the following values:

• Command to the full path to the server executable
• Attach to “Yes”
• Debugger Type to “Native Only”

Stop you web server and make certain that you have copied the latest version of the extension DLL and the .pdb files to the \ext directory, then restart the web server. Set a breakpoint in the DoubleUp method and execute Debug > Start Debugging. You may get a message that the web server executable was not built with debugging information. Ignore this warning and click Yes to continue debugging.

Open a web browser and browse to your test page that calls the DoubleUp method. Your breakpoint should be hit. Step through the code, and be sure to use Debug > Continue (F5) so that the web server doesn’t hang.

To stop debugging, go to Debug > Detach All or stop the web server.

Where to from here?

The Zend API section of the PHP documentation provides a wealth of detailed information on the macros and functions available for extension development. And now that you’ve got your own extension up and running, you can finally make use of it! Some areas to explore are enabling your extension to accept configuration parameters from php.ini, and creating methods that accept multiple parameters, and/or optional parameters.

Managing Builds

Schema URL Mappings
 

We’ve been using CruiseControl.NET and NAnt for nightly builds of our products. Both technologies use an XML file format. SlickEdit’s XML features include Auto-completion of tags and attributes, gleaned from the definitions in XSD schemas. Visual Studio also has an excellent XML editing experience, but SlickEdit allows you to customize what specific XSD schemas are used for a particular XML namespace declaration. CruiseControl.NET does not distribute an “official” schema for their namespace, mostly because the CruiseControl syntax is extensible with a plug-in architecture. By using Microsoft’s XML tools I was able to take my existing CruiseControl project files and generate a starter schema. SlickEdit’s URL Mappings allow me to then use that custom schema for document validation and auto-completion.

In an effort to reduce redundant code and reduce the size of the NAnt source files, many common properties and tasks used by multiple projects have been broken out into a series of include files. However, locating a property or task that is defined in an external file usually requires a multi-file search.

Regex Evaluator

By using the SlickEdit Regex Evaluator I was able to craft a regular expression to search for task and property definitions. Once the expression was ready, I created a macro in Slick-C (SlickEdit’s C-like macro language)(snippet) to search for the word at the cursor in the current NAnt build file and any included build files. Now I have instant search across multiple files when the definition of a property or target eludes me.

Building Installers with WIX (Windows Installer XML)
WIX is an open-source toolkit from Microsoft for building Windows Installer .msi files. It too uses an XML file format. There are tools available in Wix for getting your project started and compiling your list of files to be installed, but authoring an installer still requires quite a bit of hand-editing the XML source. I use SlickEdit’s Aliases feature to provide completion of code snippets for commonly used Wix XML constructs. Aliases go well beyond simple insertion of prewritten code. You can configure an alias to format and auto-indent the new text, set the initial editing position, and prompt for replacement parameters.

Defining Aliases

All of the code for the installer is placed in a custom SlickEdit project. A custom project allows you to create as many organizational folders as you need, optionally organized by physical directories or file extensions. The real power in SlickEdit projects is the ability to define custom build steps to call external tools. Since this project invokes quite a few NAnt build targets, I customized the build menu by adding new build tools to the project. These allow me to invoke NAnt to execute the build targets and display the output in the build window.

Dabbling in PHP and MySQL, with a Side of PowerShell
A year or so ago, I worked on a side project to develop a content management website using PHP and MySQL. The application had to work with Internet Explorer, Firefox, and Safari browsers. Using SlickEdit allowed me to create a single project to organize the code and work with the Subversion repository located on a remote Linux hosting account. And I was able to edit the code on both a Windows XP tablet PC and my MacBook as the custom project format is identical on Windows and *Nix platforms. Customizing the project’s build commands allowed me to add shortcuts for opening pages in multiple browsers, execute MySQL scripts one the database, and transfer files via FTP to my remote hosting account.

PowerShell Syntax

SlickEdit supports dozens of languages out of the box, and has the ability to quickly add your own user-defined highlighting schemes or modify existing ones. I found that the default listing of SQL keywords didn’t include some of the MySQL keywords, but they were easy enough to add via the Color Coding options dialog.

For the past year or so I’ve been using PowerShell in place of cmd.exe, and steadily building a library of scripts to automate routine tasks. But it just didn’t seem right that such a neat shell language should have to be edited without any syntax highlighting. With SlickEdit, this was easily solved. To set up color coding for PowerShell, all I had to do was create a new language definition, specify the comment format, and add a list of keywords.

No Code Left Behind
These examples only begin to scratch the surface of the features available in SlickEdit. Your code or build process doesn’t have to be a second-class citizen just because it doesn’t fit neatly into Visual Studio. For all those times you have to “just edit it in notepad” or “run this tool from the commandline”, think of how SlickEdit could save you time and hassle.

Download Free Trial

You can download a free trial of Slickedit 2007 here: SlickEdit Trial

So, what do sports fans do during this down time. If they are desperate, they watch tennis, really desperate, maybe try to get into watching a soccer game. But, if you are exceedingly desperate, you invent a new tournament sport.

The Single Elimination Font Championship

It’s hard to pick a really good programming font. There are a lot of fonts out there, just google for “programming font” and you will find a lot of really great fonts, and a lot of really weird fonts. But how do you pick the best font?

Here is my grudge about font selection dialogs. They work in one of two ways:

1. They will only show you one font at a time.
2. They display the list of fonts in the font itself.This seems like a nice visual solution, except that it makes it impossible to
   decipher the font name of a symbol font or foreign language font.

Finding a good programming font seems to involve a lot of trial and error. Some fonts look great in the font dialog, but do not look very good in practice. Sometimes it is hard to read vertical spacing from the font dialog. Sometimes, the plain font looks great, but it’s italic or bold variant is horrid, and you do not notice that until you are using the font in your editor.

In this article, I am going to outline a design for a new paradigm for font selection that overcomes some of these issues, including the problem with there being no sports on TV.

Picking the contestants

The first step is to select a set of candidate fonts. This is where you use a traditional font dialog, with one modification to the font list: checkboxes so you can pick which fonts will participate in the tournament.

The Playoff’s

Once you have a set of contestants, you begin the playoffs. The fonts are assigned randomly into a single-elimination bracket. A slightly more thorough variation of the system could use double-elimination brackets, but I don’t believe it’s really necessary.

The font contests are head-to-head. You are shown a big dialog with both fonts, their names, a size selector, and six samples side-by-side:

1. The plain font with programmer-friendly sample text:

   1 2 3

   == Line before == Aa_Bb_Cc = (l1 + O0); == Line after ==

2. The font in bold with the same text.
3. The font in italic with the same text.
4. The font in bold and italic with the same text.
5. The font in underline with the same text.
6. An editor control with your color scheme displaying code
   in a language of your choice where you can paste in your
   own text to see.

Then you select the font that you like better, and move on to the next contest. The fundamental principal is that while it may be hard to select a favorite font from a list of 100 fonts, most programmers can look at two fonts and pick one that they like better than the other.

The brackets are played out until you reach the championship round and select one favorite programming font, which you will then have the opportunity to assign the champion as your default source window font in SlickEdit. Playing out the brackets with a single-elimination tournament requires (N -1) contests where N is the number of candidate fonts participating in the tournament. Even with a huge field of 50 fonts, you could finish in 15 minutes, and you would know that the font you are using is a champion. Which will leave you plenty of time to catch that spelling bee later on ESPN2.

Conclusion

“It’s so crazy, it just might work.”

This is merely a design sketch for a font tournament system. It’s not a feature that is being developed or even in the works, just an idea. If some industrious SlickEdit user wanted to exercise his/her Slick-C skills, it would be quite easy to implement, and would be a really great user-contributed batch macro.

I mean, what else are you going to do with your time? It’s not like there’s any sports on TV.

When I fix a bug in someone else’s code, sometimes I cringe at their coding style or lack thereof. On occasion, I find myself in some code that I can genuinely admire the clarity and attention to detail. I like to think of fixing bugs, in your own code, or in someone else’s, as a kind of spot-welding. The goal is to put in a clinically minimal change to fix the problem.

Here are a few tips for creating a clean, but strong spot-weld.

a) Adapt to the existing code style — whether good or bad

Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
    int foobar(int *arr[], int n) { 

        int i,count=0; 

        for (i=0; i<n; i++) { 

           if ( arr[i] == 0 ) { 

              ++count; 

           } 

           if(arr[i]<0)/*fix*/ 

                 { 

                 break; 

                 } 

        } 

        return count; 

     }

Different brace style, indentation, spacing around punctuation, and a nearly worthless comment, “fix”. The coder who put in this fix put his ego and love for his style ahead of consistency. One thing you will find about any programmer’s style: no matter what the brace style, no matter what the spacing preferences, in general, inconsistency is ugly.

b) Adapt to the existing naming conventions — whether good or bad

Granted, some people’s naming conventions are difficult, nay, impossible to recognize, but there are simple facets that can always be mimicked to improve consistency. Do they use mixed case? How do they use underscores? Do they use a naming prefix pattern? Do they use a naming suffix? What are some of the root words that represent the concepts being worked with?

Making your changes mesh with the existing conventions — whether good or bad — will make your changes fit in with the code around it and it shows a degree of professionalism. The code’s original author is less likely to doubt the quality of your change if it fits in.

c) Adapt to the existing structures and coding constructs

Example: You may use exception handling in all of your code. Programmer X may use return codes. When you do a fix in programmer X’s code, you should adapt to his constructs, even if you think they are archaic, because consistent, archaic techniques are better than inconsistent application of two very different techniques.

Another example: Don’t write a class to fix a bug in code that doesn’t use any classes, unless it is the only solution. Again, think of the concept of a spot-weld.

d) Beautify the code, but don’t check in the beautifications

If you just can not read a piece of code because of it’s style, go ahead and beautify it. But once you have a fix, revert back to the original style and merge your fix back in. This keeps the amount of change to a minimum which will help the next person who has to review the change history of that code.

e) Leave a note behind

When you fix a bug, leave your initials and the date with a short comment saying, “heh, I was here, I did this, and it was supposed to fix something.” That will save other people who see the code time when they are wondering who to blame (or who to give credit to). This is one area where I think it is ok to diverge from the existing code style. You should leave a note behind even if it is the only comment in the entire code base. You can think of it as good manners.

If not, then dang. You’re done reading. Go home, have a cold one.

Otherwise, you are in good company, so don’t feel so bad. Come down off the ledge.

What you really want — is to be able to fix bugs in one part of the code and keep the rest of the code functioning in the same working or non-working state it was in before. But the code is woven like spaghetti, and you swear under you breath every day that the guy who wrote it should have his fingers chopped off. This mantra makes you feel better, but unfortunately it doesn’t fix any bugs.

Unit Testing

It’s very academic. If the code had tests, then you could fix things, run the tests and know if things break. So, biting the bullet and knowing you are volunteering to spend your foreseeable future writing incredibly boring tests, you go to your manager and you say, heh, Bob, I’m gonna take six months and write thorough unit tests for this library, then we won’t have these horrid problems anymore. Of course, Bob is not excited about losing his star developer for six months and tells you no, you have more important things to spend your time on — like fixing the bugs you create by fixing bugs.

Next you ask your boss, maybe we could hire an intern to write unit tests? Your boss considers the amount of damage that could do to a young, idealistic programmer’s mind, then tells you no, can’t do that –in fact, it should be illegal, it’s cruel, like chopping off people’s fingers — you start to wonder whose side he is on anyway…

Why is it so hard?

Why are unit tests so hard to write and also so boring to write? That’s simple. The traditional approach to unit testing tries way too hard, because the traditional approach is focused on a proof of correctness. You start writing tests for APIs and then putting in a bunch of assertions with respect to the results, and the assertions are intended to capture 100% correctness.

There are two major problems to this approach.

1. It is very tedious.
2. You know that the code isn’t 100% correct to start with, otherwise, you wouldn’t be in there fixing bugs.

The result is that unit testing indirectly becomes a bug-hunting exercise, because you write tests, they fail, and you are left to figure out if your test is wrong of if the code being tested is wrong. You don’t want to go home until you have unit tests that cover a large part of the library, and pass. In the process, you wind up fixing several bugs in the code you are testing — which is really not what you wanted to do — not until you had complete tests.

If you have good will-power and a unit testing harness that supports it, you can avoid the bug fixing trap by simply ignoring test failures until the entire test suite is complete. Most people don’t have this kind of patience, because by the time you debug your unit test, and know it’s really the code being tested that has a bug, you probably also know how to fix it, and it’s hard to resist.

Status Quo

From Webster’s dictionary: Latin: the state of which. The existing state of affairs: also status in quo.

With the exception of the bug you are fixing, the status quo is precisely what you want for the rest of the code’s behavior.

So, without tests, how can you know that unravelling one piece of spaghetti code will not cause a metaphorical meatball to roll off the table? Bad news time. You can’t. You need tests and you need to be able to put them together fast.

Unit Testing by Status Quo

A solution to this problem is to design a way to generate unit tests that feed input to the existing code and captures the results. The key here is that you are capturing results — whether they are right or wrong — what matters is the status quo. Forget about proof of correctness. We’re looking for proof of same-ness.

Put the inputs and expected results into a harness so that you can re-run the tests and compare the new results with the expected results and know when something changes.

Once you have this harness in place you will become a scavenger for raw input, more test cases, to feed the harness. The more the better. The harness needs food. That will become your new mantra. That other guy can keep his fingers.

Using this technique, you can achieve a high percentage of code coverage with a minimal amount of effort. Also, since the code now has effective unit tests, you can now pass maintenance of the problematic library to another developer and know that they have some guard rails when they go in to fix bugs.

Managing change

With the status quo testing harness in place, when you make changes to the code, one of three things will happen:

1. All the tests will continue to pass. Either this is good, if the change was a refactoring or a performance improvement. Or, this is bad, it means that your fix didn’t fix anything.
2. There are tests that fail, and you expected them to fail because your fix was going to change the code’s behavior. In this case, you review the changes and regenerate the expected results.
3. There are tests that fail, and they should not have failed. Then, you know that you broke something, and you need to work more on your fix and try again.

Case Study

In the span of two weeks, I was able to assemble a huge battery of tests for one SlickEdit library that had a total of around 50,000 lines of code.

In this instance, the code being tested just took text as input and called functions in another library. In order to isolate the test code, and capture the results, I stubbed out the functions being called and replaced them with functions that just printed out their name and arguments. For example:

1
2
3
4
5
6
7
8
   void doSomething(int x, int y) 

   { 

      printf("doSomething(%d, %d)n", x, y); 

   } 

   void saySomething(const char *s) 

   { 

      printf("saySomething(\"%s\")n", s); 

   }

The results looked like a big function trace:

1
2
3
4
5
   doSomething(1,2) 

   saySomething("Hello") 

   doSomething(3,4) 

   doSomething(5,6) 

   saySomething("Goodbye");

Comparing the expected results to the actual results using a simple line-by-line differencing algorithm allowed me to zero in on test failures and quickly review whether or not they improved the status quo or not. Building a regenerate feature into the test harness allows me to quickly update the test suite after reviewing everything.

Before these unit tests, due to the code’s complexity, nearly every fix was a roller-coaster ride. Since the unit tests, we have had zero incidents of fixes introducing new bugs. It has also given us much more freedom to undertake refactoring and cleaning up the code, since we have confidence that even sweeping changes will be unlikely to cause major breakage.

Conclusion

Unit testing by status quo is a simple method for insuring continued code quality with a minimal investment in test development. It does not focus on 100% proof of correctness, but instead focuses on allowing you to make continuous improvements to a code base to push it uphill towards 100% correctness without allowing for sudden backslides and unexpected breakage.

At one time, we might have used the word “hacker” to describe these people. Unfortunately, this term has become confused with those who break into computer systems, and its meaning has been weakened with connotations of inelegant or unskilled approaches. Instead, let’s call them “Power Programmers” for their particular approach to programming.So, just what is a Power Programmer? A Power Programmer is a person with a passion for coding, expertise in key areas of programming knowledge, and a bias toward working in the fastest, most efficient manner.

Passion for Coding
Power programmers love to code. They code at work. They code at home. They code for the sheer thrill of making something run. Because of this passion, they have generally written a lot of code, far more than someone who is just doing it for a living.It is, perhaps, the volume of code that they write that drives much of the rest of their traits. By writing so much code they have been exposed to a broader range of problems than other programmers, giving them a greater repertoire of ready solutions. They are also faced with the same problems over and over again, giving them a greater opportunity and justification to seek the best solutions to those problems. Experience allows them to solve problems more quickly.Together, passion and practice often produce expertise, and expertise is an essential characteristic of a Power Programmer.

Expertise in Relevant Areas of Programming
Expertise produces highly effective results, programs that are robust and efficient, not just something that runs. It is this expertise that puts the “power” into power programming.Programming knowledge covers a very large area, and one that is increasing every year. There is general knowledge, like knowledge of a particular language. And there is more specific knowledge, like knowledge of a particular API or a technology, like XML. You cannot say that knowledge of any specific language or technology is a requirement to be a power programmer, but you can say that there are key areas of programming knowledge that are required.

Mastery of the Programming Domain
Define a programming domain as the combination of language(s) used and the APIs for the target platform. Someone can be a master of one programming domain, like writing C++ using the Microsoft Windows APIs, yet have no knowledge of another, like coding in Carbon on the Apple Macintosh. Though no single domain can be listed as required knowledge to be a power programmer, mastery of the domain in which you work is required.Power programmers have a mastery of the syntax and idioms of the programming languages they use and are sometimes referred to as “language lawyers”. If you want to know about effective parameter passing or when to favor an iterator over a for loop, go ask a power programmer. Ask an object-oriented power programmer whether they would ever make a destructor virtual, and they won’t just answer “Yes”, they’ll answer “Heck, yeah!”Programmers love to debate the relative merits of different languages, platforms, and APIs. You can still find vigorous debates over big endian versus little endian. However, no one programming domain has a monopoly on power programmers. You will find them everywhere.

Knowledge of Computer Science Theory
Knowledge of the underlying principles of computer science is applicable to virtually any programming task. Power programmers show an unusual affinity for this knowledge.One important aspect of this is knowledge of data structures and when each is applicable. Power programmers love data structures. You will rarely see them so happy as when they are pondering the relative merits of a hash table versus a red-black tree. And it’s not enough for them to know how to use data structures; most are compelled to know how to implement them as well.Power programmers also have a burning interest in algorithms. They can tell you the Big O notation for all of the common sorting algorithms. They understand what makes code run faster and how to isolate and fix performance problems. Few things are as upsetting to a power programmer as an inelegant algorithm.There are certainly other important areas of knowledge to power programmers, but the core knowledge can be identified by applying the Knuth Test: if it appears in one of Donald Knuth’s volumes in The Art of Computer Programming, then it’s probably important to a power programmer. In this area of knowledge, Dr. Knuth is probably the ultimate power programmer.

Knowledge of the Tools of the Trade
For programmers, the tools of the trade include editors, compilers, debuggers, make systems, source control systems, and various utilities like grep or diff. Power programmers show a mastery of these tools.Since the editor is where programmers spend most of their time, power programmers are unusually particular about their editor. Often, they have gone to great lengths to customize it to work the way they think is best. They look for facilities in an editor to avoid using the mouse, to reduce keystrokes, and to automate common operations. For a power programmer, the editor is an extension of their mind, allowing them to manipulate code with little thought about the actual mechanics used.

Hunger to Learn
Regardless of the programming domain, power programmers show a hunger to learn. They suck up programming knowledge like a black hole swallowing star systems. They are often trying new techniques or experimenting with new programming languages. You frequently see them reading books about programming. This learning fuels their passion for programming and provides them with the knowledge to be more effective.

Working in the Fastest, Most Efficient Manner
If you watch a power programmer work, you see a whirlwind of activity: windows opening and closing, text being manipulated, scripts being run—all at an incredibly rapid pace. This pace is possible due to their mastery of the tools they use, and it is driven by their passion for coding.Power programmers love to code. But this love is not for the act of coding—the actual typing of keywords and symbols—but for the thrill of creation. The act of coding, itself, is often viewed as tedious so they look for ways to automate frequent operations and eliminate repetitive typing.By working faster, power programmers are able to write more code. This creates a feedback loop. By writing more code, they learn more and become more effective, which allows them to work faster and write more code…If you ask a power programmer if they prefer to write fast code or write code fast, they will always answer “yes”.

Am I a Power Programmer?
It is not our place to decide whether you are or are not a Power Programmer. That’s for you to decide, just as it is for you to decide your own criteria by which to judge this. The act of introspection is more important than whether or not you meet any single definition of Power Programmer. Growth in any field of endeavor depends on examining your knowledge and abilities and setting goals for areas of improvement.So, who’s the best programmer you ever saw? Even if you have a long way to go, you’ll be able to answer, “You’re not looking at him, but I’m on my way!”

In programming, however, the mouse can be one of the greatest productivity sinkholes. Time is wasted each time you lift your hand from the keyboard to grab the mouse, and more time is wasted when you move your hand back to home row in preparation for more typing.

So what’s the solution? Keep your hands on the keyboard! To do this use the SlickEdit^® command line and bind commonly used commands to keys.

Launching Operations

SlickEdit provides three ways to launch operations: key bindings, commands, and menus. OK, there are actually four, if you include icons. Since the focus of this article is how to keep your hands on the keyboard, I was going to skip that one.

Key Bindings
Key bindings are the fastest way to launch an operation. They can be pressed at any time while editing. A key binding associates a key sequence with a command. A key sequence is a series of key strokes. Anything you do frequently should be bound to an easily remembered key sequence.

For example the key sequence Ctrl+A means hold down the Control key, typically labeled “Ctrl” on most keyboards, and press the A key. The letter A is represented as an uppercase letter, but this does not mean that you are to press the Shift key. If you are supposed to press the Shift key, the sequence will be written as Ctrl+Shift+A.  We use the uppercase A to match the letter on the keyboard.

Commands

Commands are useful for less frequently used operations or operations that take arguments. They are executed from the SlickEdit command line and are nearly as fast as key bindings. Press the Escape key (in most emulations) to activate the command line, which is displayed at the bottom of the SlickEdit application window. 

  Figure 1, SlickEdit with Command Line

It offers a full command history and completions for command names and arguments. Use the arrow keys or the mouse to scroll through previous commands. As you type, a list of possible completions is displayed. Use the arrow keys or mouse to select a completion. SlickEdit stores recorded macros as commands. You can also use Slick-C to write new commands. Use the _command keyword to identify a macro as a command. Any command can be bound to a key sequence for faster launching. 

Menus

Menus are accessed via the mouse or a keyboard shortcut. Menus are great for infrequently used items that may not be worth a key binding. They are also helpful to learn about new capabilities. But if you use an operation frequently, you will be more productive by binding it to a key sequence or launching it from the command line. Many menus list a keyboard shortcut to launch the operation. This is just the key binding for the associated command. So when you use a keyboard shortcut, you are really just using a key binding.

You can also operate the main menu through hotkeys. Enable the use of hotkeys by selecting Tools > Options > General, selecting the General tab, and putting a check in “Alt menu hotkeys”. This will be selected by default in many emulations. Once enabled, pressing the Alt key will display an underscore beneath each menu option, indicating the letter to press to activate that option. This is not as fast as key bindings, but it does keep your hands on the keyboard and is much faster than using the mouse. In some cases the menu hot key sequence is a good mnemonic for the command. For example, Alt+P, E (to bring up Project > Properties) may be easier to remember and type than binding project-edit to Ctrl plus some function key. 

Icons

SlickEdit presents icons in a series of toolbars related to different tasks. Toolbars can be customized with an extensive set of additional icons. Icons are useful for die-hard mouse users or for setting up infrequently used operations for which you have a hard time remembering the associated command or key binding. 

The Golden Triangle

The three methods (excluding icons) to launch an operation are related, forming the Golden Triangle of operation launching. If you know how to execute an operation with one of these, you can easily configure SlickEdit to launch the operation using the other two methods. Commands form the base for the other two…which is why it is shown as the apex of the triangle (Damn it, Jim, I’m an engineer, not an artist!). Maybe I should have used a Golden U or something. 
 

Figure 2 the Golden Triangle; behold its majesty!

From Key Binding to Command

Sometimes you may want to change the key sequence to which an operation is bound. You first need to find the command associated with that key sequence. Use the what-is command from the SlickEdit command line or select Help > What Is Key from the main menu. The command line will be replaced with the prompt, “What is key:” Enter the key sequence in question, like Ctrl+A (hold down the Control key and press A), and SlickEdit displays the associated command. In CUA emulation, SlickEdit will output, “Ctrl+A runs the command select-all”. You can use the same approach to determine the commands associated with mouse events. After you run what-is, click any mouse button and you will be prompted with a list of mouse events. Select one from the list and SlickEdit displays the associated command. For example, if you select mbutton-down in CUA emulation, SlickEdit will output, “MButtonDn runs the command mou-paste”. 

From Command to Key Binding

To find the key binding for a command, use the where-is command or select Tools > Options > Key Bindings from the main menu. The where-is command works just like what-is, except you type in the command name and it outputs the key sequence. The Key Bindings dialog displays a list of the commands. You can scroll through the list or search for a command by typing the command in the text box at the top. The key binding for the selected command is displayed in the dialog.  

Figure 3, Key Bindings Dialog   

Modifying Key Bindings

The Key Bindings dialog can also be used to set a key binding. Type the command in the Command field, or select one from the list. Then click the “Add Key or Mouse Click” button. Now type the key sequence you want to use. For example, to bind a command to Ctrl+A, hold down the Control key and press A. To bind a command to a mouse event, click any mouse button and then select the appropriate event from the list. When you are finished, click the Bind button. To exit the dialog, click Done.

From Menu to Command
If the menu entry displays a keyboard shortcut, you can quickly find the associated command using what-is and entering the key sequence. If the menu entry does not display a shortcut, then finding the command for an entry involves a little more work.

SlickEdit provides a convenient UI under Macro > Menus that allows you to view and modify menus in SlickEdit. To find commands for the items on the main menu, select “_mdi_menu” from the list and then click the Open button. You are presented with a menu hierarchy that you can expand to find the menu entry in question. Once selected, information about the entry is displayed including the command executed. You can use this menu to add or change the shortcut for a menu item. Doing so has the same effect as using the Key Bindings dialog to bind the menu entry’s command to a key sequence.   

Figure 4, Menu Editor

Some menu entries are added dynamically by SlickEdit, so you may have to search the code to find the associated command. One example of this is Build > Java Options, which is only present when a Java project is active. Unfortunately, finding the associated commands for these entries can be very difficult and not easily covered in an article like this.

Context Menus
It is also easy to find the commands in the context menu for the editor window. The context menu, itself, contains an entry to “Edit This Menu”. Selecting this option brings up a dialog that lists the menu entries and associated information, including the command. Use this dialog to modify the context menus. Note that there are two context menus for the editor window: one when a selection is made and one when no selection is made. You can view or change the function that is used for these menus by selecting Tools > Options > File Extension Setup and selecting the Advanced tab.

From Key Binding to Menu and Back
Menu entries map to key bindings through commands, so key bindings are not directly associated with menu entries. To map from a key binding to a menu or vice versa, you need to look up the associated command. That Golden U is looking better all the time!

Customizing Toolbar Icons
The focus of this article has been to help you keep your hands on the keyboard, so icons weren’t included in the Golden Triangle. Besides, then I would have needed a Golden Square or some other form of rhombus, and that just doesn’t sound cool. You may find it helpful to change the set of displayed toolbars, add or remove icons, or change the behavior for an icon. SlickEdit uses the term “toolbar” to refer to both icon bars and tool windows. To change the set of displayed toolbars, select View > Toolbars and check/uncheck one of the listed toolbars. The list is divided into two groups. The top group is comprised of tool windows, like the Symbol view and the Projects view. The bottom group is made up of icon bars.

Additional options are available on the Toolbar Customization dialog by selecting View > Toolbars > Customize. The Toolbars tab provides a way to control the visibility of the toolbars. The Toolbars tab allows you to set options for which toolbars are visible, whether they are dockable, etc.

The Categories tab displays the complete set of available icons. These can be added to any icon toolbar by dragging them to the desired location. All of the icons have pre-defined behaviors, except the set in the “User Definable Tools” category. Use these to add your own functionality.

Each icon has an associated command that defines what happens when it is clicked. To view or change that command, right-click on the icon and select Properties. The icon needs to be located in a toolbar to do this. You cannot access the properties for an icon in the Toolbar Customizations dialog.  

“Exit, Stage Left”

OK, that one is a Snagglepuss reference[ii]. Whatever angst I previously expressed for mice has now been transferred to the Golden Polygon of Unspecified Dimensions. Regardless of the shape, you now have the tools you need to configure SlickEdit to work the way YOU think it should, using the key bindings you find natural. This is one of the essential steps in being a true power programmer.
 

[i] Mr. Jinks, sometimes called “Jinks the cat”, appeared in the “Pixie and Dixie” cartoons as part of “The Huckleberry Hound Show”, by Hanna and Barbera.

[ii] Snagglepus is another of Hanna-Barbera’s cartoon characters.