developement time

[allmhuran]

I don't really understand this viewpoint, though it is certainly common. There's nothing so special about developing software that means it can't be kept to a schedule, any more than building a skyscraper. Both endeavors involve dealing with setbacks and unforeseen issues, and sometimes things get behind schedule, but I don't think it's impossible to have a schedule at all for either of them just because they're not 100% predictable.

Well, aaaactually...

Building software, particularly complex software, is quite different from building a skyscraper. A lot of software development is about solving "puzzles", and coming up with those solutions is not a simple, procedural process. It requires imagination and creativity. Most of the time is spent not in the banging-out-of-the-code, but in the figuring-out-of-the-solution - or even the figuring-out exactly what the question is in the first place!

Building skyscrapers, on the other hand, is a largely procedural process. Architects and engineers can do most of the problem solving ahead of time. Some specific issues with construction and engineering will certainly arise, but the time is spent mostly in the construction itself, not the thinking-about-the-problem.

This is why software milestones are notoriously difficult to schedule. To get a feel for it, try to give an estimate of how long it would take you to solve this problem (before you actually spending time on trying to solve it of course):

"Three gods A, B, and C are called, in no particular order, True, False, and Random. True always speaks truly, False always speaks falsely, but whether Random speaks truly or falsely is a completely random matter. Your task is to determine the identities of A, B, and C by asking three yes-no questions; each question must be put to exactly one god. The gods understand English, but will answer all questions in their own language, in which the words for yes and no are da and ja, in some order. You do not know which word means which."

[Red Iron Crown]

It's fine to have an internal deadline to work from but publishing a deadline means that people will hold you to it. That sounds all fine and good and generally works in a more professional environment where the client only sees the final QA version and then decides whether they're going to pay for improvements outside of scope, but if you publish a deadline for every update you make during early access game development with a fuzzy scope you're going to end up with a lot of very hacked off players because you will inevitably miss 50% or more of those deadlines.

E: At least, that's been my experience watching early access games. Maybe I have a different perspective being in development, maybe I'm more patient with updates because I know what goes into them, I don't know.

I see what you're saying here, particularly in how it applies to updates to an ambiguously defined project like an early access game. But it surely can't be that way for software development in general. I find it hard to imagine that one company hiring another to write a piece of software for them is going to accept statements like "It will be ready when it's ready" or "Soon". Businesses need proper schedules to make things work.

Well, aaaactually...

Building software, particularly complex software, is quite different from building a skyscraper. A lot of software development is about solving "puzzles", and coming up with those solutions is not a simple, procedural process. It requires imagination and creativity. Most of the time is spent not in the banging-out-of-the-code, but in the figuring-out-of-the-solution - or even the figuring-out exactly what the question is in the first place!

Building skyscrapers, on the other hand, is a largely procedural process. Architects and engineers can do most of the problem solving ahead of time. Some specific issues with construction and engineering will certainly arise, but the time is spent mostly in the construction itself, not the thinking-about-the-problem.

This is why software milestones are notoriously difficult to schedule. To get a feel for it, try to give an estimate of how long it would take you to solve this problem (before you actually spending time on trying to solve it of course):

"Three gods A, B, and C are called, in no particular order, True, False, and Random. True always speaks truly, False always speaks falsely, but whether Random speaks truly or falsely is a completely random matter. Your task is to determine the identities of A, B, and C by asking three yes-no questions; each question must be put to exactly one god. The gods understand English, but will answer all questions in their own language, in which the words for yes and no are da and ja, in some order. You do not know which word means which."

I don't see this as any different than any other development project, be it building a building or designing an aircraft. All those projects involve problem solving and design to a large degree, and none of them are purely procedural in nature (if you believe building a skyscraper is as procedural as you make out I would respectfully suggest you have little experience with construction). They experience the same problems of poorly defined parameters, scope creep, and changing customer requirements. Yet other design-and-build projects are able to make and generally keep to schedules reasonably well, I don't see why software should be any different.

* * *

I should point out here that I'm not really criticizing Squad's pace of development or lack of external timetables and feature lists. I'm satisfied with the pace of development and quality of work from Squad, and completely understand their position about releasing information about upcoming releases. I just find the argument that it's not possible to make and keep a schedule for developing software a bit difficult to swallow.

[Dodgey]

Building skyscrapers, on the other hand, is a largely procedural process. Architects and engineers can do most of the problem solving ahead of time. Some specific issues with construction and engineering will certainly arise, but the time is spent mostly in the construction itself, not the thinking-about-the-problem.

But the difference is that you aren't taking into account the entire development process of building a skyscraper, from inception to completion. Which is more akin to game design. Where the difference is that game development such as KSP is that design and construction happen at the same time or close enough to. Where as a skyscraper would be designed and built in order.

[Red Iron Crown]

There's a tremendous amount of redesigning and revising that goes on after a construction project is started. The plans aren't finalized until contruction is complete in most non-trivial construction projects. It's a requirement for most projects to submit "as-built" drawings after completion, these are usually the design drawings marked up with all the changes that were made during the project.

[cpast]

Exactly. The same way that complaining about bugs more than once won't make them get solved faster. The same way that suggesting features won't get them into the game. The same way that complaining about people's complaint's won't stop them from complaining.

So, in essence, the entirety of this forums is useless according to your statement.

Even if this were true, it *still* wouldn't make all the forums useless - much of the forum is stuff like challenges, or people sharing gameplay moments, or asking questions and getting answers, or showing off addons - there's a lot more to the forums than talking about development.

One thing is very clear and I dare you to prove me wrong in this:

-There is no clear definition on what SQUAD is gonna do in any release of KSP no matter how many deblogs, livestreams or anything they do. Let's look at ARM. At first, it was stated to be a DLC, then a mod and we only got to know it was an addon when the afformented thing was released.

If you're complaining that things aren't clear, you can start by making your own writing clear. What, exactly, is the difference between a mod and an addon? For that matter, what's the difference between a major official addon and a DLC? If, as of the release of ARM, it becomes impossible to buy KSP without ARM, what's the difference between that an an update? Are you just assuming that describing something with a different word means there's an actual difference in the thing itself? That it actually matters whether you call ARM a DLC, a mod, an addon, or an update?

I'm also confused how you can consider something that on release is given for free to all users of KSP, and which on release replaces KSP 0.23 in stores, and which makes changes to 0.23 instead of just adding new things (e.g. joint strengthening, engine rebalancing) a "mod" or an "addon" instead of an "update"; the only thing really addon-like about it is it partially uses the addon framework for its new parts, but it's really pushing the boundaries of the word to say that that alone makes it an addon.

[allmhuran]

They experience the same problems of poorly defined parameters, scope creep, and changing customer requirements. Yet other design-and-build projects are able to make and generally keep to schedules reasonably well, I don't see why software should be any different.

Yes, both types of projects encounter common scenarios such as poorly defined parameters, scope creep, and changing requirements. But construction does not require the same kind of continuous creative logical problem solving once actual construction begins. That's the difference.

if you believe building a skyscraper is as procedural as you make out I would respectfully suggest you have little experience with construction

Well, I do work at a company that is primarily in the mining and construction industry.

But the difference is that you aren't taking into account the entire development process of building a skyscraper, from inception to completion. Which is more akin to game design. Where the difference is that game development such

as KSP is that design and construction happen at the same time or close enough to. Where as a skyscraper would be designed and built in order.

Yep, that's what I mean when I say that most of the creative problem solving for a building is done by architects and engineers prior to construction starting. With software there are still architects putting together high level plans before any developers actually start doing work, but even with this in place the developers themselves also have to continue the process at the lower levels right through development.

[allmhuran]

Having said that, it is worth noting that some companies - indeed, more and more companies - seem to be trying to put the building construction methodologies into software development: using a few engineers and architects, and outsourcing the actual code-monkey work to the lowest bidder. This would parallel a construction scenario with a bunch of construction workers doing the large quantity of procedural work with a few engineers walking around providing oversight and the occasional visit from the architect.

But this almost invariably results in crappy software, because you can't really have such a thing as a "code monkey" given the tasks that need to be performed. Even Microsoft can't make it work properly (ref: the decline of the quality in flagship microsoft tools like visual studio over the last 10 years, the number of bugs and omissions in releases of enterprise critical software like windows server and sql server, etc).

It also tends not to decrease development time, since communication seems to become the biggest bottleneck.

[Jouni]

I see what you're saying here, particularly in how it applies to updates to an ambiguously defined project like an early access game. But it surely can't be that way for software development in general. I find it hard to imagine that one company hiring another to write a piece of software for them is going to accept statements like "It will be ready when it's ready" or "Soon". Businesses need proper schedules to make things work.

Businesses need proper schedules, and that's why almost all software out there is bad. You can hack major new features together very quickly. It may take a week to get them 90% done. (A week meaning 15-20 hours of real, productive work, and anything up to 100 hours of trying to work but not getting any good results.) Add a month of polishing, and the new features are 99% done. (Maybe they fail catastrophically 1% of time.) Add another year, and the features may be 99.9% complete and ready for release. (Too bad the real deadline was a year ago.)

The core logic under any software feature is usually simple. The real work goes into making the exceptional cases work, when something goes wrong, the user does something unexpected, or one of the underlying assumptions fails.

I don't see this as any different than any other development project, be it building a building or designing an aircraft. All those projects involve problem solving and design to a large degree, and none of them are purely procedural in nature (if you believe building a skyscraper is as procedural as you make out I would respectfully suggest you have little experience with construction). They experience the same problems of poorly defined parameters, scope creep, and changing customer requirements. Yet other design-and-build projects are able to make and generally keep to schedules reasonably well, I don't see why software should be any different.

Software development is not a design-and-build project. Building the software is cheap, fast, and more-or-less automatic, while almost all work goes into the design part. Even when you see a programmer in the middle of something straightforward enough that it could be categorized as building software, he/she is probably trying to figure out a way to do the routine task automatically. At least if the programmer is any good. That's kind of the essence of software development: identifying, abstracting out, and generalizing routine tasks, and figuring out ways to do them automatically.

Another difference is that software is complex - far more complex than anything else the human race has ever done. Remove everything that's essentially software from a skyscraper or an aircraft, and you're left with a big thing that's relatively simple compared to its cost.

[Seret]

what do we feel about the slow developement?

If I notice any, I'll let you know. KSP seems to be pushing updates out at a good pace considering where it is in the development cycle.

[MR4Y]

Even if this were true, it *still* wouldn't make all the forums useless - much of the forum is stuff like challenges, or people sharing gameplay moments, or asking questions and getting answers, or showing off addons - there's a lot more to the forums than talking about development.

Don't forget that the forum was the primary way of communication between SQUAD and the community. Why would anyone care to build reputation and that much hype over an Alpha/Beta/Whatever game, provide funcionality for mods and all that jazz? How many indie games have done that?

If you're complaining that things aren't clear, you can start by making your own writing clear. What, exactly, is the difference between a mod and an addon? For that matter, what's the difference between a major official addon and a DLC? If, as of the release of ARM, it becomes impossible to buy KSP without ARM, what's the difference between that an an update? Are you just assuming that describing something with a different word means there's an actual difference in the thing itself? That it actually matters whether you call ARM a DLC, a mod, an addon, or an update?

-A mod is something that is not supported by the company that owns the game, and it's most likely made by a 3rd party or an individual separate from the company. A mod is something that changes the game in some way, without necessarily adding content to it.

-An add-on is an addition that is separate from the core game developed and can be either done by the company as an option or a 3rd party supported by the main company. So there's no difference between a major official add-on and an add-on.

You also may recall that modifying something is different than adding to it.

-A DLC is an add-on developed by the company who made the game.

Consider that ARM is not even inside the main SQUAD folder. What's the difference between that and an update? You can remove it from the game without major hassle or without breaking it.

I'm also confused how you can consider something that on release is given for free to all users of KSP, and which on release replaces KSP 0.23 in stores, and which makes changes to 0.23 instead of just adding new things (e.g. joint strengthening, engine rebalancing) a "mod" or an "addon" instead of an "update"; the only thing really addon-like about it is it partially uses the addon framework for its new parts, but it's really pushing the boundaries of the word to say that that alone makes it an addon.

I'm not considering anything. That was what SQUAD said themselves. At first, it was a DLC. People complained about that profusely. Then it turned to an update. People complained about it profusely. Then it was stated that it was a free add-on that could be removed from the game.