Does poor coding ever sink a startup?
I was curious if there are any stories of a startup failing due to poorly built software.
7 comments
I'm positive that more than a few startups have been sunk by poor code, however I don't have any examples.
I worked on a Big oil company IT project that had failed twice due to bad code. As the business guy I figured out that the system would round round down the final non zero digit of any value stored in the system to either zero or five. Usually this would make the report numbers slightly off, but sometimes it could be massive. Say you bought 1,000 $9.00 parts the system would show $5,000 in cost instead of $9,000, but if you paid $9.26 for the parts it would show $9,250 in cost.
The root cause of this error was the IT team had one guy who was crazy smart and had a bucketfull of assumptions about what the problem was that couldn't imagine that the issue was one baked into some of the first code he had written.
In a nutshell, this was a reporting package that sat ontop of SAP that was supposed to be actually useable by field managers and guys who turned wrenches so they could keep track of their budgets and spending. Of course this was needed because SAP had been implemented with very little training and no helpdesk for users.
The project had been rolled out twice to the field and just rejected flat out because the numbers didn't match, million had been spent building it and there was a 3rd try before the entire system was scrapped and a few million spent on an off the shelf piece of software.
It took a while to find the root cause of the totals being off because I'd always get these great complex explinations as to why the data was off an they had project change orders in to fix it. Finally I just pulled data to find out what was going on, and saw this weird pattern of the data being off in specific places but it took a day before I had the insight that the same thing was changing $140.00 into $100.00 as $0.79 into $0.75 i.e. the final nonzero digit of any stored value was being rounded down to the either 0 or 5.
I worked on a Big oil company IT project that had failed twice due to bad code. As the business guy I figured out that the system would round round down the final non zero digit of any value stored in the system to either zero or five. Usually this would make the report numbers slightly off, but sometimes it could be massive. Say you bought 1,000 $9.00 parts the system would show $5,000 in cost instead of $9,000, but if you paid $9.26 for the parts it would show $9,250 in cost.
The root cause of this error was the IT team had one guy who was crazy smart and had a bucketfull of assumptions about what the problem was that couldn't imagine that the issue was one baked into some of the first code he had written.
In a nutshell, this was a reporting package that sat ontop of SAP that was supposed to be actually useable by field managers and guys who turned wrenches so they could keep track of their budgets and spending. Of course this was needed because SAP had been implemented with very little training and no helpdesk for users.
The project had been rolled out twice to the field and just rejected flat out because the numbers didn't match, million had been spent building it and there was a 3rd try before the entire system was scrapped and a few million spent on an off the shelf piece of software.
It took a while to find the root cause of the totals being off because I'd always get these great complex explinations as to why the data was off an they had project change orders in to fix it. Finally I just pulled data to find out what was going on, and saw this weird pattern of the data being off in specific places but it took a day before I had the insight that the same thing was changing $140.00 into $100.00 as $0.79 into $0.75 i.e. the final nonzero digit of any stored value was being rounded down to the either 0 or 5.
One issue that I have seen is that many people will confuse anything more than slapping together code and checking it in as "premature optimization." Many of the same people believe that the value of their code scales proportionately with its size. More code is always better, right?
Poor code leads to technical debt, startup or not. Like all debts, if you don't bite the bullet and repay it, you will eventually be consumed by it.
Poor code leads to technical debt, startup or not. Like all debts, if you don't bite the bullet and repay it, you will eventually be consumed by it.
They may not completely fail due to bad code but it does incur a huge hit in pockets. Bad code results in high maintenance cost of the project and could take eventually kill it. Hence there is need for application and solution architects in any software development project.
I've experienced more startup failures due to over engineering and premature optimization (and thus late to market) than bad code.
You can fix the code after you launch, or you can just never launch.
You can fix the code after you launch, or you can just never launch.
One that springs to mind is Friendster. I seem to remember there were lots of stories about it running like a dog when converted to run on Java (and I'm not knocking Java).
I know a startup who spent 18 months and all their investment capital on outsourced development. When the code wasn't up to standards they used expensive consultants to fix the code. They ultimately decided to hire development staff but couldn't add new features without breaking the existing product.
It is a good little business but failed because of bad management decisions and poorly built software.
Contact me if you want more details.
It is a good little business but failed because of bad management decisions and poorly built software.
Contact me if you want more details.
Yes and probably more often than you think but it can quite difficult to diagnose from a top down perspective. It usually materializes in costs becoming too great but the underlying cause frequently is a rushed product that eventually costs too much to iterate on because of sloppy underpinnings. Its a delicate balance - you've got to get stuff out quick enough but also stable enough to make sure the next iterations wont become exponentially longer and more costly.
Outsourcing, high turnover, constantly changing requirements with unreasonable schedules all can lead to codebases that become too expensive to iterate on when the market demands more. Sometimes the only way out is to approach a complete rewrite which is usually a risky proposition.
Many times poorly coded products from the outside can have correlated symptoms of poor performance, bugginess, and slow feature development which are the cited reasons users may abandon the product.
Outsourcing, high turnover, constantly changing requirements with unreasonable schedules all can lead to codebases that become too expensive to iterate on when the market demands more. Sometimes the only way out is to approach a complete rewrite which is usually a risky proposition.
Many times poorly coded products from the outside can have correlated symptoms of poor performance, bugginess, and slow feature development which are the cited reasons users may abandon the product.
Do you think "over-engineering" could be a contributor to an unmaintainable code base? Also, do you think TDD is key to faster/cleaner iterations?
Yes, absolutely. I had an experience where the design was dictated by an architect who cared more about the theoretical and having UML diagrams looking nice than about actual business requirements and having the code be lean, clean, simple and efficient.
TDD and also code analysis tools can help highlight what you actually need and what you don't.
The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements.
Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug). Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).
TDD and also code analysis tools can help highlight what you actually need and what you don't.
The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements.
Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug). Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).