Getting It Right The First Time

Introduction

This post is the seventeenth part of a ramble-rant about the software business. The current posts in this series are:

This post is about getting software right the first time.

This is also a professional development post for SQL University – my first!

Counting The Cost

Everyone wants to write perfect software. How hard could it be? Hardware can be configured to perform with high availability and reach five 9’s – why not software? There’s a group of developers out there who do just that: They write nearly flawless code. And it only costs $35,000,000 per year. You can read about it in this article: They Write The Right Stuff.

8:00 to 5:00

I found the working hours striking: “It’s strictly an 8-to-5 kind of place — there are late nights, but they’re the exception.” What? They’re writing nearly perfect code and working normal hours? I hear you thinking “Andy, how can this be?”

“I’m Glad You Asked”

Working lots of hours does not mean better code. It may mean more code. And it certainly means more hours billed to the project (pay attention if your bonus is tied to ROI). But it may not mean better code. In fact, there’s a point of diminishing returns where more people developing and/or more hours of coding begins to hinder the success of a project, pushing the goal farther from achievable and lengthening the time to delivery. That same Return On Investment (the ROI mentioned earlier) begins to decrease.

The same can be said about high availability hardware. The closer you move to perfection, the higher the costs to achieve ever-decreasing amounts of uptime. It’s asymptotic.

It Gets Worse

You have to always remember software development is an intellectual pursuit. We’re talking about knowedge workers. If you’re reading this and you manually load pulpwood trucks all day, I know this will sound silly. After all, how hard is sitting down in an air-conditioned office typing and moving a mouse? I hear you.

Manual labor is work. I call it “real work” because I grew up on a small farm. Clearing land meant hooking a chain around a stump to pull it out of the ground with the tractor. Gardening wasn’t fun – if we didn’t weed the potatoes, we had less food for the winter. Hunting was something we did for food as well. If we wanted spending money, we pulled tobacco for $1/hour.

Intellectual work isn’t like that.

But you can still demand too much of an intellectual worker. Just like you wouldn’t ask a laborer to pull tobacco for 24 hours straight, you wouldn’t ask a DBA to work 24 hours straight either. Or if you did, it should be the exception and not the rule.

The alternative is to ignore this advice and burn-out good people, produce lower quality code that takes longer to test, troubleshoot, and repair (by already exhausted teams), and lose revenue.

Conclusion

Bottom-line: You cannot deliver good code on a death march. You can do other things: run off good people, deliver junk on time, etc. But you cannot deliver good code.

:{> Andy

Andy Leonard

andyleonard.blog

Christian, husband, dad, grandpa, Data Philosopher, Data Engineer, Azure Data Factory, SSIS guy, and farmer. I was cloud before cloud was cool. :{>

3 thoughts on “Getting It Right The First Time

  1. Andy,
    An interesting post, and I agree.  If you drive people too hard you drive them off, but then again, if there’s no direction then nothing gets finished.
    Read "The Right Stuff" article.  How’s that fit with Agile practices?

  2. Hi Jack,
      Excellent question. I don’t think "Right Stuff" is Agile – I believe it’s a hybrid of mostly waterfall with some other methodologies sprinkled in. The article isn’t very clear, though.
    :{>

  3. I experienced projects where working IT stuff is forced to work harder for short project periods with lots of stuff. And what is bad about this, it becomes a habit after the first exceptional case.
    I observe that the quality drops off just like the mood of the stuff.
    Unfortunately, if you are not working in an IT company, your managers believe that you are a more support department rather than an IT department.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.