> Let other programmers fix the bugs and charge it to support after you release it. Send your main programmers onto the next project. That's how commercial software works.
That's how some commercial software works, but less and less. It's a dying model.
That strategy represents two bets: 1) You can shift a lot of the costs from before release to after (in the form of tech debt), and 2) people will pay you a lot up front before they figure out that your product is buggy and that you can't innovate any more.
That could work with packaged software where you can market the hell out of it and get a lot of people to buy it once. It doesn't make sense for internal software, though. And it mostly doesn't make economic sense for software as a service, where people pay you month by month. With a service, it's better to start small with a core market and then innovate continuously, so people always feel like it's getting better. You can't do effective continuous innovation with high levels of technical debt and your "main programmers" off on the next project. Unless your market has a very high barrier to entry, somebody will spot your weakness, jump in as a competitor, and quickly lap you.
We'll still be dealing with the bad habits from that era for years. But the era itself is over.
That's how some commercial software works, but less and less. It's a dying model.
That strategy represents two bets: 1) You can shift a lot of the costs from before release to after (in the form of tech debt), and 2) people will pay you a lot up front before they figure out that your product is buggy and that you can't innovate any more.
That could work with packaged software where you can market the hell out of it and get a lot of people to buy it once. It doesn't make sense for internal software, though. And it mostly doesn't make economic sense for software as a service, where people pay you month by month. With a service, it's better to start small with a core market and then innovate continuously, so people always feel like it's getting better. You can't do effective continuous innovation with high levels of technical debt and your "main programmers" off on the next project. Unless your market has a very high barrier to entry, somebody will spot your weakness, jump in as a competitor, and quickly lap you.
We'll still be dealing with the bad habits from that era for years. But the era itself is over.