Ship it, or Ship Out

Joel, in his inimitable way, posted the flame bait of all flame bait posts yesterday, explaining the role of the Duct Tape Programmer.

To my surprise, the Twitterverse started to reverberate with commentary, but weirdly, almost all of it was very negative about the post, many claiming that Joel was just creating straw men and knocking them down, or was characterising developers who care about quality as being poor developers.

I was surprised, because I read the article totally the other way around - and had said so earlier in the day to someone on Twitter, saying I largely agreed with it. It seems that there were two ways of reading the article, and mine differed substantially to most people I follow on Twitter.

I was quite pleased to see Michael Neel post last night in a semi-defence of Joel's standpoint, and I thought the 140 char limit of Twitter wasn't enough for me to post my opinions.

Background

Joel has a bit of a record on this, he isn't best liked by a large proportion of the developer community who see their focus and remit as producing high quality, well tested and highly maintainable software. His original tirades in a podcast about his deep distrust of Test Driven Development and of Unit Testing in general brought uproar. And on that matter he was so far off the mark, it was understandable why he had riled so many people - he really just didn't understand or "get" TDD or testing in general.

But, what he had done, in conjunction with Jeff Atwood, was to deliver a website, stackoverflow.com, that was proving hugely successful, and was being used extensively by all those same developers who railed against his podcasts and blogs.

That website, as Joel and Jeff explained, was not done with TDD, was not well tested (via Unit Tests), was badly hacked together in places, and used "old" technologies like TSQL over "modern" solutions like ORMs

Whether Joel "got" TDD wasn't important, what he and Jeff had done was to ship a product, get it to market, and build upon that release to make stackoverflow the massive success it is today. It's so successful, that soon after stackoverflow was released, they used the same code and model to release other Q&A sites, and they continue to do so.

The Duct Tape Programmer

So with all of that in mind, it was sort of obviously flame bait for Joel to make a post that basically boiled down to "shipping it way more important than fancy patterns and great tools" - he certainly has a way of putting such a simple message that can antagonise the meekest of individuals (and some not so meek).

It was a terrible choice of label, but I guess "Pragmatic Programmer" had already been taken.

Time, Quality, Functionality

I read the article slight differently - I read it as an urge to maintain your highest priority as shipping the product your business wants you to ship.

There are three factors involved in a project (if you exclude Resourcing, which falls under Brooks Law):

  • Time
  • Quality
  • Functionality (or Scope)

If you try and maintain all three factors as fixed, your project is doomed to fail. Something will, unless you are really lucky, break. And then one of those factors will suffer, and it will be luck as to which it is. At best you can fix two of those factors, and then the third has to be allowed to slip when the unexpected happens (as it always does).

But, the important part here, is that which of those factors is fixed, and which is allowed to slip is NOT a developer decision - it is a business decision.

Much of the outrage about Joel's article stated that he isn't a developer - and they are correct - he is a business owner, and prior to that a project manager. His focus is therefore on shipping his product, and inevitably from that perspective, the instinct is to fix Time and Functionality (ship as soon as possible, with as much functionality as possible) and to let Quality suffer to achieve that objective.

This is a TOTALLY VALID business decision - it is just one that developers don't like, it offends their sense of code quality and high standards.

Why Do Developers Care So Much About Quality?

I'll start with the cynical view: development is only fun while you are trying new things, trying to perfect a tricky algorithm, or make some great new OSS component do some magic. By nature, the developers who care deeply about quality are also perfectionists, they like to make sure they have done a good job, and have written the best code they can.

Go on, admit it, if developers just did routine coding all day long, our jobs would be boring. We like new toys, new language features, we like to play.

And we know that better code will be easier to maintain - and developers HATE bug fixing duty, so we want to ensure we don't have to do much of it.

To a developer, the most important factor in any project is Quality, followed by Time (because we know our bosses will be mad if we miss our deadlines), but we are happy to slip Functionality because it matters little to us if a new feature isn't included in the release.

Fundamentally We Are Not Aligned

Developers and business owners are not aligned in their goals - we prioritise the three factors very differently, and for different reasons.

Only two things can happen here, your developers need to align with their business objectives, or the business needs to align with the developers - or they can both compromise.

Agile is all about the compromise, making both sides aware of the issues involved, and then coming to an agreement, but fundamentally - it is STILL A BUSINESS DECISION.

While it is the responsibility of a professional developer to explain all the problems they see with low quality code, and to make their boss aware of all the potential future issues this may cause, it is also their professional responsibility to go with the decision their boss makes.

They have one other option - resign and go somewhere that is more closely aligned with their values.

Ship It or Ship Out

Whatever your opinions of Joel and Jeff's understandings of TDD, Unit testing, maintainable code or just code in general (and I'm sure yours aren't too far from mine), you have to admit they delivered a product to market (many in fact), and have turned it into a huge success. They may have to pay for that speed to market later, but that was a business decision they were willing to take.

Never underestimate the value to a business of being fast to market - there is a risk the product will be so bugged it will backfire - but there is a chance they could steal the march on their competitors, and gain critical traction. Business is all about assessing risk, that is what a business owner has to do, and if they do it right their business flourishes.

If your boss wants a product shipped by a particular date, and that is their highest priority, you have a responsibility to ship it. If they won't sacrifice functionality to achieve that goal, then code quality will have to suffer - in that case do the best you can do with the restraints you are under. And if all that fails, quit, go somewhere that appreciates your values and dedication to your art - you do not have a right to hold your employer to ransom.

So, Ship It or Ship Out.


Posted 09-25-2009 9:38 AM by Jak Charlton
Filed under: , , , ,

[Advertisement]

Comments

Tim Ross wrote re: Ship it, or Ship Out
on 09-25-2009 7:00 AM

I really don't understand why maintaining quality means you ship later. If anything it should allow you to ship earlier and more often. I don't think quality is about going slow and carefully, I think it is about continuously improving your design and process to maximise your effectiveness at delivering high-value features, fast and frequently.

Kevin Berridge wrote re: Ship it, or Ship Out
on 09-25-2009 7:29 AM

Great post!  Its good to see someone weigh in on this with a little perspective.

I like your comments on quality.  Quality in software is an especially tricky thing.  I've written about it in the past as well: kevin-berridge.blogspot.com/.../paradox-of-quality.html

Tony wrote re: Ship it, or Ship Out
on 09-25-2009 7:39 AM

I pretty much read the post by Joel the same way and I agree that there is some balance between getting stuff done and getting stuff done 100% "right". Personally, geting stuff done 100% "right" is about as fun as doing bug fixes all day.

I also feel that people do not want to agree with what Joel had posted because it will reflect badly on them. The simple fact is a project can never really be 100% "right" because it would cost to much and take too long.

Just like in life, there is always someone smarter or better then you, in programming there is always a better way to do something. =P

Mark Nijhof wrote re: Ship it, or Ship Out
on 09-25-2009 8:11 AM

Very good read! I have to say that it is crucial that the business makes the decision for the right reason and that we try to do our best to make them aware of the consequences.

Jak wrote re: Ship it, or Ship Out
on 09-25-2009 8:20 AM

@Tim

Quality doesn't mean you ship later. But define "quality" (Kevin's link to his blog asks good questions)

And then it depends how good a developer you are - if you are exceptional, you will always write high quality code, and probably quickly. If you are average and still seeking perfection (and I have seen this many times), you could well be overengineering or rewriting or refactoring just for the sake of it or to learn a new tool or toy

Quality is a subjective term - but it is up to your boss to decide what he considers quality to be and how important

FriedBob wrote re: Ship it, or Ship Out
on 09-25-2009 8:34 AM

I can see both sides of this, having been on both sides in limited roles.

My biggest argument with "ship it fast" at the cost of quality is that that sort of thing will often come back and bite you in more time and costs later spent debugging and maintaining the code.

Your approach is also in some ways mandated by your environment. Yes, this sort of approach can be best where you have a new product that needs to be first to market.

But, there are times when this sort of programming is very, very bad. For example, the company I work for has an established product, and more importantly, we process and store credit card data. This means we have to maintain PCI-DSS compliance, as well as other related "best practices" when it comes to our coding. And one of the requirements for PCI-DSS is thorough testing and documentation of EVERY change to code.

The duct tape programming article does have some very good points to it, and some situations where it is very applicable. But as far as being any sort of "blanket statement", I can see how it would not go over very well. That sort of approach is great where innovation and speed are key, but on the flip side, it can make code that is a nightmare to maintain and requires massive re-writes down the road.

You mentioned priorities, and how business owners and developers tend to prioritize those three factors differently. That is a very good point, but you also have to consider factors such as how well you can support the project (again, depending on the environment and nature of the project) and external factors such as federal regulations or PCI-DSS.

What it boils down to is that you can't make a blanket statement about an sort of programming practice and say this is the best way every time every situation.

You have to use the best tool and approach for the job, and every situation is different.

You have to find a balance between "duct tape programming", structured tool/framework based coding, code quality, shipping date and maintainability.  Find the right mix, and you won't really have to make any significant sacrifices in any of these areas.

sergiopereira wrote re: Ship it, or Ship Out
on 09-25-2009 9:55 AM

To paraphrase a recurrent analogy often used by Robert "Unlce Bob" Martin:

- Would you like if your doctor in the middle of surgery looked at the clock and said: "OK everyone, it's 10AM already, we need to wrap up here and take care of what we missed when the patient complains about it. Good job folks. We did it on time. Congratulate amongst yourselves."

How can we ever earn respect from the business if we don't act responsibly?

I can't disagree with the overall idea of your post - the business is king. But I can't stand the idea the I'm contributing to make my own job increasingly more painful.

After a few cycles of "ship it anyway" we will have produced another maintenance monster and have contributed to the bad rap software developers get.

Jak wrote re: Ship it, or Ship Out
on 09-25-2009 10:30 AM

Sergio, the doctor analogy is a very poor straw man by Robert Martin - if you had to arrange operations up front, and decide on scope, time and quality at that point, nobody would choose a level of "quality" that let patients die.

It would be better to compare that to a health system that has to rationalise the services it provides, and chooses drugs based on many factors other than them being the #1 best drug available.

I agree that making your own job more painful isn't great, but again, that's your responsibility to put forward your case for different priorities and your employers right to decide which.

Developers and IT are not special, just because on the whole businesses have no idea what we do, does not give us a right to hold them to ransom - we need to come into alignment, either through persuasion and education, or by understanding why quality is sometimes not the most important thing

Ollie Riches wrote re: Ship it, or Ship Out
on 09-25-2009 10:40 AM

The front office of any investment bank is a prime example of this - exploiting an opportunity in the market is all that matters, because the cost of supporting the code is tiny compare to the possible gain.

Now you would have thought it would be different - banks have unlimited development budgets but they will still hire 'duct tape' programmers because they fullfil the prime directive, exploit the opportunity, better than people like me :)

jdn wrote re: Ship it, or Ship Out
on 09-25-2009 11:50 AM

DING DING DING!!!!  We have a winner.

You are absolutely right, it's a BUSINESS DECISION.

One thing to keep in mind about Joel's post is that the duct tape programmer he describes is also rare.  You "have to have a lot of talent to pull off this shtick."

Karl Grzeszczak wrote re: Ship it, or Ship Out
on 09-25-2009 12:27 PM

I agree with Joel's view on shipping. The whole point of designing a product is for it to be used, after all. If you end up laboring over a project and put a lot of hard work into it the only way to see ANY return on investment is to ship it.

I also 100% agree with your take on aligning developers and management. 9 times out of 10 they are at war with each other (for different reasons, sure) because they both have different goals. The truly successful organizations, that I've seen from experience, are the ones where management allows their developers to do what they do best (develop software) and the developers respect management enough to not be infuriated when management does what they do best (manage work flow). If either of those is out of whack, there will be too much friction to get ANYTHING done.

Great post, Jak.

Christos Karras wrote re: Ship it, or Ship Out
on 09-25-2009 12:46 PM

There are also valid "business reasons" for a developer to prefer maintainable code:

* customer expects software to be delivered bug free and doesn't want to pay for bug fixes (a perfectly reasonable expectation, but which requires a high level of quality to be realistic)

* unmaintainable code leads to reasonable customer questions such as "what do you mean, it will take 2 weeks to add a search field? that's insane!"... there may be plenty of reasonable technical justifications for that, but having to defend them can fragilize/break the trust relationship between the developer and customer

So having maintainable code helps in:

* making bugs a rare occurrence, and therefore an acceptable risk that the developer can absorb

* making changes that look simple to the user also simple to the developer, avoiding endless negotiations every time a simple change is requested

In these case, the business has to decide if it is acceptable to trade fast delivery NOW for interminable delivery in future versions (once the code has grown unmaintainable), and also to accept a "no warranty" contract where each bug fix must be paid.

That said, there are tools/methodologies that help in ensuring that even under "acceptable low quality", the code doesn't grow too unmaintainable (such as TDD), and these are the tools that distinguish "pragmatic programmers" from "architecture astronauts". As for the "duct tape programmer" label, it can be abused as a justification for plainly not caring, and this is probably why it gets such a negative response.

Robin Robinson wrote re: Ship it, or Ship Out
on 09-25-2009 12:50 PM

@sergiopereira

Are you going to work for free on the weekends in order to make sure it is high quality when your boss tells you there are only 2 weeks on money left?  I work in the DOD world and money and dates are what drive us more then anything.

Steve wrote re: Ship it, or Ship Out
on 09-25-2009 1:42 PM

Got to agree with Sergio on this one, I work in a highly regulated industry where "ship it early, fix it later" not only is not an option, it could get us in some serious hot water.

Most of the software that Joel (and by extension Atwood) "write" has very little impact if it has a bug.  If StackOverFlow is a bit slow returning some data, who cares.  If a financial system messes up 4 million transactions causing people to lose their homes, it's a completely different story.

MM wrote re: Ship it, or Ship Out
on 09-25-2009 2:11 PM

some bugs prevent people from posting pictures of their dog. some bugs make people die.

context matters.

Damien Guard wrote re: Ship it, or Ship Out
on 09-25-2009 2:57 PM

It wasn't written with old technologies - it uses the LINQ to SQL ORM, ASP.NET MVC and JQuery.

[)amien

pcomeau wrote re: Ship it, or Ship Out
on 09-26-2009 5:45 PM

"If they won't sacrifice functionality to achieve that goal, then code quality will have to suffer"

Hmmm... there's a crux there though. If you work in a place that is willing to let code quality suffer for the sake of the deadline guess who gets nailed when bugs show up. You the coder, cause your boss certainly won't fess up to it.

I've seen this too many times, from rigging the schedule so that the devs get more time then QA and then when the devs are late, QA's time gets shrunk.

To the "I ain't got time to unit test" really? Then why did I find 2 simple null exceptions cause you forgot to instantiate a collection.

Seriously I understand the deadline can rule, and sometimes you just have to buckle down and get it done. But this is what gives us a bad name ultimately.

Then again last I checked, when has Joel really been subjected to a deadline not of his making? His company makes shrink wrap software, so the article has to be read through that lens. He has shown contempt in the past for internal development, which is a fundamentally different world.

So again I get it, but I see it also as perpetuating the problem...

Jack Ukleja wrote re: Ship it, or Ship Out
on 09-27-2009 1:17 AM

The funny thing is we pretty much already know that expansive functionality does not make a winning product.

There are many examples of this: Microsoft Office - it has got a million features, but 90% are never used.

Or take the average video game - 95% of customers never complete the game.

What this means is the focus on functionality has been counter or un-productive. It either results in information overload for customer, or wasted effort for developer.

I think the success of iPhone App Store (even the iPhone itself) shows this again - small, polished programs are desirable over full featured but crap looking/unreliable software.

Jak wrote re: Ship it, or Ship Out
on 09-28-2009 4:23 AM

@Jack

>>The funny thing is we pretty much already know that expansive functionality does not make a winning product.<<

*we* as *developers* may know this, marketing and sales department may think otherwise. Just because *we* think lots of features isn't a good use of time, doesn't mean our businesses priority isn't right.

@pcomeau

>.So again I get it, but I see it also as perpetuating the problem...<<

So we have to either educate and explain why we think the priority is wrong, or move on

Eber Irigoyen wrote re: Ship it, or Ship Out
on 09-28-2009 1:35 PM

you've hit it, that's how I interpreted, too bad the agile fanboys took it the wrong way, but I guess that's how they roll, talk the talk, but can't walk the walk

Steve wrote re: Ship it, or Ship Out
on 09-28-2009 4:22 PM

Agile Fanboy?  What is this, a PS3 v. XBox 360 debate?  

The reality is, Joel sells a bug tracking system, so he likes it when bugs exist.  His other project he's related to is a website which can fail and it's really no big deal.  So of course he's all about "ship it and we'll fix it later".  

The reality is, a lot of software cannot work that way for a variety of reasons (the industry it's used it, to the costs involved, the bad PR it would create, etc.), so having that attitude doesn't really apply.

While  I definitely think he makes a fair point about Astronaut Architects, the "get'er done" developer can cause just as many problems in the long run.  

Jak wrote re: Ship it, or Ship Out
on 09-29-2009 4:46 AM

@Steve

>>The reality is, Joel sells a bug tracking system, so he likes it when bugs exist<<

Don't be silly, he has all the maintenance cost of his own software - he just obviously codes to his particular standards and processes and is happy with the technical debt taht may incur.

>>The reality is, a lot of software cannot work that way for a variety of reasons<<

And this is why it is a business decision.

If I am writing an ecommerce website, it matters little if a few bugs means it displays some items a bit oddly.  The business priority is probably going to be time to market and functionality over quality

If I am writing an aircraft control system, a minor bug could cause an aircraft to drop from the sky and ground my entire fleet, quality is going to be of utmost importance, and time can slip until it is right.

Context is key ... but 95% of developers reading this blog work on the first type of application, very very few developers work on *really* mission critical software.

Chris E wrote re: Ship it, or Ship Out
on 09-29-2009 11:37 AM

The problem with the original article is that Spolsky conflates two completely different traits. Trait A is avoiding needless complexity. Trait B is hacking things together in order to get them to work. These are orthogonal to each other.

FWIF I'm sure JWZ has a lot of TraitB, but I as far as I can see most of the article concentrates on TraitA.

TraitA doesn't necessarily mean that you are slapping code together without thinking - and the fact that netscape's code base was convoluted is not really a counter argument to that, it was a large project and I doubt if JWZ was responsible for most of it.  A better example might be the nestcape2/3 codebase - if available.

When it comes down to it, JWZ has a lot more code in the public domain than 'uncle' bob - and it's generally more clean and more functional (from a user's perspective).

There's probably a case for TDD - it's being made by the wrong people though.  For those snarking that Spolsky writes bug tracking software - Martin sells consultancy to failing projects.

Steve wrote re: Ship it, or Ship Out
on 09-30-2009 12:54 PM

@Jak,

In your eCommerce example, you missed the part that what if your bug caused people to get changed on their credit card and yet fail to receive the product they ordered.

You somehow define mission critical software as "planes dropping out of the sky", how about over charging someone's debit card causing them to not beable to pay their rent (this happened more than once where I used to work).  How about messing up someone's credit score so they get denied a loan or mortgage?

You'd be surprised how many people work on projects that could directly or indirectly affect people's lives.  Using "would a bug cause them to die" doesn't really make much sense as criteria in deciding if a bug is important or not.

Anyways, this entire arguement is getting ridiculous anyways.  I tend to side more on Joel's side on this arguement purely because I've worked with way too many Astronaut Architects who would over design tying their own shoe if they could find a way.  

Jak Charlton wrote re: Ship it, or Ship Out
on 10-01-2009 3:46 AM

@Steve there are always shades of grey - TQF are not boolean flags - they are sliding scales,. but something always has to give

Acerracrs wrote re: Ship it, or Ship Out
on 10-10-2009 10:27 PM

Excellent site. It was pleasant to me.,

Bill Sorensen wrote re: Ship it, or Ship Out
on 10-27-2009 11:17 AM

If you hire an electrician to wire your new home, do you tell him how to do his job?

You may give time constraints, or choose functionality (number of outlets, type of switches, etc.). You may even have some "GUI" quality input to save money - go with the cheap switches that may break in a few years. But the internal quality and safety considerations is up to the professional. You are not qualified to make those decisions.

If we want to be considered professionals, we need to have professional standards. Offering the customer options is good. Letting customers dictate quality is not.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)