What's Wrong With The Way We Write Software?

Lately, I've realized that when discussing "what's wrong with the way we write software?", that I've been starting out on the wrong foot. The clue is in the question: there's not really that much wrong with the way we write, it's all to do with the way we design. (Caveat here: I've been drafting a post about what's actually wrong with the way we literally write software too, so we're not completely off the hook.)

This shift in viewpoint is coupled to another misnomer about software development that we regularly need to challenge our business sponsors on:

If you're not typing, you're not developing

This has been covered very well by various authors, so I won't go into it (but if you need some ammunition, then read up on it - I wish I could readily remember where the best starting point would be).

It has been said that one of the original flaws in the emergence of the field of "software engineering" was to compare the act of creating software to the act of production in other engineering disciplines. This has since been recognised as not the case, and that in fact our production/assembly/manufacturing/building cost is practically nil and almost entirely error free, because it's just compiling, linking and deploying the software. (OK, deployment of some software has its challenges, but if we imagine the simple case of uploading a package to your website for people to purchase and download, then it's pretty trivial.) The act of writing software is of course the design process, as the code is effectively a detailed specification of the program that the compiler turns into executable code.

So why do we still talk about "writing" software? I suppose it may be because most people tend to design at least partially "on screen". I've met few people who design without the use of at least some skeleton code, to allow them to sketch out the way interfaces might look, or look for creative solutions in the way they might put together some template code for instance. It's pretty hard to purely "think about" some aspects of software design at the detailed technical level, because we're not very good at holding the full problem in our heads, and we're pretty rubbish at remembering language specifications in sufficient detail to get it right without having to type it out at least once. The detailed job of assessing some facets of technical design is after all best left to the compiler.

However, it's said that our creativity could benefit from freeing ourselves from our monitors and keyboards and using other media and involving all of our senses (see Pragmatic Thinking and Learning for some good ideas here). Time at the white board, sticky notes, paper cut-outs, Lego bricks, even role playing all have a place here. (I found that some paper cut-outs of a mouse pointer, some icons and basic graphics components were of great help in designing a new interaction idea lately).

I perhaps digress from the main point here, so lets try and get back to it. I can see - in my way of thinking about it at least - that making the conscious decision to stop talking about writing software, and instead talking about designing it could have a profound impact on how effective this process is. The reasons are intrinsic and extrinsic to the development activity:

• Intrinsically, we can be more creative in design and perhaps more productive if we release ourselves from the idea of developing software purely in text, at our screens. Free your mind and the rest will follow, as the song goes: let your creative, non-logical side in on the act and you'll double the brain power available, not to mention, maybe enjoy yourself a little more.
• Extrinsically, if those around us understand the process as one of design, (but with the necessary and quite mundane constraint that it is translated into code to be compiled), then they may be better placed to support us in this activity. Fundamentally, the idea that "thinking time" is more important than "typing time" can germinate more easily, and also, supporting resources and activities might become more available.
• Moreover, perhaps we can more readily engage non-developers in the technical design process if it is more accessible: product managers, analysts, UI designers, testers, support staff, technical writers and so on. If the design meeting is Lego and playing cards, then there's no barrier to inclusion, as almost everyone can get on board with these sorts of design metaphors.

If we shift to talking about designing software, then perhaps even the tools we use might change. An IDE who's primary form of interaction is a UML diagram, dependency management tools that simply involve changing an "efferent arrow" to an "afferent arrow" (and do the necessary dependency inversion under the hood for you), containers that really look like containers, who knows. One thing's for sure though, if we encumber ourselves with the dogma that we must carry on typing at all costs, then even if some mysterious benefactor chooses to create these tools for us, we might miss them.