Time and again, I’m astounded when potential clients come to me with their vision for a software development project, along with a budget. Not because they actually have a dollar figure in mind, but because they think that the coding is all it will take to get the job done.
In fact, my experience is that the actual programming part of a project is about half of the cost. Maybe as low as 20%, depending on the project and its objectives.
First off, you’ve got the discovery phase. What’s the problem that’s being solved? Sure, you might have a spec, but really, what’s the problem that’s being solved? Where will this project be in a year? In two years? How should we best structure the underlying system to be best positioned to deal with these future plans? No code is written here.
Then there’s code, but it’s not really code that gets kept, even if it’s really brilliant. In over 20 years of coding for money (ewwww that sounds dirty,) I don’t know if I’ve ever been given a spec, coded to that spec, and delivered exactly what was asked for without changes. Sometimes seeing a feature in an early iteration sparks a new idea in the client’s imagination, sometimes enough time passes in the development cycle that a new business driver gets introduced, and sometimes people just change their mind, and woe be unto those who are on jobs where the budget is fixed to a certain overall cost no matter what. Code is written here, but it gets scrapped.
Oh, there’s actual code too. The stuff that makes the final product shine. This is where the coding lives.
While all that’s going on, there’s infrastructure and documentation. Many projects don’t get a binder full of documents, but every project gets added to a source control system with comments on each check in, and a bug tracker with all issues and their resolutions, tied to the patches that fixed them. Typically, the client never sees this work, but it’s vital to the success of any project that takes more than 30 minutes to finish.
Finally, there’s the post-release phase, where typically the project enters the real world. With real conditions. Things nobody thought to try during any of the testing cycles. As the technical resource, it’d be great to just walk away here, and the contract often says you can, but in reality it’s best to at least be aware of the long term baggage of even a successful implementation. Code is written here, but is it budgeted?
And yes, those are all parts of “the project” that I’m being paid to do, and I’ll cost out the quote to make these things fit, but too often the value I’m seen as delivering is what I call “the typing,” when in fact that’s a really small part of the puzzle.
This is an evolving list, but it’s one I’m working on building based on past client work. Hopefully, by focusing and expanding on it I can approach projects (internal and external) in a more holistic way so people can understand the true cost, and value, of a professional software development project. My job, as I see it, is to take that budget and put it in the various buckets in a way that ensures the best outcome, which might not involve a lot of actual coding at the end of the day.
(Oooh, look, a technical post, finally! Er, kind of.)
Leave a Reply