One of the hardest things for us nerds to stop doing is maxing out favourite aspects of our work.  For example, I used to work for a team leader who would carefully calculate the run-time efficiency of every algorithm he wrote or he asked someone else to write.  Endless discussions were held to decide if framework X’s sort algorithm could be trusted to sort those ten entries into alphabetical order.  Another person I worked with would tinker endlessly with control layout on dialog boxes and create complex formulae for others to use to ensure consistency of controls, labels, grouping boxes, tabs, etc.

Of course, while this was going on, the customer just wanted a simple dialog box that displayed the names of their contacts in alphabetical order.

I think what happended here is that the leaders of these projects (and almost every other project I’ve worked on) didn’t create a shared view of perfection.  They allowed the nerds, who all have their own peccadillos, to decide how much needed to be done.  Instead they should have outlined their own view of perfection (using the idea of tradeoffs I’ve talked about before) and made it clear that a “balanced good-enough is perfect”.  An ugly, misalinged dialog box isn’t good enough and neither is a super-expensive beautifully laid out dialog.

Good enough is the new perfect.  This is one of the less explicit, but still important, messages that has come from agile software development.  Maxing out a few aspects of our work is a way of selling our customers and projects short.  We need to acknowledge that all aspects need to be collectively maximised and that this generally requires no aspect to be individually perfect.

Berin Loritsch has a post discussing various aspects of efficiency of programming languages.  He concludes with:

What I find most important is effeciency of maintenance. That means that the system should be self-explanatory, and provide enough information to be easily debugged. While creating a system as efficiently as possible is a concern, it is the poor maintenance guy that has to bear the brunt of the work. The easier it is for someone new on a team to get up to speed, the better the system is defined. Reducing the amount of code needed to describe a problem, and making it easy to understand what code performs which function are two very important ideals to pursue.

This is good advice that I think also applies to decisions about frameworks and application architectures.  I’m taking a bit of a gamble, having never communicated with him (except in reading his blog), but I think that using the list of attributes from my previous post (Talk about the tradeoffs), he would place approachability and maintainability at the top of his priority list for teams in addition to when selecting programming languages.

When I have been in the position of monitoring a number of projects there is something called the (Harmer) Safety Index that I use to decide which projects are most dangerous (ie most likely to be challenged).

Its a pretty simple idea, give each of the following areas a ranking of low/med/high and then focus upon the projects that have the lowest overall ranking.

• Experience of the team - this is obvious, the more experienced the team in the problem domain and tools being used the safer the project.
• Appropriateness of methodology - if the methodology being used by the team doesn't fit the project then things are more likely to go off track.  For example, if a two people for three week project is using a heavy-weight methodology with multiple sign-offs, etc. then they will be placing their project at risk.  Similarly, if a two year fixed-price project with a customer who is afraid to make decisions uses XP then again project safety is compromised.
• Constraints of the tools - some tools allow almost anything to be build (think Java, C++, etc).  Others allow only certain types of projects to be built (Excel, Cold Fusion, vertical application customisations, etc).  If the tool being used restricts the types of applications that can be built (and the needs of the project are met by the tools) then safey of the project is increased.  I’ll repeat that - the more constrained a tool the safer a project is.
• Skill of the project manager - this is a vital measure.  I believe that almost all project failures are caused by poor project management.  This is through missing important warnings signs, being incapable of leading the project towards completion or being unable to gain the resources needed by the project.
• Discoverability of requirements - its okay for a projects requirements to be unknown at the start of a project.  What is important is how easy it is for the requirements to be discovered.  Compare a project where there is a customer who is easy to get along with and who has a list of things she wants fixed with a project with nine customers from three different companies who change their mind constantly.  Obviously the project with requirements that are more easily discovered will be safer.

I know these are simply potential risks and can fit into a risk management process.  I don’t know many risk management processes that actually work but if you have one that does, then check that these potential risks are considered.  Regardless, these make great headings on a project brief/progress report or good discussion points for project managers to discuss with their own “bosses” or project sponsors.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.