Kill Your Children

The fiction of software

By Julian Browne on August 14, 2007. Filed Under business, delivery, strategy

A classic sign of inexperience in creative endeavour (or perhaps any undertaking) is the inability to 'let go' of your best ideas. Rookies, will come up with a concept, lovingly craft their baby, and refuse to be budged even as the world around them changes. Despite market forces, advice from experts, they continue to add ever more baroque extensions to their now irrelevant core, never questioning whether their foundations are still appropriate. What often results is largely unintelligible and difficult to enhance and maintain once they learned their lessons and moved on.

This is true of software architecture and code as much as it is of fiction.

In one of my other lives outside software, I write, and to some extent study, narrative fiction, and am something of a devotee of John Gardner, the man who heavily influenced Raymond Chandler in his formative years. Although not as commercially successful as his protégé, John Gardner's books on how to approach writing are succinct and timeless directives on the delicate process of harnessing the imagination and applying it to the business of production. Something that applies to hacking as much as it does to short stories or poetry.

Without wishing to boil his life's work down to a few bullet points (although as an advocate of the minimalist approach, he may well have approved) many of his edicts can be generically represented by the assertion that text (code), is cheap. By that I mean experienced individuals soon come to see that even the most beautifully structured text (code) is replaceable and throwaway. Seeing this allows them to adapt and go with a flow of ideas, to closely couple what is done to what is needed. It's the idea, or the concept, or the requirement, that is king, not the first realisation of it you came up with. Which great art work didn't go through tens, or hundreds, of revisions to reach perfection?

Great code invariably has to go through many revisions, not just to meet changing requirements, but also to fix bugs and support ongoing maintenance. I'm not convinced there will ever be a simple way to auto-generate the complete source code required for an application from a business-level model, but clearly the pursuit of this aim (coding without coders) is also the pursuit of cheap, throwaway, replaceable code. The 'model' is the idea and the 'code' is relegated to the cheap and cheerful instantiation of it. Change the model, click a button, change the code.

I don't think full auto-generation will come, because the inputs to the model originate from a source too capricious to submit to the modes of engineering - other human beings. Donald Knuth recognised this decades ago, describing software creation as an aesthetic experience more like poetry or music than building office blocks.

Our customers might expect or wish us to exhibit the predictability of engineers but, on so many occasions, what they get is the result of self-indulgent political pettiness and unmanaged precocity.

You can't completely tame creativity, and neither should one try, but you can remain mindful of the desired end result. If authors can produce prize-winning novels to order, and sculptors make millions in the whimsical art market, then hackers can surely follow suit.

And it's all about killing your children.

• Kill Your Children

  No matter how much you love what you have written, see it as dispensable at the altar of the greater good, and the bigger picture.

• Kill Adjectives and Adverbs

  Just as it is in writing, it is in code. If you can say it with fewer words, say it with fewer words. It will be more readable, and much much easier to maintain later.

• Write Something Every Day

  You will only see code (words) as cheap if you write them often. If it takes you three hours to craft a function to parse a string, you will be more inclined to modify it rather than chuck it away when the requirement changes to parse an associative array. If you don't get to write code as part of your day job, do it for fun outside. Teach yourself the basics of emerging languages to see how paradigms are shifting.

• Write Like Nobody's Watching. Edit Like Everybody Is

  Sometimes you just have to get an idea out. In creative fiction this is like exorcising a demon, and once it's on the page you are released from its spell. It doesn't really matter whether what comes out is great, good or dog-do. You will have learned an imperceptibly small amount just by doing it. If it's great you can keep it, but if it ain't then you know what to do..

• The Author Is Dead

  An oft-discussed notion in creative fiction, emanating from French literary critic Roland Barthes, is that the author is 'dead'. Once the words are out and on the page, it is what it is: an artefact to be interpreted and used by the reader, without reference to the author. This applies to code in the most visible of ways.

  On any major software project, with touch points into legacy systems, it's rare that the authors of that heritage are still around. They're more likely to have taken a pay rise and gone elsewhere, than to be dead in the conventional sense, but to all intents and purposes they are unavailable to the next generation who must read, interpret and extend the inheritance.

  Understanding your impending, though figurative, demise is a useful notion in making good software, as it enables you to put your affairs in order so that those who come after can have a better life, and in doing so be thankful that you left them with an elegant code base on which to build the new world.