Ward Pond's SQL Server blog

Ruminating on issues pertinent to the design and development of sound databases and processes under Microsoft SQL Server 2008, SQL Server 2005, and SQL Server 2000 (while reserving the right to vent about anything else that's on my mind)

Pond’s Eleventh Law Emerges From Reflection Upon The Perils Of Going Fast

Pond’s Eleventh Law Emerges From Reflection Upon The Perils Of Going Fast

  • Comments 1
  • Likes

(updated for grammatical issues on 21 July 2006)

 

When I first published Pond’s Laws, I promised it would be a living document.  Herewith is the first evidence.

 

Perhaps it’s the fact that when I left my old job, I had a month-long programming push towards an intractable deadline coincide with my wife and daughter being out of town for three weeks.  Perhaps it’s the fact that shortly after I started my new job, I spent two weeks largely out of the office, which forced me to either slow down after that hard push or risk permanent, intractable insanity.  Or maybe it’s the fact that I spent a good part of last week driving on rural interstates, which offer a great opportunity to ponder the impact on fuel economy of high speed. 

 

It was probably all of that plus the fact the when I was walking to work this past Monday morning, I ran across an intersection and actually broke a sweat even though it was a pretty cool morning.  That’s when it hit me..

 

Going fast is expensive!  Usually in more ways than one.

 

So many times, in both our professional and personal lives, we’re focused on our schedule.  All too often, though, as the magic deadline moment draws near, we find that we’re further from our destination than we thought we were.  Being results-oriented people who are loathe to disappoint the people who are counting on us, we rarely adjust the schedule.  More often, we elect to go faster, work more, play harder, or otherwise speed up whatever it is we’re working on.

 

It’s been said that there are three ideals that are pursued in software development – budget, scope, and schedule – and that it’s generally possible to avoid compromise on two of them (In this instance, what’s true in software development is probably true in life more often than most of us would like to admit.).

 

As a practical matter, this “trichotomy” almost always comes down to a question of scope or schedule – the budget is the budget.  Even if we could hire more people, we’d have to get them up to speed on our project.  Unless we already have qualified candidates ready to be productive, adding headcount won’t help in the short term.

 

I’ve been part of many programming crunches, and I believe they are “expensive” on several levels that may not be immediately obvious:

 

  • people who work long hours eventually get tired
  • when presented with the opportunity to make a choice or a decision, a tired person is more likely than an alert one to make a poor choice or decision (I humbly offer some of my recent posts on optional parameters as evidence of this fact in my case)
  • a tired person is more likely than an alert one to introduce new errors into a program or process 
  • tired people who continue to work long hours while introducing more new errors and making more bad choices and decisions than they typically do eventually get grumpy
  • tired, grumpy people are tough to work with, so this arrangement is not good for our colleagues
  • tired, grumpy people are tough to live with, so this arrangement is even more not good for our families

So Pond’s Eleventh Law is, quite simply: Whenever You Must Compromise, Try To Compromise the Schedule First.  This is sometimes alternately stated as Slow Down, You’re Rushing Towards A Mistake.  There will be times when the schedule is intractable as a practical matter.  Those instances must be identified, and asking the question Can the schedule be compromised? is a means to that end.  If the schedule can't be compromised, then you've still complied with this Law, because by asking the question, you tried to compromise the schedule.

 

Why don't I want to compromise scope?  In most cases, cutting scope will invalidate your integration and test plans, because you’d no longer be changing code you thought you were going to change.  Furthermore, if you’re going down this road, you’re already tired, you’re already behind and you’re probably approaching grumpiness as well, so your planning and analytical skills are going to suffer just when you would need them most.

 

So..  Unless you perceive that you’re working lemming-style towards a failed delivery regardless of schedule, try to get yourself a little more time to see through the plan you’ve made without unduly stressing the work/life balance of your staff and their families.

 

There you have it. :)  Please let me know your thoughts.

 

          -wp

Comments
  • Marc left a great question on a Pond's Laws post from July of 2006 : Hi, I have a flashcard system that

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment