Force Multipliers...

When I first got out of college, my first job was with a small group of 'lone gunman' programmers. They had developed a PC based 911 system over the course of a year or so. It was robust, had many nice features and options and was easy to maintain. It was a few months before I found their major competitors where huge companies with dozens to hundreds of programmers. At the time I just accepted that the lead programmer, a grizzled HAM radio enthusiast, was just that good. Looking back on my career, however, I have seen larger groups get less done while working around the clock. Now that I am attempting to start my own software project, I have become obsessed with finding the reasons for this.

In the military, things that improve your forces' ability to fight are called force multipliers. The idea is that a person has a finite amount of force which can be used. Using them in certain ways makes them more effective. Using them in others makes them less effective. An example is keeping your men in better shape than the enemy's men. A much better example would be a small team using the cover of darkness, night-vision goggles, surprise, flares (for blinding the enemy), automatic weapons, planning, cover, artillery, tactics, armor, diversions, and traps. The first example may have saved a few lives in a war. The second would allow a few men to destroy a much larger force.

In software development, force is about getting a project completed on time, within budget, and to an acceptable degree of quality. It's a balancing act, but if you ask your customers what is most important they will tell you all three. Therefore, anything that increases your speed and complexity or lowers your cost is a multiplier. Anything else that takes time, money, or complexity is a divider. Also, the best multipliers effect two or all of these. Let's look at a few that I have seen.

Tools: Software is built from software tools. A good tool can increase your productivity while a bad tool will have you searching for work-arounds. There are many types of tools but here are the most important in software development:

• Language and Compiler
  
• Text Processor
• Build System
  
• Source Code Control System
• Change Request/Bug Reporting System
• Debugger
• Testing Tools

The language you choose to develop in has three components: abstraction, familiarity, and efficiency. Abstraction allows the programmer to think higher level thoughts. Imagine having to multiply in assembly, every time you would have to move the data into each register, multiply those registers, check the overflow flag, if there is an overflow deal with that, move the data to where it will be kept and possibly return an error! Compare that with typing "a = b * c;". Familiarity is how well the programmers can program in a language. Haskell might be a better language for a system, but I know C right now so I can get started. Last is efficiency, or how much code is needed to get something done. Every line of code takes time to write and time to debug. I like C++ but I can create a GUI without a few lines of code in Visual Basic.

Your text processor will play a large role in your projects. A good tool like emacs or vi will give you options you never had before; such as indenting code, adding files and classes, and moving blocks of code. If you have ever had to manually do anything a dozen times or more find a new editor. Your build system will make or break you at the most important times. I recommend "make". It's been around since the dawn of computer time for a reason and I can't tell you how many times I have had to argue with an IDE to get it to compiler my code correctly. The other tools have similar effects so choose wisely.

Then there are development techniques. One of the best is writing a set of tools to build your application. A simple example would be a command line interface to the main functionality. This can be used to automate testing though a script, outputting run time data, separating parts of a program, and even getting people to use your application while it is still in development. Another might be a code generator so you don't have to repeat a creation step twice.

Planning, however, is a waste of time. Although it is important to get your requirements in writing, trying to visualize every aspect of an application will usually fail except in very simple programs. I don't know how many times I have scrapped a design because people wanted it to do more once they saw it. There is an old riddle, "How far can you walk into the woods?" The answer is "Half way, after that you are walking back out." When designing software, you need to be flexible to try new approaches. There are usually a few core parts that can be used independently. These are the tools you can use to build a simpler system.

Finally, the best way to get more code done, is simply to start coding. Now. I mean it. Really. Why are you still reading this? Everybody, out of the internet and get started!