Coding is like gardening...

Great article on thinkvitamin.com today, although there was one small point I wanted to quibble:

First of all, for the most part it’s impossible to develop offline ‐ this is because we use hosted services, APIs and most likely you’ll write something that uses some data stored elsewhere on the web.

I disagree — if you’re doing things properly you should be stubbing that API in your test and using git locally, allowing you to work anywhere. Testing the integrated whole must usually be done online, but full integration tests can be always be run later when you’ve done your piece of work and you’re back on the grid.

Should've written a clearer spec...

We left off saying that fixed price projects had a number of disadvantages. One other problem with these types of projects is that they’re implicitly set up to pit client and supplier against each other. This wastes valuable project budget on working out what to do when the project changes.

Imagine a client and developer have come to an agreement and spent a lot of time writing the spec for a project. The contract is signed for a developer to deliver the spec for £4,000. Immediately we have two contrasting forces at work:

• The client is wanting the maximum amount of features that the developer will give him, so he gets the best return on investment.
• The developer is hoping to spend the minimum amount of time on the project to get the work done, so that he can cram as many projects in and make as much money as possible.

Good developers and good clients will mitigate these forces, but each party will always need to protect their interests to some extent, or they’ll go out of business.

There’s enough tension in the above relationship as it is. What happens when the client wants to add in another couple of features? The client might argue that the new features aren’t really new, but part of the original spec, so that he can try and get as much as he can for his money. The developer is likely to argue that everything that differs from his interpretation of the spec is new, and therefore should be charged for. The result is usually a fight, hopefully a compromise, but always a big waste of time and energy. Who wants to plough through a huge change process just because the original spec wasn’t clear enough? That time could be better spent actually delivering more features and providing more value to the client.

In practice, specs are never clear enough, and always require changing. Therefore at the beginning of the project you are committing to spending a fair amount of time arguing about the spec. If the change is a big one, then you’ve got a big problem: a lot of time has been spent already getting this spec “right”, and now it’ll need to be thrown away or rewritten significantly. There’s also more pressure to rush this new spec, which results in a worse spec the next time, causing more problems down the road.

The net result of all this is less efficient and more costly projects, bad feeling between clients and developers, and an overall reduction in the success of the project. Forget that ‘ongoing high quality relationship’ both sides wanted at the beginning: for serious failures often the only priority is to escape without a lawsuit.

It’s not all doom and gloom: some fixed-price projects do go as planned, but setting up projects in this way makes it all that much harder to see them through. I’m also not against specs: clearly it’s important for the client to communicate what they want! I’ll discuss how we use specs (although we call them something different) in a later post.

So take heart: there are more modern project management methodologies which ensure that there’s that much more chance that projects succeed and that everyone gets along. Next time we’ll look at some fundamental laws of software development in the search for a better way.

Tune in next time for the four variables of software development (you may want to subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :)

Billing is a thorny issue for most developers. At Eden we’ve billed via various means over the last few years, and have recently settled on a new method which is worth me taking some time to explain. If you’re in software development, it might help you to rethink the way you’re charging your time to clients – our new billing method has made our lives much easier, and improved communication with our clients.

But first, a bit of background on various ways developers bill clients for their work.

Fixed price – Billing per project

Are you sure you want to do this? There is no undo.

As a developer, I have an aversion to billing a fixed price for a whole project. In my opinion it pits the client and the supplier against each other, especially when parts of the project change (as they inevitably do).

The fixed price concept is borrowed from traditional engineering, when costs and requirements had to be worked out fully in advance as things were hard to change. Imagine you are a building contractor, you’ve just poured the concrete for the foundations, and your client pops over to ask for the building to be moved slightly to the left?! Because things are difficult to change after the work has been done, it costs a lot to do so. Therefore it makes sense to work out the costs fully in advance, and charge a fixed amount. If things need to be changed after the fact, there’s a rigorous (and expensive) process that is worked through, usually costing the client a bunch of money.

Some software developers behave as if the same was true of writing code. They put together a brief, build a website, possibly as a cut-price deal. Then they charge a fortune to change the homepage text, or add an extra button. We often get calls from clients who are fed up with being charged for four hours of time to change the wording round in one sentence. Ultimately, unlike in the construction industry, software (especially web-based software) isn’t and shouldn’t be hard to change. Why do we behave like it is?

Sure, expertise is valuable, and one argument for this sort of charging had made the round in various forms and is often used as a defense for this practice. However, I’m more concerned with communication: let the client know what the ongoing bills are likely to be before you start. Otherwise they have no way of measuring how much your expertise is actually going to cost, and therefore no idea about the true cost of the project. Because all projects change, a so called ‘fixed price’ gives clients less information that they would normally have.

Tune in next time for more discussion on why fixing prices for whole projects is also bad for project quality (subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :)