Friday, September 04, 2009


Human progress seems to be a fairly inefficient process. People acquire knowledge and experience throughout their lives (~75 years in the developed world) and then, quite suddenly, they die and take it all with them. Some of it is passed on and occasionally some of it is written down and preserved; but most of it is irretrievably gone. Even that which isn’t lost is often ignored so that the next generation can make the same mistakes all over again. Every generation’s children swagger forth into the world, heedless of their parents’ warnings and advice and only later in life come to realise that they were probably right all along. As far as generalisations go, this is about as safe as they come.

It’s hard to put a number to it, but the effort-to-result ratio would be dreadfully low.

This thought came to mind after this rather eventful week at the office, which consisted mainly of pushing out a major software update and then ironing all the unforeseen issues that threatened to bring all business to a halt. The whole thing was needlessly haphazard. There is a wide array of best practices, processes, methodologies and tools to deal with these sorts of issues. But rather than learn from the experiences of those who came before us, we instead charge headfirst into new situations and learn only from our own scars and bruises.

It wasn’t until code changes were being blown away that we realised the need for source control, a tool first invented in the 1970s (3.75MB PDF). It wasn’t until the burden of maintaining hotfixes in the midst of a huge update became too great that we even considered branching and merging strategies. Some of the team still prefer to cram nearly all business and data logic into Page_Load and write monolithic functions that contain over 500 lines of code.

It can be easy for somebody like me to become a bit jaded in an environment where shortcuts and hacks are a way of life because so much emphasis is placed on the fastest possible turnaround time between a feature request and its implementation. I have a curious personality and enjoy tinkering with things in search of greater understanding and finding better ways to do things. It’s a characteristic I need to keep in check in the midst of a culture focused on just cranking out code. Meanwhile, words like “Agile” and “quick win” are brandished as a justification for skipping all the tedious preparation work and beating the shortest possible path to the next “key value-adding deliverable”.

This is what happens in a company that likes to punch above its weight and promise things that it has a very real danger of not being able to deliver on. Consequently, almost all effort is directed at features, while our ageing frameworks and support systems buckle under the crushing weight of constant patches and new requirements.

On the other hand, it wouldn’t surprise me if most development teams followed a somewhat similar evolutionary path; they’ve just been at it longer and possibly have a more sympathetic environment. Sometimes you just have to learn things the hard way. Sometimes the lessons of the past do not actually apply anymore (or never did in the first place), and holding to them would cripple progress (see the Escalation of Commitment anti-pattern). Learning from others is good; but on the other end of the scale, living vicariously is no substitute for occasionally challenging conventional wisdom and finding out for oneself what works and what does not. The latter approach of reinventing every wheel in sight can be criticised as ineffective and unnecessary, but the former can also result in equally bad practices like cargo cult programming and the equivalent “monkey see, monkey do” behaviour on a project management scale. Taking refuge in either extreme is equal folly.

It’s tempting to waffle on about finding an ideal balance between the two extremes, but I won’t. Firstly, I am just a code monkey and that limits my perspective; I don’t easily see things from a business point of view. And even people who know what they’re talking about can’t agree because it’s far too situational and subjective for any kind of coherent one-size-fits-all answer. Secondly, it is not my intention to indulge in the hubris of telling the world what is ideal and what isn’t, as if such a thing is even knowable.

Instead, I am trying only to make sense of the world I am in, for my own purposes. On the remote chance that somebody in a similar situation finds this and feels a bit better for knowing that somebody else feels a bit of their pain, I may have just done something slightly useful. I’d settle for that.