Monday, July 24, 2006

The Key to Programmer Productivity (That everyone overlooks!)

Digg This!

It's the development cycle! What exactly do I mean by development cycle. This is the time it takes from the point a code edit is completed to when the developer can see the results of the change. This could be through a unit test, hitting a break point in a debugger, or manually checking the results. Why is this so important?

Way back in the early 90's I was fortunate enough to spend some time at AT&T Bell labs. I was amazed when I was looking through the company directory and there was "Ritchie". Yes, that Ritchie, Dennis M. Ritchie one of the authors of "Programming in C". Possibly the best programming book ever written. I never did meet Dennis. There were also some very interesting people on my team. One of my team members was a tester on one of the first releases of Unix. We were chatting about the first computers we worked on. He had me beat. He mumbled something about punch cards and then he said something that has stuck with me over all of these years. "compilers are better at reading code than developers." While this may seem obvious and somewhat trivial. If you really think about the implications of this simple fact; it will change how you look at development.

One of the obvious implications is that the compiler will detect a syntax problem long before a developer will. The time it takes to compile has been reduced by performance increases over the years. Now, this implication is relatively moot with background compilation. At least for some languages and environments. However there is another implication. When I first started writing code. I wasn't actually writing it. I was typing it in from listings in magazines and books. I was learning to code. After typing in hundreds of programs I got better at typing and catching errors in transcription. Eventually I even found errors in the code in the actual listings. One of the skills that improved dramatically was my ability to spot the problem area and the actual problem. I became very proficient at finding errors. This was important because it took so long to edit and compile a program. If I guessed wrong there was a large penalty in time before I could try something else. The development cycle was a long one. Time was better spent double and triple checking your code than watching a build. This has changed over the years. We as developers gain performance and then it is taken away (this may be a topic for another post). This can still be an important skill on large projects. There is no better way to lower your productivity than to make a typo when you are in a long development cycle. On small projects it is more efficient to just run it. That old axiom still holds true. The important point that can be derived is that the development cycle should be as short as possible because the compiler is better at finding syntax errors, and test cases and debuggers are better at finding logic errors.

A development cycle is the time it takes to make a code change to the time the developer can see the results. This cycle determines how many changes a developer can make in a coding session. The shorter the development cycle the more changes a developer can make. The more changes a developer can make the closer they can get to making the code work correctly in a given amount of time. Another advantage to a short development cycle has to do with something sometimes referred to as the "zone". Being in the zone is when a programmer is completely immersed in development and performing at the best of their ability. Long development cycles have longer periods of time where a developer is waiting to see the results. This can lead to distractions that can take a developer out of the zone. After a fifteen minute build I am almost always out of the zone. I usually try to get back in the zone by saying to myself, "Now where was I?" A short development cycle does increase developer productivity.

The development cycle has some other components as well. The amount of source code plays a role not only in compilation times, but also in edit times. It takes a longer amount of time to locate the code that needs to be edited in a big program than in a small one. The deployment environment also plays a role. If the program must be deployed or published this adds to the development cycle. This is especially true of web server applications where the server must be restarted. That extra minute can cut productivity in half. Let me say that again in more specific terms. Developing an application that needs to be deployed to IIS or JBOSS will cut programmer productivity in half.

Certain languages and development environments have become extremely popular. Let's look at the often loathed Visual Basic first. Let me state outright; I like VB. I heard a collective groan. True it has many short comings. It doesn't do X, Y and Z. So why was it so damn popular? I'll share why I think it was so popular. I have written code in many, many languages on many platforms. VB had at one point the shortest possible development cycle. The ability to almost instantly run a program and edit the code in the debugger does wonders for the development cycle and programmer productivity. I believe this was one of the key reasons VB enjoyed the success it achieved. The other being the simplicity of the development model especially in regards to database development and the windows event model. This also has a lot to do with why ruby and ruby on rails is so popular. The same goes for python. I think the languages themselves although concise are secondary to the short development cycle. Java on the other hand typically has a long development cycle for web development compared to ruby on rails.

Why it matters. It matters because the development cycle impacts productivity. It impacts how long a piece of functionality will take to build. So estimates need to take into consideration the length of the development cycle. Developers should look at their development cycle and optimize it as best they can within the constraints of their environment.

Rasch On Tech