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.

The Importance of Being Passionate About Coding

Throughout the years I’ve worked with a considerable amount of software professionals and have known a countless number of computer enthusiasts.  I dare say that the number of those who are passionate about their involvement in the aforementioned fields is far greater in the latter of the two groups.  I wasn’t going expound about this topic for some time but a recent phone call from a previous semi-co-worker (an employee where I recently held a contract) who had just returned for forty days in India learning some new technologies.  

    I have personally seen a multitude of coders over the years who were quite competent (or close enough) at what they did in terms of developing new systems or upgrade existing ones.    What I don’t see as often is that elusive fire that burns within the not-so-common coder, software engineer, developer, etc.  Some of you may be that person or know that person.  The one that is incessantly infatuated about this new algorithm, concept or design which might be revolutionary or simply solves a problem in an elegant way.  

    Even if you don’t know someone personally, you know of people like this.  In the spotlight we know of people like Guido van Rossum, Larry Wall, Donald Knuth, Kernighan & Ritchie.  Mind you not all amazing coders are language developers, though I would fancy a guess that most if not all of those who have the yearning for their craft have on one or more occasions figured out whether on paper or in their heads a way in which they would design a language or re-work an existing methodology to make it better.  

    Coders with this mindset and thirst don’t operate this way for fortune or fame, they do it because they have a natural yearning to create, design and improve solely for the purpose of knowing that whatever it was they needed to do was being done right.  You might recognise these people by their visible expression of excitement when discussing a new piece of code they worked on or a problem they re-worked.  However it is usually more apparent when you speak with them about coding in general.  Their eyes widen and you can hear the infatuation in their voice.  They sound much the way they did when they first discovered coding whether it was as a child or as an Adult.  That’s the fire and passion I’m referring to, and it is my hope that everyone, coder or not, gets to know at least one person like this, even if they themselves are one of these people.

Updating Existing Perl to 'use strict' Standards

     Now that a little over a week and a half has passed at my new place of employment, I find that I understand my new environment enough to make some observations in a not-too-specific manner out of respect for my new employer.

    First let me state that all of the existing software is a product of its environment and that it all functions as it was intended.  That being said I’m able to say with a clean conscience (after that little preamble) state that the code was ... lacking.  

    I am thankful for this to some degree.  For one thing it provided an opportunity for employment at a place I enjoy with some very intelligent individuals who all seem to have their own special abilities and areas of expertise.  

    More importantly though, I’m thankful because it places me in a situation I find most mentally stimulating.  It makes me re-think an entire existing architecture and being that I have held the role of Software Architect (amongst others) for much of my professional life, it is all the more appropriate. 

    It is one thing to walk into an new environment with a clean slate in which one may design to their heart’s content, yet another wholly different situation when the software exists in a production environment of one form or another.  There are so many more facets with which to deal when the database structure and all of the depending software is tightly build upon that aforementioned code base.  

    The whole point of this rambling is that my first week and a half has passed and while I have done much more with the database redesign, class design, object handlers, etc., I have finally been able to enjoy that great feeling which comes when turning previously un ‘strict’able perl code into a fully compliant piece of code.  I might also add that I ensured the code conformed within the guidelines of Damnian Conway’s “Perl Best Practices” book, which while a little different than my own manner of laying out perl code, is wonderful none the less.

    Now that this honeymoon is over, I can move onward and upward to greater code causes to champion, and based upon the intents of the owner of the company I don’t doubt that there will be a wonderful logic requiring plethora of future projects for which I am to contend.  I only hope that others out there are as lucky in their endeavours.