Less Updates

[Clockwork13]

I'm not saying the updates are bad, but updates seem to come out a little too quickly, not to mention less updates would also benefit the KSP team:

-They would get more time to work on updates and find bugs

-Modders wouldn't get overwhelmed and/or burnt out by adding update support all the time.

So what do you guys think?

[SebLavK]

I don't think every new version release after 1.0 was planned before hand by SQUAD. They are all hot fixes for some game breaking bugs and numerical values. That's the reason they are numbered 1.0.x

The fact that some new features are implemented with these is because they were ready by the time, or they were developed along with the fixes, even being part of the fix.

The next big update will be 1.1, and that won't come out in a few months. If you see the time in between big releases (0.17-0.24, 0.90, 1.0) as too short... Then I can only say I disagree

[katateochi]

My first answer is simply "Agile and Lean".

Having released that answer, I'll now update it.

Agile and Lean development practices focus on releasing small updates more frequently, this is in contrast to the practice known as waterfall development which aims to release a completed product in one major release. I wouldn't quite call Squad an Agile development house, but what they're doing is much more akin to Agile/Lean than waterfall.

Some of reasons for following an agile approach are exactly the reasons you put. With a small update that just focuses on delivering one bit of "added value" (to use the jargon) the dev team is focused on a smaller task and bug testing that one aspect is a simpler problem. Code turns to spaghetti all too easily, the aim of agile is to make the team focus on delivering just one new concept at a time and really following that concept through to ensure it's well thought out and well implemented. If you try to bundle lots of changes into a single release and then bug/acceptance test all those changes just prior to release it's much harder to fully test all permutations of each change (never mind how those change interact with the other untested changes).

In an Agile release cycle each new feature (or updates to an existing feature) is called a sprint and typically each sprint is 1 or 2 weeks in length. That means an update every 1-2 weeks, but each update is much much smaller than what we've seen in KSP's release history and will only alter one small aspect of the game at a time. With regard to the modders, I think part of their pain comes from suddenly getting an update to KSP that breaks many aspects of their mod and they are then suddenly under pressure to fix all of those areas as quickly as possible. If KSP had more frequent updates and each update only changed one key aspect, it would be much easier for modders to digest each change and adapt their work to it.

Similarly for us in the community, we would be able to adjust more gradually to smaller changes, rather than getting one update that requires relearning many aspects of the game at once. And this is another key reason for following an agile approach; delivering what the customer wants. After each KSP update there is uproar as we gripe about a bunch of core changes and find a new set of bugs. Our feedback and bug reports become a mess as we pick apart all the different things that have changed and our feedback is most likely hard for Squad to digest and react to in a positive way. With more frequent updates we could respond in a more focused way as everything we'd have to say about a release would pertain to that release's one feature.

Another very key aspect comes more from the "Lean" side of the approach (which goes back to Toyota's manufacturing processes and implementing waste reduction and safety in their factories). Lean is about being able to react to problems before they become something that affects output, in its origin it was about having an automated shutdown if there was a problem in a factory processes before raw material were wasted or before anyone got hurt. In coding it's about stopping development when a core bug arises and turning the focus to resolving that bug while it is still fresh in the developers minds and before it becomes buried under a pile of other code. A bug that you added yesterday is much easier to fix that one that was added last week, one that was added last month is a real problem (sadly something that KSP's team has plenty to deal with). I'm not saying that every bug must get fixed the moment it is added, some bugs take a while to surface, but once a bug is known, it is best dealt with before adding more code on top of it. Not all bugs can be solved instantly, but in that case they should be well ring-fenced and if you find that after a while there are a lot of ring-fenced "unsolvable" bugs, then it's time to stop and take a very hard look at the core approach.

With shorter, smaller releases the QA testers would have smaller scope to test and their feedback would come to the dev team while that particular feature was still fresh in their minds and without forcing them to switch from their current task back to something else (there's a whole essay about waste caused by "context-switching" here, but I'll leave that....it's a feature for another sprint!)

So in summary; I would argue for much more frequent releases than we've seen, with each release delivering just one change at a time.

[DocUrlaub]

Agree with OP for the reasons stated here:

http://forum.kerbalspaceprogram.com/threads/126466-Stabilization

The modding community has to be recognized as contributing to the success of KSP, burning them out, and the players waiting on updates is a big downside to continuous development.

[pandaman]

I understand the irritation with frequent updates, but IMO if they are hot fixes for issues that need addressing they are better to update rather than wait.

[Murph]

Agree with OP for the reasons stated here:

http://forum.kerbalspaceprogram.com/threads/126466-Stabilization

The modding community has to be recognized as contributing to the success of KSP, burning them out, and the players waiting on updates is a big downside to continuous development.

Frequent small updates are better for mod coders as well, so I reject that argument as being entirely misguided and without any substance behind it. A small update should be far less likely to need significant changes to mod code.

Also, as others have said, there's simply no viable alternative to putting out minor patches after a major update. No matter what any of the various posts claim, it's quite literally impossible for Squad to find all of the bugs in a major release due to the sandbox nature of the game. It's impossible for them to test every valid usage prior to release as the construction mechanics and wide variety of uses creates an effectively infinitely large set of situations to test. So, a flow of around 2–4 minor updates in the weeks following a major release are always going to be necessary to address issues that are impossible to address prior to release and only found once the majority of the user base starts bashing on the release and breaking stuff. Sure, there have been some things which should really have been caught in QA prior to release, but equally many important things which could not reasonably have been caught at that stage. No matter how much they improve QA, these minor updates and hot fixes are a necessary part of KSP.

Squad, please keep going with updates as often as you feel they are needed. In my opinion, you should ignore every single demand for less updates or less frequent updates. You know the pros and cons of updates without needing to be told them, and I trust your judgement.