Ian Baird posted an interesting link in the #macsb channel last night. The author asks why we don’t make use of simulators and design tools when writing software.

There are several reasons why.

Programmers don’t want to change the way they work.
Mythical super-programmer. Cowboy. Lone wolf. We tend to adopt the hubris of our heroes even though we haven’t attained their level of achievement.

Major is Minor. Programmers don’t design software in an architectural sense. There is no grand scheme, no big wall of interaction diagrams used to document how classes and objects interact. We tend to design on a bottom-up basis. The design is embodied in the text we write. The documentation is the code.

Minor is Major. Programmers like to focus in discrete units of code we can parse at once. The smaller the unit we can interact with at once, the smaller the unit of code we write. Functions, or modules, have been shrinking as we’ve moved from punch-cards and printouts to TTYs to GUIs. It isn’t just that we’ve learned that reducing function size and behavior improves comprehension. The fact is the reduced visual workspace requires us to improve code comprehension!

Code operates linearly, or sub-linearly if you compact several statements onto a line or make abundant use of ternary operators. Programmers love to do that because it’s detailed. We love cute little tricks like obfuscation because they’re details. But it isn’t readable, and it isn’t professional.

Programmers are the detail-oriented, step-by-step kinda guys whose focus is on the specifics. We hate ambiguity. We have to understand things before we’ll do anything. This is why any design document on a system’s organization quickly degenerates into the use of linked-lists or DB schema or some such implementation details irrelevant during the planning stage. It’s why programmers argue incessantly over trivial issues and attempt to refute assertions with minutiae. It’s also why debugging involves figuring out the why one part of the system clobbers another: we forget the details of other pieces and how they interact.

This is the main reason why different languages rise to prominence over time: each offers a new level of detail the prior language did not. It introduces some abstraction, paradigm or need that is unmet in the old language and its repertoire of code.

Programmers are afraid to change the way they work.
We already have UML and Nassi-Schneider diagrams and flowcharts. Some programmers might draw one up for a quick back-of-the-envelope idea of how to get the function to work, but they’re not an integral part of the development process. The documentation isn’t kept around. The writing tools used by programmers is little better than the tools used by other writers of fiction. Look at the markings on a printout of code and you’ll realize there’s been little changed from the techniques used from before the time of Shakespeare. Why is this?

Programmers can’t change the way they work.
It’s because programmers are literally oriented. Both literally and figuratively. As our tools are text-based, the persons attracted to the profession are people who think literally, and not visually.

As much as programmers have changed the way other professionals work, there’s been little acceptance for the transformation of our own industry. Text-oriented tools attract text-oriented people who write more text-oriented tools and keep the cycle repeating.