Software projects fail all the time. In fact, if you do client or startup work, you may never yet have built a piece of software that was commercially successful.
Why is this? Is it because of you? If you just learned one more code design pattern or chose the right language or framework for your next project, would it be a success?
No, probably not. Why?
Because code doesn’t determine commercial success. No matter how well you code, the project can still fail, and it probably will.
This is because a successful business needs the following three things:
1) A product that customers want, 2) sold for a price customers are willing to pay, but which is still profitable for the business, 3) which customers are aware of.
In the context of software, this means that you need:
If any of these three are lacking, the software will not be successful and the business relying on it will fail.
The software must be designed correctly for the target customer. The customer defines what is correct: not the programmer1 or the business owner.
If the design is wrong, all the work the programmer puts into making the code conform to that design is wasted. It will all have to be thrown away when the design changes, if the business survives that long.
If whoever does the product design is not finding out what the correct design is from the customer’s perspective, you might as well shut down the project. It will go nowhere.
Programmers often are not involved in product design. This means that most of our work is irrelevant to success.
The price for the software must be a price customers are willing to pay, but it also must be a price that is profitable for the business in the long run.
Programmers have no control over pricing, and limited impact on profitability. Their salaries affect the bottom line, obviously, but their code only matters to the degree that it costs the business extra money.
Programmers can ensure that the software runs with as few resources as possible, with as few bugs as possible. While this helps profitability, it’s not usually enough to make or break the business.
If the price is too high for the customers or too low for the business, the business will fail, and there’s not much a programmer can do about it.
Customers have to know about the product in order to buy it. Everything else can be perfect, but without effective marketing leading to adequate sales, the business dies.
Programmers don’t do marketing. So if whoever is doing it does a bad job, the business can fail without the programmer doing anything wrong.
Is it hopeless then? For some projects, yes; for others, no. Here’s what you can do.
Be more than a programmer. Programmers may not contribute much to the three items above, but that doesn’t mean you can’t. If you want your software projects to stop failing, you need to know more than code: you need to know design, business operations, and marketing.
Don’t accept your role. Get involved in the design, operations, and marketing of your project if you care about it succeeding. Don’t slot yourself into a programmer role when you could contribute more.
Accept your role. When your boss or client puts you in the programmer box, and won’t involve you in design, operations and marketing, then accept it. As a programmer, and only a programmer, the success of the project or business is not your responsibility. It’s on them. Don’t feel bad or be surprised when it fails, because it wasn’t your fault.
Or “Software Engineer”, “Engineer”, “Coder”, “Writer” or whatever we are calling ourselves these days. ↩