John Wood

Why Programming is Hard

I'm certainly not the first to rant about how hard programming has become.

Programming is a surprisingly arbitrary art. The countless decisions you have to make in the process of writing code in your programming language are more often than not finger-in-the-air.

Lets look at some of these decisions:

1. Naming. Naming of classes, namespaces, assemblies, enumerators, variable names, parameter names etc.

2. Methods granularity. At what point do I decide to move a portion of procedure A into a separate procedure?

3. Interfaces and abstraction. Should this class be an interface, will it be implemented elsewhere? Or perhaps it should be a base class? Or perhaps it should be an abstract class?

4. Code layout. Do I put my methods in alphabetical order? Do I group interface implementation methods together? Do I just put methods anywhere because it's just not important?

5. Commenting. Does this line justify being commented, or is it clear already? Who's the audience anyway, and what level of expertise should I expect them to have?

6. Re-use. I have to write X. Do I modify and use the very similar Y code, or do I just write X again because modifying it will break other code or be more hassle than it's worth?

7. Testing. It's simple code, does it *really* need a unit test?

I'm sure there are a lot more decisions than that too. And then there's GUI code, in which the decisions just explode in number because of the seemingly infinite possibilities that are available in what we can present visually.

The problem is there are a vast number of choices for each of these decisions. Given the number of programmers and the number of problems to solve, you can imagine that nearly every choice has been tested by someone.

This is what makes software complex.

Imagine if when a town was built, the construction workers for each street could decide on the type of material to use, the shape, color, width, lighting etc. to use when building that street.  You would quite simply end up with a collage of streets that wouldn't properly connect with each other. Now consider how that would complicate trying to drive around the town and you'll get an idea of how decisions complicate software.

These decisions also take time and time is money. Decisions make software expensive. What's more, most of these decisions are really a bad use of time. They're time spent on problems that are mostly irrelevant to the problem domain at hand. They're small change. Every minute spent thinking about a name for a method is probably a wasted minute.

Programming languages are too general, that's a big part of the problem. They're flexible in order to meet the needs of the diversity in software that needs writing, and the diversity in opinions on many of these decisions.

But sometimes you just have to say enough is enough - the street will be X feet wide. Stop the debate. Coding standards help here, but we need more than just standards. People rarely obey standards unless they have a gun pointed to their head. We just need less flexible languages. IDEs that keep our methods in a specific order. That better understand the code to help us name the method. That know when a method can be re-used, or is getting too large, and should be split up. And when it doesn't understand something it should mandate a comment. GUI frameworks that don't give us the opportunity to decide on what color to make this button.

(side thought - WPF is really a step backwards there, in WPF you're also left with the decision on whether you should make your button dance in 3D).

The IDE understands too little about what we're writing and until it wises up a little, and starts making decisions for us, programming won't get any easier and software won't get any simpler.

End of rant.