The Devil is in the Details

By Deane Barker on August 4, 2006

Here’s something not that shocking: the same amount of time spent on different Web development activities can yield vastly different productive results.

Put another way: you can spend two hours on Activity A or the same amount of time on Activity B. Does this mean they will both contribute equally to getting your project done? Nope.

Example: in three hours you could:


Define the complete content model for your Web site, build the data model, define the content objects, and either configure a CMS like eZ publish or stub out an admin section in a framework like Rails.


Fix one infuriating CSS bug.

Again, this isn’t rocket science, but it is very important for people who get paid to build Web sites.

The first example is something that would fit into “Principle Construction.” This is the stage in the project where you’re fundamentally building the site. This is a fun stage because you progress rapidly. You spend two hours on something, and you have a lot to show for it. You feel great – things are moving along.

The second example can come during “Spit and Polish.” This is after Principle Construction is done – the Web site is more or less feature complete, and you’re just fixing stuff and tidying up (another firm I’ve worked with calls this “Dust and Clean,” or “D & C”).

Spit and Polish can be frustrating, because the pace slows. You can spend the same block of time on something as you did during Principle Construction, but have comparitively little to show for it.

Joe and I were working on a project once, and things started out great – right out of the gate, we were streaming along the requirements list. We were solidly in Principle Construction, but back then we didn’t have a name for it.

A week later, the project didn’t seem that fun. The work was...ickier and much less satisfying. I mentioned this to Joe: “Why was this project so much more fun last week?”

His response was so true: “Well, I guess all the easy problems have been solved.” That is to say, we were smack-dab in Spit and Polish where you spend a lot of hours for little results. It’s not nearly as satisfying.

So, what’s the point of all this? It comes down to bidding Web projects. We have always had a tendency to bid Principle Construction only. You look at a project, and you think, “Well, it will take X hours to implement the content model, X hours to set up the users, X hours to do this and that.” Then you just add up the X’s to get a total.

In this stage, you don’t bother to bid things like “Fix a little CSS bug” because that seems so small in comparison to “Implement the data model” and because you can’t forsee a specific CSS bug that you’re going to have to fix. But how many of us have killed ourselves for two straight hours trying to figure out why a pixel won’t like up in Internet Explorer? Yeah, I thought so.

What this means is that you have to explicitly account for this stuff in your bid. You have to add a phase to your proposals called “System Testing” or something which is where you’re going to do all the Spit and Polish, all the Dust and Clean, all the things that you can’t bid separately because you just don’t know about them yet.

The fact is, you’re going to do these things – you have to, in order to deliver a project. The only question becomes, are you going to get paid for it?

But should you get paid? I mean, if you were good, these things wouldn’t happen, right? Not a chance. No matter how much experience we have, stuff just happens. Bugs pop up, things change slightly, original plans have to deviate. Things will have to be done at the tail end of a project that you could never have individually speculated in the beginninng.

So, bottom line, when you bid a Web project, don’t just bid Principle Construction. Know that the unplanned but crucial details will crop up, and you are going to need some budget to pay for them.

On the one hand, this feels sneaky, doesn’t it? We’ve all heard the proverb, “Estimate the number of hours the project will take...then double it.” I’m not saying you should double all your estimates, but you should have a buffer there.

If you don’t, the client ends up losing out. The budget runs out long before the project is done. You’re not getting paid anymore, so details go unfixed, stuff gets pushed back, and – most importantly – your enthusiasm for the project nose dives. Not only are you working for free, but you subconciously feel stupid because tail-end bugs have once again cropped up that you didn’t account for. Didn’t this happen last time? When will you learn? It’s a morale killer.

Bugs are going to happen. In all but the most controlled situations, little bugs are going to come up that you have to fix, and that could never have estimated. I don’t care how good you are – this stuff will happen.

The only question becomes: how prepared is your project for it?

Comments (2)

Dave says:

the niggling details exist, and you are going to need some budget to pay for them.

Do like most other industries; make a best-guess of what it might cost and bury that in other line items. It’s kinda like building in the costs for lights and heat or health insurance; you don’t have a line item for that, but the guy that hires you for a programming job knows that part of what he’s paying you will go to cover those costs. You know – & and your customer knows, if you’ve educated him well – that there will be these niggling little issues that need to be resolved before the job is completed; you need to make a best guess as to what might go wrong, what it’ll take to resolve it, and build that cost into the project. There’s nothing sneaky going on; it’s just doing business.

The great thing about building costs like that into a project is that as you get better at avoiding the spending huge amounts of time on the “Spit and Polish” and the “Dust and Clean”, the higher your profitability gets. Or the lower you can bid a job and still make money.

Chad says:

In addition to bidding web projects for your own business, I think this is also relevant for creating project timelines in software development projects when working as an employee of a large company. $h!t happens, and it’s better to plan for it than not. The major obstable I have run into is that sometimes project managers, and most of the time project sponsors (the business side of the project) doesn’t understand or care to understand why you need a buffer, and that you aren’t trying to give yourself 4 weeks to do a 2 week job just because you are lazy. This usually happens when there’s a lack of IT ownership on a project.