The Django Book is Done. | Home | Migrating from TFS to SVN

Filed under Architecture on December 17, 2007 by Joel Potischman

Whose Value Is It Anyway?

I recently completed a software development project for a client. I came up with what I thought was a great design to meet their very unique needs, and I worked with a really smart team who thought deeply about every design decision and produced world-class technology. The only negative apparent to me at the time was that my original time estimate ended up looking like the sales tax on the actual effort.

Big deal. Another late IT project, right?

As I combed through the charred wreckage of my project plan for its black box. I thought about the projects I've worked on where my estimates were dead-on, and I thought about the ones where I didn't see my kids for days at a time. This project gave me a brutal reminder that a software development project's ability to be estimated accurately is inversely proportional to the amount of new technology involved.

Some development projects are really deployment projects. You aren't creating anything truly new. You're mainly just gluing together pieces you've built or bought many times before. There's nothing wrong with that. It might not be a thrill a minute, but it's the lowest risk way to build software . . . if you can meet the requirements.

And that "if" is key. If all projects were that simple, you'd never do any new development. We'd call ourselves Mashup Engineers, not Software Developers, and projects would last a few hours and launch on time every time, instead of an unknowable number of weeks, months, or years. New mashups might come along that blew everyone's mind and created new zillionaires (Engadget + Amazon = RidiculousGadgetOfTheMonthClub.com !), but the value added by the people actually coding it would be low. After all, how much better can my glue be than yours?

But most projects require some new development. Let's say the typical project is 90% familiar to you. You always need to design a database, generate reports, write classes to enforce business rules and security, etc. Because this is such cookie-cutter work, you may feel like you're not doing "valuable" development, but remember that to your client, value = solved business problem, even if to you, value = new data persistence paradigm that's 40% more performant in low-memory situations.

This is a fundamental disconnect between developers and humans. We developers want to develop, and it's hard for us to turn that drive off, even when presented with a solved problem. Hell, especially when presented with a solved problem. Come on, if you had to be 5 minutes late for your 10th anniversary to make a chunk of code that nobody but you ever sees or complains about 30% faster, you know you'd at least be tempted.

And what about that 10% of the project that's new development? I don't just mean writing yet another CRUD class for yet another project. I mean "new" as in "novel". As in "uncharted territory". As in "this will be fun, but let's face it, you don't really know exactly what you're getting yourself into."

Even assuming your project is perfectly scoped (scope generally doesn't creep; it just becomes more clear over time), estimating how long it will take to work with a piece of new technology is the riskiest part of software development. Dependencies come up you didn't anticipate. The new thing doesn't work the way you had hoped. Any estimate you give for this work is simply a guess, though there is no question that your client will reap great benefits if you manage to deliver it some day. By definition, if this functionality didn't exist before, none of their competitors has it!

So to developers, it often seems that 90% of the project is boring and adds little value, but 10% is fun and glamorous and adds great value. Alas, the client values the software differently than you, and they cut the checks. Clients care deeply about being able to get back to business when you deliver the software they need. They do not care if their project is 90%, 95%, 99%, or even 100% boring to alpha geeks. They care about 100% complete and delivered.

The correct approach is thus to keep as much of your project out of that lawless 10% area as you can. Wherever possible, put on your Mashup Engineer hat and reuse existing software, libraries and frameworks until all that remains is the innovation directly necessary to address the client-specific business problem you were hired to solve, and no more. You may find that your project isn't 90/10 after all. Maybe it's 95/5. You've just reduced your project risk by 50%. Hey, maybe it's 99/1 and you really will ship on time! The less innovation you do, the better your chances of doing it well when it's actually beneficial to the client, not just intellectually stimulating to you.

If you know your software is going to be deployed numerous times or expanded immediately in ten different directions, investing the additional time, energy, and neurons up front can pay for itself many times over. But if you are building a system for one client, keep your innovation under control and deliver the value they want to get, not the kind you want to write.

So what really happened on my big late project? It had some fairly unique requirements that couldn't be addressed with the usual tools in my toolbox, nor could we find much existing software that fit the bill either. We thus felt justified in developing more technology than usual. Still, once you scratch an itch it can be hard to stop. We found ourselves rapidly approaching our intended ship date, but instead of a finished client application, we had a far more flexible and powerful world-class software platform . . . but it was only halfway built. We did eventually ship, and I'm extremely proud of the technology we created, but maybe, just maybe, it was the solution to the much bigger and more abstract problem I wish existed, not the one the client actually had.

Post a Comment Digg Del.icio.us

Post a Comment:

Name:

Email Address:

URL:

Comment:

The Django Book is Done. | Main | Migrating from TFS to SVN