Tar Pits or Tar Sands?

October 16, 2005 by
Filed under: Leadership, Process 

One of my earliest memories of leafing through our old copy of Encyclopedia Britannica as a kid were the artist’s depictions of the La Brea Tar Pits, down in an area that is known today as Los Angeles. All those prehistoric animals stuck in the tar, doomed to an unpleasant death, where 40,000 years later their fossils would be found in an era of a very different type of challenging and frustrating existence – undisciplined software development.

The saber-toothed tigers and early wolves, probably chasing after prey, were hopelessly stuck despite their swiftness and cunning – just like in the muddy farmer’s fields where we would lose our boots as kids.

Fast-forward a few years in my life, where I learned in school about the Tar Sands in the Canadian Prairies. In the late 60’s this area was literally a latent black gold-mine, known to store a vast amount of energy, but stored in a form that was too expensive to make it worthwhile with extraction techniques of the day. Someday, this would be quite valuable, but at the time they were simply a footnote in an otherwise boring Canadian geography class.

Here we are much later, Los Angeles is a bustling place of a different kind, and the United States, China and other companies (I originally intended to put ‘countries’ there, but is there much difference these days?) are bidding to own as much of our now valuable tar sands as they can get their hands on. Technologies have improved, crude prices have skyrocketed, and we’re quite a docile country here to deal with. The same stuff that contributed to the extinction of many early mammals might just allow us to sit in our SUV’s a few years longer.

With software, we have known for years that there are practices that clearly, measurably reduce overall effort and risk on software projects, many of the things that support the successful completion of projects of any kind – clearly defined scope, a realistic schedule, checks and balances, objective validation, and clear communication are a few of the prominent practices.

Many software shops seem to look at the commonly acknowledged ‘best practices’ in the industry with disdain. They can’t afford the time to deal with the pomp and circumstance of requirements analysis, and the design, well that is simply embodied in the code, right? Ruthlessly guarding their code as personal property and shipping when the compiler says all is OK (thank goodness we can tune out those pesky warnings…), they don’t have time for all those overhead activities – they have tight deadlines, after all. If these things were so important, they would have spent more time on these in school, (rather than the languages, databases, and operating systems) wouldn’t they? Best Practices are the things that slow us down from getting the job done, we’re doing just fine, thank you very much. Quality is someone else’s problem.

If only the saber-toothed tigers could talk – my guess is that they would know better that they were in a nasty situation. You probably have to be sentient to be naively optimistic and do the same stupid things over and over. Huge amounts of rework and poor quality are killing software companies, even today.

There are those software shops that recognize the true value of best-practices. Yes, there is a cost to mining them, and while some should be considered mandatory on any project, many simply aren’t worth it for trivial little tasks, and some aren’t even worth it for larger ones. If you want to really play the game of industrial-strength software development, due consideration of best-practices are absolutely critical and worth every penny of the investment. They are not overhead; they actually speed you up and reduce your overall risk on projects, when applied appropriately for the situation at hand.

Things that can appear daunting from a naïve viewpoint can be the source of tremendous value if leveraged properly.

There is no time like the present to acknowledge what Fred Brooks suggested over a quarter century ago, that there is plenty of room for improvement in most software development shops. While some teams are recognizing this and becoming more effective over time, there are still many that are mired in the goop of their own dysfunction, wondering why they can’t get things done. Some are doomed to extinction because they refuse to recognize they have a role in their own predicament, and will never take the steps to address their challenges.

Are you stuck in the tar pits, or mining the tar sands? – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September 15, 2016: Thanks to the Vancouver chapter of the IIBA for inviting me to present a talk about Real Analysis agility - the bottom line is thoughtful application of effective analysis over Cargo Cult application of the latest fashionable approach! - fabulous interaction, great feedback!
    November, 2016 - A workshop series to help you develop resilience in the workplace and in your life!
    Next open enrolment sessions start soon - contact us to get involved!
  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.


    Contact Jim if you would like to connect around any of the upcoming dates:

    • March 1-3, 2017 - Winnipeg, MB
    • March 6-8, 2017 - Edmonton, AB
    • March 15-17, 2017 - Victoria, BC
  • What People are Saying

    In our brief one day session with Clarrus, we identified the key areas to focus on, and drilled down to discuss the best approach to take in each area. Rather than a sanitary discussion of best practices, we arrived at a practical, specific set of items to implement – I think we made significant progress as a development group.

    — Daniel Miller, CEO, Miller Software