How do you destroy a successful company in one simple lesson?
There once was a company that was so market leader in its field that its name became a generic term. This company sold very useful devices, and money was pouring in. However, the software for those devices has had constant development and had become unmanageable. To the outside world, the company was practically stagnant for years, and meanwhile, the market was largely being captured by app developers. Those apps weren’t as good or useful, but at least they were being developed further. The company was no longer praised as a technology powerhouse. Where did this all go wrong?
Later, I spoke with someone who told me that he was head of the test team at said company at the time and had proudly stood his ground: the new software had to do exactly what the old one did on the outside first, and then new features were allowed to be added; otherwise, he couldn’t test it. Aha, that had been the cause of the delay!
The company has now released devices with its new software stack, and they don’t look like the old ones. Some features are still missing, but as a customer, I don’t care. Better to turn back halfway than to go completely astray, so to say.
The lesson of the day: If you’re starting over with the software for your product, don’t cling rigidly to your old feature package. That is the way to cause significant delays.
Solution: You ca not regard rebuilding your software as a purely technical activity; it’s also a business issue!
Management usually doesn’t understand what it means when engineers complain that the software is unmaintainable. What they do understand is that the reason every development takes so long isn’t because of your developers (if you have good ones), but because every shortcut taken since day one of development is now dragging them like a lead weight.
It always is a nightmare trying to get a budget just for refactoring well running software. However, you will have a much better story if you can sit down with the business side of your company and create a new product line with a number of features they’d like to see and improvements that would never have been possible in the old software, and then trade those for the features you (temporarily) will be dropping.
Especially if you have a software product, it is not insurmountable to sell two product lines: the old one that’s barely being updated anymore and the new one that can accommodate all the exciting new features. You can happily keep selling version 1 to loyal customers who are hooked on the old features.
It’s not difficult, but you do have to keep it in mind. That’s why you need people who can contribute to the intersection of business development, architecture, and marketing.
