That's fine, thanks for that Alex.
W/R to SafariJohn's post:
Developing software is iterative
Correct, software
should be iterative. From a commercial perspective, releasing early and often is usually the best way to get feedback quickly (QA)
To make your product iterative and not run at a glacial pace it requires you to slow down initially and plan and slice the work accordingly, constantly re-evaluating yourself as you go along.
By getting a full vertical slice of functionality through the door we can prove the infrastructure / deployments & CI pipeline is solid. Achieving this forces us to think about our ticket / story slicing in a way that each feature can be separately developed and released. We call it 'getting a bullet trace through the system'.
This approach usually lends itself a slower start, but doesn't have as much of a negative effect later down the line - (as you call it - the 'development hell')
Therefore in the long run you can maintain a more steady velocity. There shouldn't ever be a development hell, your process somewhere down the line has failed if you've gotten yourself into that situation.
What we're describing here is basically an agile approach vs a waterfall approach:
https://upload.wikimedia.org/wikipedia/commons/1/1c/Agile-vs-iterative-flow.jpgNotice each release on the left is much smaller, yet more frequent, if we're really talking about iterative software, this is how it's done.
With the gaming industry this isn't as easy to do, especially when your trying to not leak information about your product.
David Braben followed a similar agile approach to iterative software releasing, creating a full vertical slice of releasable game play pretty much right from the start.
He wasn't that bothered about keeping updates a secret and actually was very candid about upcoming releases. Yes, there ended up being plenty of bugs on day one, but they got ironed out pretty quickly in his defense.
Every release which came after was frequent / iterative and they never slowed down, he ended up finishing the 1.0 version of the game in no time at all.
Not everything has to be a big bang release, though it makes sense in some situations, such as releasing a big expansion pack for a game.
That's how many projects end up spending 90% of their time and effort on the "last 10%" of the work AKA Development Hell
That's because most projects you've been involved with probably are run in a waterfall fashion.
They start quick due to lack of initial planning / slicing, also develop initially fairly quick..
Then what usually happens is they slow down over time as things get more complex and the code base becomes more out of control.
https://ars.els-cdn.com/content/image/3-s2.0-B9780123815200000023-f02-01-9780123815200.jpg?_Yes there will always be non functional requirements to consider, scope creep, un-expected technological barriers, Peoples illness / absences. Live issues you need to jump on, etc,etc But that's the same with all software usually.
The difference here is how you manage the stuff that
is purely in your control.
If you're running a really big project over multiple teams, you kind of have to do this stuff or everything just grinds to a halt and cost will sky rocket.
However even for smaller products / individuals - the same principles above can be applied - It just happens on a smaller scale to bigger businesses.