I hope this is not my legacy

I’m currently ripping a stack of CD’s to MP3, which is a task I find suprisingly satisfying. I’m in no way obsessed with things being neat and tidy (as long as the mess isn’t debilitating), but organizing things into nice rows does make me feel fairly content. I think that is fairly well demonstrated by how I write code: start off banging ideas out, lambdas and single letter variable names all over the place, and then as the functionality gets refined, the code gets polished so that the end product is a functional block of code in lovely columns (preferably highlighted in yellow and green on black, since I much prefer work with a high contrast color scheme now).

I think this is a fairly common way of working, especially for the newer generation of programmers who never really had to worry much about breaking the OS with unsafe pointers. I mean, I have worked with my fair share of C/C++, but Windows XP and modern Linux pretty much protect you against catastrophic errors taking down the whole mainframe. The basic philosophy seems to go further than this, beyond software development. It seems natural to me and many others of my generation (who grew up with Windows PC’s at home) when sitting in front of a new computer program to just click away at the GUI until I have figured out how everything works. We are fairly sure that no bad things will happen without due warning so are happy to just try things out, and I notice that this is very different approach to the Dad generation who like to understand exactly what a button will do before clicking it. One of the big reasons I chose to specialize in software and programmable logic rather than electronics is that you can use an iterative development style, without costing your company a lot of money. The problem with electronics is that once a mistake is made, it can get very costly to fix.

The thing I am slowly coming to realize is, however, is that despite what Visual Studio leads us to believe, software development shouldn’t be treated as the use of an application. The great debate of where the true discipline of software development lies (computer science or software engineering or programming as a craft or something else entirely) hasn’t come to too many strong conclusions yet, although I think it’s fair to say that most people agree that it doesn’t fit neatly into a box and probably never will. I think that a lot of the time where my aforementioned programming “methodolody” falls down is that I am tempted into the trap of thinking “it works, so the code is correct”.

I think there are two ways of making sure that quickly written code which works but is ugly or hard to read or has the possibility of undefined behaviour doesn’t get forgotten about. The first is to have code reviews where dodgy looking code gets rejected and re-written. In theory this can happen in a team situation where one explains his/her code to the rest of the team, and probably even without anyone else saying anything, the act of talking through the code should reveal problems to the developer. Often there isn’t adequate resources to involve a team for this purpose so I think we should be disciplined enough to go through our repository commits and make sure that we haven’t forgotten about stale code, and just think through all of the changes we are making.

The alternative (or complimentary) strategy is to think about the damn problem a little bit harder before tackling it, and to approach the task of writing code from more of an engineering perspective. Where I use the code base as my notebook for ideas and attempts, with all of the crossings out and scrawlings and smudges, one could just use a real notebook to plan out the best way to solve the task in hand and then transcribe this into code, and be fairly sure of nailing it in one or two attempts.

I think it’s fairly obvious I have already come to a conclusion on this one…