For several decades I have been involved in software; building software products for large companies, growing a startup, and even running a boutique consultancy for 10 years. I now do independent product development helping client turn ideas into software products.
Many times in my career I have heard software development described to a client the same way you would create a house. This metaphor made sense on the surface. A house is something that the clients could relate to. There’s a design phase where they talk about what they want, then there’s the building phase where the design is implemented.
Does this metaphor sound familiar? It should, I have heard it from clients and other developers. But it is dangerous to use something so concrete to describe a medium as fluid as software. I now avoid using home construction as a metaphor for software development. Here’s why:
Scope can change dramatically after the contract is signed
As the client sees the product come together they reach realizations and will want to change the design. If we were building a house, it’s like the client casually mentioning that they want to add another bathroom on the second floor—right after you agreed on a price.
Unlike a house, software is made to be changed. Whereas a house is a largely static product, software needs the ability to adapt to changing demands, many of which present themselves during development. The catch is that clients cannot easily see all the work that goes into those changes, so they struggle to understand the complexity introduced with a new request.
Software processes can be complex
Building a house isn’t simple, but most people understand that first comes a design, and then you build it—that’s the process.
By contrast, software development can employ a number of flexible processes that many people aren’t familiar with. Processes like weekly stand-ups, sprints, backlogs, retrospectives give development teams the ability to quickly adjust to the changing needs to a project.
I find myself educating clients as fast as humanly possible, because without taking the time to explain how we change the software, and in-turn budget, the project would simply seize up.
The good news is that agile methodologies and the like are slowly permeating other industries and schools, but until these concepts gain wider acceptance, essential client education takes time and patience.
Cash flow will strain the client relationship.
If you apply for a construction loan, the bank wants to be sure of a few things before they’ll agree: like that you’ll pay them back, that the construction firm is legit, and that the costs of the project are reasonable. The bank won’t take the risk if any of these criteria don’t match what’s expected.
When all of these things do align, the process works well; the bank doles out money to the builder as costs build up. The builder knows that there is money, the client knows they will be spending it, and the bank controls this in the middle.
Software is nothing like that at all. To start, there’s no guarantee the client has any money, so it’s usually on the risk of the builder to pay their own people until the costs are covered. That can easily end up being 60 to 120 days depending on the terms of the agreement. It’s unfortunate, but right after a contract is agreed on, it’s a little like the developer—using their own funds— just extended credit to the client, all based on a handshake.
Sure, this can be solved by having the client pay up front. But there are always other firms willing to jump in to get the business, and the pressure is always there to just make a sale. As a development firm, it takes a lot of discipline to properly deal with the financing before the work gets started.
Estimates might be the biggest problem
In the middle of every project is the budget. For the construction industry they can get three bids from subcontractors and calculate material costs. My brother in law does this for hospitals in Missouri. As complex as this is it is fairly precise.
In contrast, for the software developer, this process is much more based on intuition and experience. Construction processes can base time and material costs on square footage, linear feet, volume, and other measurable metrics. Software lacks this hands on relationship. Estimates simply have to be summation of estimated risks. We have a couple techniques for this, but the process is wrought with variables. There are many places where this can be miscalculated. For example, the client might not have told you of everything they wanted, the developers might have misunderstood the requirements or the technology landscape can change while you are in the middle of creating the product.
These are the obvious things. Then add scope creep, legacy code, and code debt, and things can balloon quickly. If this estimate is wrong, there’s immediately a problem, and the longer that problem isn’t addressed, the bigger it’s going to be.
As developers, have ways to mitigate this, like doing development spikes to test technology and adding integrated tests to see if legacy code is usable, but in the end a number has to be agreed on, and you’ve got to do it quickly to start the project.
A better metaphor.
Let me propose farming is a better metaphor for software development.
It takes time to grow a crop, and there’s always the risk that it will fail due to weather, insects, and countless other external variables. It also takes time to grow a software product. Slowing things down increases the chances of success.
In my experience, It takes at least a month to just think through an idea. It takes at least another month to build a prototype that you can test internally, and it can easily take one to three months to produce a product that’s ready for release.
It is totally fair to say that a software product takes three to six months to grow, and at that point you basically have some young plants. It takes even more time to get it scaled up for a commercial release.
Sure there are magic fertilizers, ninja farmers, and amazing machines you can rent. But people need time to think, experience, and learn because that’s when ideas grow.
Don’t construct a house out of software, take the time to grow a product.