Related: Design By Committee and Other Bad Ways to Plan Development Projects
Developers understand that what they do is hard. Unfortunately, many in the business world don't realize how difficult it is to develop custom software. As such, my guess is that the thoughts and ideas I'll share here will primarily only reach and resonate with developers. Unfortunately, though, my thoughts are primarily aimed at investors, startups, and any business that needs custom software.
Most Custom Software Projects Fail
The first thing to communicate about custom software is that most custom software projects fail. In overly simplified terms, it shouldn't be too surprising that custom software projects, which tread fully into the unknown and undone, regularly fail to materialize on time or as expected. But, in my experience, organizations looking to find and hire a developer or development organization to tackle custom software needs typically run about only about a 33 percent chance of success each time they pull the trigger. In other words, if company X is looking at fully revamping their website to integrate some core, new business feature into their site or if they're looking for a custom LOB application, my experience is that they'll probably run into two, fairly spectacular failures before finally getting what they needed in the first place.
Related: Good Development Project Planning: Establishing Project Champions
In my experience, the primary reason for entire projects failing when it comes to custom software development really boils down to two very simple and interrelated concerns: scope and developer compensation. In terms of scope, it's easy for developers to joke about how their clients never know how to communicate what they want, but the reality is that the problem of discovering, evaluating, and prioritizing requirements to adequately address project scope is much harder to tackle than most business organizations and developer shops care to admit. Businesses are typically too eager to get started to avoid lost opportunity costs, and developers too frequently assume that they 'get' what's required before adequately collecting, enumerating, and evaluating all requirements. As such, far too many custom software projects start out what is going to be a marathon in what metaphorically amounts to either a three-legged or potato-sack race.
Developer Compensation: Why I Only Develop on an Hourly Basis
When far too many software projects start off with an incorrect understanding of the true scope and nature of the project involved, which invariably means that developers end up having to play the catch-up game if they're ever going to be able to deliver on time and on price. However, even in cases where scope and requirements were meticulously gathered, the mere fact that what's being created is fully within the domain of the unknown and undone, it's still possible for unexpected bugs, hiccups, and other complications to arise and potentially derail deliverability. In my experience, once these problems crop up, it's very common to see businesses that try to 'solve forward' and go for the optimal solution, rather than simply hacking or kludging things together to get the project out the door and at cost.
Related: The Business of Software Development: Guidance for Professional Software Developers
As such, it's far too frequent to run into situations where developers are left on the hook to address problems that no one could have foreseen or conceived even if due diligence was performed in terms of scope and requirements. To this end, the nearest analogy I can think of would be something akin to building an industrial building for vehicle fabrication and assembly. You'd need to address everything from pouring the foundation to getting the framing, electrical, roofing, and plumbing done. Now, let's say that the vehicles are finally being assembled on the main floor now, but you've unexpectedly realized that the framework needs to be 24' tall, instead of the 16' feet they were three weeks ago. And the floor itself was amply provisioned at only 20' high, per the initial spec. In other words, the height of the ground level of the building now has to somehow be magically increased even though plumbing, electrical, roofing, and three additional floors above this floor are all almost done.
For developers caught in this type of situation, the problem is primarily one of engineering. In other words, the problem can usually be solved with some creative thinking and typically a lot of additional effort. Of course, the problem is a question of who ends up paying for the additional effort. In terms of fixed-bid development projects, developers simply eat it or lose their shirts, which is something I sadly did once and almost ran me out of business. Since then, I've only undertaken development efforts on an hourly basis. Of course, that puts more of the risk and capital expense on the organization paying for the solution, but I think that's only fair as most developers of custom solutions aren't compensated with stock options or a cut of the profit margin from the app they're creating if it's successful. As such, it doesn't seem fair to make them silent and non-compensated investors by holding them to a fixed bid that'll almost, invariably, end up leaving developers short changed when anything complex or truly innovative is being tackled.
A Case Study: Why Software Developers Aren't Investors
A while back an entrepreneurial friend reached out for some development advice. He'd been undergoing some pretty major business changes by means of spinning up an application to better track sales, leads, and other core concerns that were key to growing his thriving business. The problem, however, was that while development of his custom needs had initially gone perfectly, reporting and some other lingering concerns were starting to take forever for his single developer to address. In helping him address his problem, my initial fear was that he'd found a developer who had gotten in over their head and only had a bunch of fluff and no real-substance. Upon closer inspection and further discussion with my friend, it was easy to see that the app not only had real substance and architecture, but also that the functional, roughly 90 percent of the app that was already done, totally worked as expected.
As it turned out, the real problem is that the developer had taken on the project as a fixed-bid project. And final payment had already been made two to three months ago when the bulk of the project was delivered after hitting a few unexpected snags. In the meantime, the developer had moved on to other paying projects and was working on the remaining pieces of this project as time permitted. In the end, I recommended that my friend touch bases with the developer, communicate how happy he was with what had been delivered so far, and let the developer know that the project might've been bigger than planned – and that my friend was willing to help throw some additional compensation into the mix to help get the project moving again.
My recommendation ended up being a huge success as the developer had every intention of finishing my friend's app but was simply too busy working on other projects to pay the bills and just couldn't dedicate enough time to a project that was already out of scope and, now, a liability instead of an opportunity. By transforming the remaining development effort back to an opportunity with a roughly 10 percent increase in project cost, the project got back on track, remaining tasks were completed, and the application became a total and complete success (minus the few weeks where development stalled because the developer was left holding the bag in terms of true capitalization costs).
