In defence of the lone coder archetype

All too often these days we see companies and methodology evangelists touting the system du jour whether it be Extreme Programming (XP/Pair Programming), or Agile as being the "One True Path" to coding enlightenment. All other be damned is roughly what said mantra translates to in common speak. We're told to beware the engineer who works alone in a dark back room for weeks on end. We're told to such a thing is heresy against the gods of modern application development.

We're being lied to by the methodology evangelists. I'm not here to down speak any of the other methodologies currently in use for software development. I am here, however to point out the benefits of the 'lone engineer' (not to be confused with the lone gunman). Lets set a few things straight though.

A coder with little to no professional experience in the field is not the optimal individual for this kind of setup. This is more for a seasoned professional who has at least been a team lead on several projects from conception through maintenance phases. I'm not saying it isn't possible to pull it off without significant experience, but I wouldn't place bets on such an individual succeeding at the whole task at hand in said company.

This kind of environment requires a disciplined engineer. We're talking about someone who knows the questions to ask, and how to dig deep to find the true needs of the client(s). This also means that the engineer needs to stand his/her ground when it comes to setting a solid schedule for phases of the project(s). There is room for variability in terms of time frames for each phase, but that the plan must be laid out in a linear fashion. This is engineering after all, and one doesn't plan to build the rooms before the foundation is laid.

Agile methodologies are more akin (though not parallel to) modular housing construction. Individual sections or units can be build simultaneous and changed (to a certain extent) by separate sub-teams. Whereas the lone engineer mentality is more akin to traditional construction in which the design is finalised, the foundation is laid and construction occurs in layers from the bottom up with customisations being generally last.

This isn't to imply that software built in this manner cannot change or adapt in a timely manner, far from it. Seasoned engineers/developers understand that the only true constant is change. We constantly work on new ways in which to design flexibility and mutability into our systems regardless of the specifics. This however just goes back to one of my earlier points in that this requires someone who isn't wet behind their ears. You can only know and plan for the unexpected via flexible designs after having cut your teeth in real world projects, and by faltering. Everyone makes mistakes, and it is through these mistakes that we grow and better ourselves. I'm not implying that senior level engineers don't make mistakes, I'm just pointing out that their success to failure ratio is pretty strong in favour of the success side.

One of the key benefits of the lone engineer methodology is that focus can remain solid with no deviation due to intra-coder/intra-team conflicts. And while this can at teams be a negative, overall it proves itself beneficial towards the ultimate goal, a finished software package/eco-system designed from the ground up to benefit the requisitioner(s)/client(s).

The issues of coding standards still must be kept, however there is definite consistency when only one individual is involved. This is also a liability as said engineer must have strict standards, commentary and documentation from beginning to end so that in case of any situation rending the engineer on the project incapacitated in any form, another could come in and continue with minimal delay. These are issues which affect other methodologies, some more than others.

There are downsides as well though. There are no direct peers upon which one can depend in times of need or collaboration. There are no peers to assist in code review sessions, meaning that the QA of any project must be proficient at testing, and enforce strict recursion testing when any changes are made to a product in production as QA becomes that final line of defence against human error. The reality is, no usable (as in serves a real purpose) piece of software is bug free and to think otherwise is the sign of a fool. What is realistic is having a system robust to handle errors when they occur, even if that is infinitesimally infrequent.

I'm getting off track here. My point is that in this newer, more extreme era in which coding fundamentalists believe they possess the one-true-way of coding and all others be damned, we must step back and realise the grave miscalculation they are making so boldly. After all, those methodologies weren't what were utilised to get us where we are today, nor were they even thought of when some of the staples of our art were invented. This doesn't mean that the next great piece of software or language won't be produced in such a manner, as it/they may. It means that we as professionals shouldn't be so narrow minded with tunnel vision when approaching different methodologies in an attempt to find which works best for the project/company/industry at hand.

Why projects fail, or more appropriately why QA cannot be an afterthought in the software cycle.

Over the years I have been in a multitude of software development environments, and bar none, the biggest reason as to why software projects fail can be overwhelmingly attributed to quality assurance.  More precisely it is either the complete and utter lack of a QA process (let alone a team), or simply the absence of sufficient testing procedures. 

Quality of software isn’t simply the fit, finish and packaging.  It is a whole encompassing methodology through which the program(s) involved are designed, revised, (when the time comes) patched, and upgraded.  It has been a long held observation of mine that coders in general don’t think of QA for several reasons.

    ◊    They feel that their programs were well designed and that they’ve accounted for all scenarios.

    ◊    The program(s) is/are too short to possibly have any error(s).

    ◊    They can be their own quality/testing department.

    ◊    They can/have figure(d) out all the necessary permutations of possible interactions that user(s) would possibly consider entering.

    ◊    There is no budget, nor push for a proper QA department and/or QA procedures.

While the above is a very, very small subset of all the possible reasons that I’ve seen/heard, the reality of it is that these are being given as actual excuses when confronted about what QA processes are in place.  The reality of it is that there are a lot of substandard, unprofessional software developers out there, who despite all the best practices of established community acknowledged developers and software engineers, continue to believe that it isn’t worth their time.

The outlook is sadly very grim from where I stand.  All too often there is considerable resistance from management, and more so from other coders when the topic of writing tests first, something we have been reminded of recently from (most notably) XP and Agile development circles.  Managers don’t want to waste time on a tight deadlined project writing code that will never make it out of the door and to the customer(s), and other coders in so many situations feel it is boring and unnecessary.  

The reality of it all is that those mentalities doom its transgressors to a endless of cycle of bug chasing and failure.  The impression that the end-user/client receives of a given software firm/group/coder is based almost entirely on the quality of their work, but there simply doesn’t seem to be the necessary forethought by those responsible to make the decisions toward quality.  

Quality isn’t simply a department which points out and/all flaws in a product, and quite frankly shouldn’t be taken as such.  Coders, particularly bad ones despise a proper quality arrangement because it points out all of their flaws without ever really providing an equal amount of praise.  Developers as a whole like to hear positive affirmation about their work.  The code produced as, such as an artists, an extension of their being, and thus hearing about problems with their work, they all too often take it personally.  They see it as an attack on their character, and that which makes them who they are.  This is something I would expect of a child, but not a professional.  

It doesn’t have to be this way.  We as a collective group of software developers, engineers and architects are the ones responsible for ensuring that quality of not an afterthought.  We have to make it a priority to build quality into ever facet of not only our software, but every facet of our varied processes.  The size of the application is immaterial.  Whether a simple shell script, or a half-billion lines of code suite, the same level of attention to quality is a pre-requisite for success.  

This includes the planning process as well.  Writing tests before actual code is produced is wonderful, and needs to always occur.  This requires discipline, which many seem to lack and/or overlook as a legitimate need.  It goes further than that though, all the way to the planning stages.  What is the point of having a high quality-focused mindset at the code level, if the project itself is lacking the same on so many other levels. 

We need to demand this mindset from the get go.  It is our responsibility to ensure that the necessary practises are put into place from the beginning, because no one else is going to care, let alone take the initiative.  If you take pride in your work, you need to ensure that it does as it is/was requested, and that requires the right methodology as well as mindset.  Not to imply that our lives depend upon this, but in reality it does.  

It isn’t as if all of this effort isn’t without reward.  We need to teach the next generation of coders to start with quality as their foundation, and it will simply become a ubiquitous piece of the process.  The benefits of this holistic view are many, and among them are:

    ◊    Stable code

    ◊    No surprises

    ◊    Happy clients

    ◊    Time to work on the next big thing (tm)

    ◊    Less stress

    ◊    Future business

    ◊    Peer appreciation

Quality is everyone’s responsibility, and that means it has to start with each individual, no exceptions.  So if you, or others which fit the bill as prescribed above have hangups on this issue, then it is time to think long and hard about it and either hangup your coding chaps, or take that next step and better yourself in your field, kicking your credentials up a notch, by having a quality centric mindset.

In future editions of the codedevl.com journal, I will be taking a more detailed look at each of the phases of the quality aspects of the software life-cycle.