In my own experience (and opinion), your style of development often results in better quality code, less bugs, and cleaner UX. The tradeoff, as you experienced, is time.
I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.
Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.
The result of this "we don't need quality" line of thinking is that almost every AAA game release nowadays is a gigantic fiasco. Nobody wants actually to buy alpha quality shit any more!
I guess games could have much higher sales (especially when the thing is new and hot) if they wouldn't release utter garbage for the most time. Just go and ask people whether they're keen on buying a bunch of bugs for 60 to 80 bucks. Most people aren't. Only a very small group of die hard fans does this.
The whole indie scene wouldn't stand a chance likely if the big players were able to deliver stuff that works actually before the first couple of patches. It's a kind of joke that one or a few people can build much better games than multi-billion companies. The problem is the mindset at the later!
I'm not advocating for "maximum code quality" as you don't get that anywhere anyway for any reasonable price. But game releases are just far beyond any pain point. The usual advice is: Don't touch, don't buy, until they proved that they're willing to fix their mess!
The games industry would need to walk a really long distance before they could get rid again of this public perception. But they need to start somewhere. Otherwise their reputation will reach absolute zero real soon now. They're already almost there…
Problem is, execs would like 300M revenue now, with a buggy PoS, than 500M after 6-12 months. Because those 300M can let them make another crappy game and release it 6 months earlier (12 if both skip on quality). Then you are missing 400M revenue, but you get 600M 12 months earlier. That recoups costs and looks nicer on reports.
Or in other words, gamers hate buggy releases, but not enough to change the practice.
This is true, but it's not the tradeoff most people think. It's not "this way is better but takes more time", it's "spend time now vs. spend time later."
In my experience, you will always spend the time. Spending it earlier can be difficult when you're on a tight schedule which is driving the process, but you'll always spend at least as much time later.
You only spend the time later if you're still working on that project later. It could have failed, done it's job, or you could have moved on to the next project leaving some other poor schmuck to spend the time later.
> In my experience, you will always spend the time.
not in mine, but I've seen a fair amount of very one-off, time-limited projects (the shortest being a client calling a morning for a very simple customized video playback app needed for that very evening, and a lot of it being only needed for a few months)
True, that’s an exception. It reminds me of the way some missile control software never bothers to free memory because by the time it runs out of RAM it’s already exploded…
I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.
Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.