Properly working burn time indicator

[Alshain]

41 minutes ago, Snark said:

Staging and fuel flow are really, really hard.  (Discussion here.) It's a big part of why KER is such a gargantuan, complex mod (easily at least ten times the code of BBT, which is itself non-trivial).  It's why BBT doesn't even try.  It's why having a delta-V calculator in the stock game has also been an elusive goal.

Again, not impossible, just... a really big design & coding job.

I understand that from your perspective as the developer of BBT, again your mod is a good mod.  I'm not saying you slacked off or anything, I would have made the same decision in your shoes.  It's not worth it as a modder unless your mod is already doing that (like KER)

However, I expect more from the developer of this game and if KER can do it, so can they.

Edited May 23, 2017 by Alshain

[Guest]

8 minutes ago, Gaarst said:

I can understand that it's not a trivial piece of coding, but you and other modders (I don't who wrote the original KER dV/burn time calculator, which was probably refined anyway) did it in their free time.

How much "free time" did they spend writing that? Can you quantify it? Those hours then need to be spent by a paid dev. Those algorithms then need to be QA'd by other people who are paid (not just users). The code needs to be iterated upon, and iterated upon, and iterated upon, until it is Good Enough For Production. Then it needs to be iterated upon by devs once the users find holes in it (because they will). Then those iterations  need to be QA'd by other people who are paid.

etc...

etc...

etc...

This is not a simple task.

[HebaruSan]

1 hour ago, Alshain said:

I don't think it's that impossible to happen.  Whether it's on the screen or not delta V is being calculated somewhere in the game.

I assume you mean the m/s countdown next to the burn timer. That's just the magnitude of the maneuver vector, which doesn't tie into the complexity of craft design at all. Calling it "delta V" is technically correct, but not really relevant.

1 hour ago, Snark said:

^ Gotta say I tend agree with regex here.  Mainly because it appears (with the announcement of "Making History") that Squad is shifting resources away from core game development and seems likely to focus their time on expansions, going forward.  They're a business, they gotta pay the bills-- and at this point, I suspect that packing more big, expensive-to-develop features into the core game, for free, is unlikely to generate any revenue for them.  So at this point, alas, it's probably the right business decision for them not to.

Any thoughts as a professional software engineer on how we as customers/users can prevent situations like this, where things that need to be worked on never are? Should we have refused to buy KSP until it had a working burn time indicator? Should we have sought refunds when we discovered pieces like this were missing?

[Snark]

21 minutes ago, Gaarst said:

I can understand that it's not a trivial piece of coding, but you and other modders (I don't who wrote the original KER dV/burn time calculator, which was probably refined anyway) did it in their free time.

That's right.  Because we have free time.  Scads of it.

Squad devs... don't.  Whatever else one may say about them, I don't think anyone is proposing that they've ever been sitting around twiddling their thumbs without enough to do.  My impression is that they've been frantically busy pretty much continuously, all the time, for as long as I've been playing KSP.

23 minutes ago, Gaarst said:

Squad should be able to do it themselves*.

"Able", yes.  That doesn't mean the same thing as "it's the right development decision, given all the other priorities they have on their plate."

25 minutes ago, Gaarst said:

I think the "it's too complex" excuse is not valid in this case

It's not an "excuse"-- it's an exercise in workflow optimization.  It's totally doable.  But the fact that it's so complex means that it's a really expensive feature to deliver, which means it would suck a lot of oxygen out of the room for all the other features (and bug fixes) that are also really important.

It's how things work in software development.

28 minutes ago, Gaarst said:

Hopefully, after 1.3 and the expansion, 1.4

Much as I'd like to see a 1.4, I wouldn't hold my breath.  My guess would be that at this point, the core game is basically just in "keep the lights on" mode while they devote their real time and energy to working on "Making History" (and perhaps subsequent expansions that they can charge for).

Pulling out my crystal ball for a moment, my best guess is that we may see a few minor 1.3.x type updates to the core came... but if we do, it'll only be for bug fixes, and/or any changes they need to make to the core game in order to enable particular features of future expansion packs.

I could be totally wrong about that, of course.    I don't work for Squad, and therefore don't have any more visibility than you do into their internal decision-making process.  But I've been working in this industry for a long time, and I've shipped and awful lot of products from a lot of companies, and that's what my gut tells me.

32 minutes ago, Gaarst said:

1.4 will be a polishing update solving these issues

Let's be clear-- this is a major feature.  So it's not a "polishing" kind of update, it would be a "major feature release" kind of update.

33 minutes ago, Gaarst said:

Plus, as opposed to modders, they have the possibility to change existing bits of code to (perhaps) make the task easier.

Not in this case.  The reason this is hard is not because "trying to work through the modding API is awkward", but because it's a fundamentally difficult design problem.  So no, it wouldn't be even slightly easier for Squad to do this than it would be for a modder.  Considerably more laborious, in fact, since they'd need to go through a rigorous QA / testing process, which mods don't.

1 minute ago, Alshain said:

I understand that from your perspective as the developer of BBT, again your mod is a good mod.  I'm not saying you slacked off or anything, I would have made the same decision in your shoes.

Oh, no problem, I didn't take it that way at all. 

1 minute ago, Alshain said:

However, I expect more from the developer of this game and if KER can do it, so can they.

Absolutely, expect more from the developer of the game.  No argument there.

And yes:  if KER can do it, so can they.

The problem is that "can" simply isn't even vaguely enough.  Software development projects are always under the budget & scheduling gun.  There are always far more things to do than there are time, money, and engineers to do them.  Which means everything is a tradeoff.  It's a zero-sum game.  Doing one thing means not doing something else.

And deciding what not to do... is really really hard.  Speaking as a developer myself:  deciding "which really cool, really useful feature do we cut" feels a lot like deciding "I can't feed all my kids, which one do I give up for adoption".  It's difficult, and seriously un-fun.  But it's necessary.

The typical discussion that comes up whenever some feature is proposed goes like this:

1. What's the benefit?  (i.e. how badly do we need this?  what does it gain?  what does it lose if we don't?)
2. What's the cost?  (i.e. how many dollars and engineer-hours is it likely to be?)

Put those two things together, then compare the various proposed features, bug fixes, etc. to see how they stack up, and that's typically how the priority goes.

Yes, it's a glaring hole that KSP doesn't have a better burn time indicator.  But there are plenty of other glaring holes, too.  (Unavoidably so; finite resources, finite time, small team-- you can't do everything.)  And there are other, formerly glaring holes that aren't there anymore, because they did get addressed.  But at least some of those former holes wouldn't have gotten filled in, if they'd decided to give us a burn time indicator and/or dV display instead.

So, if you're prepared to point at some other feature in the game of comparable complexity (i.e. "number of engineer-hours required to implement") that you (and a majority of KSP players) wish they would have cut in order to make room for a burn-time indicator, then that's a perfectly valid thing to do and we can have a discussion about that.    But "add this extra thing" simply isn't something that happens.  It's always "do this thing instead of that thing."

I'm not saying that they necessarily made the right decision.  Just that I don't know that they necessarily made the wrong one, either-- certainly I don't think it's a slam-dunk.

[Snark]

45 minutes ago, HebaruSan said:

Any thoughts as a professional software engineer on how we as customers/users can prevent situations like this, where things that need to be worked on never are?

The short answer is:  Provide frequent, good, constructive feedback, somewhere that the developers can see it.

It's worth noting, though, that you're phrasing it wrong.

Everything needs to be worked on.  All the time.  It's how software works.  And it's an economic reality that there's never enough time, money, and people to do everything.  Which means, invariably, there's going to be stuff that "needs to be worked on" and never is.

So, if your complaint is about "software that has something missing that needs working on that never is", you've just described basically every single piece of software in the history of the universe, past present and future.

The issue here is therefore not "they didn't give us X".  The real issue is "they gave us Y instead of X", where Y is some other (hopefully important) feature or bug fix.

So, with that in mind, here's what the real question should be:

Quote

How can we as customers prevent situations where the company provides the wrong features, and gives us X when we would rather have had Y instead?

The answer is simple:

We do it by providing frequent, constructive, vocal feedback about what we like (or don't).

Such as this thread, for example , and others like it.

This helps the software developer by letting them know what's important to their customers.  (It's not always obvious, when you're sitting in the developer's chair).

For example, if you went to them and said:  "I really want a better burn time indicator.  Please stop fixing bugs with the wheels and leave them broken, because I never play with rovers anyway.  So please give me a burn indicator instead, it's way more important."

• And then a hundred people will chime in and agree with you.
• And then a hundred rover fans will join in with howls of rage, saying the exact opposite:  "must fix wheels NAO, forget the stupid burn indicator, it's less important".
• And then a hundred other people will say they should be working on yet some other feature, never mind the wheels and the burn time.

And then, one hopes, somebody at the company would pick through all the feedback and try to form some sort of coherent picture of what most players want, and then try to chart a course through the rocky shoals of Can't Please Everyone.

45 minutes ago, HebaruSan said:

Should we have refused to buy KSP until it had a working burn time indicator? Should we have sought refunds when we discovered pieces like this were missing?

Sure, if this is such a big deal to you that you honestly think KSP wasn't worth your money without it.

But... really?

I dunno about you, but that's laughably not the case for my own experience.  I adore KSP, spent US $27 in exchange for literally thousands of hours of entertainment.  I don't think I've ever seen that kind of value proposition from any product I've ever bought, software or otherwise.  It could be shot full of a lot more holes than it actually has, and still be way way way on the "plus" side of the ledger for me.

Does that mean I like the holes?  No.  But I keep them in perspective.  It's a little indie game by a small team of developers sold at relatively small volume (compared with something like Starcraft), developed on a relative shoestring, so it's gonna have the kind of warts and imperfections you get when you buy, say, a hand-crafted mug at an art store instead of something cranked out by a mega-factory.

So what do I do about it?  When I see something I don't like, I provide constructive feedback here in the forums.  If enough people do the same, and if it's not too hard to fix, often they actually fix the problem.  If it doesn't make the cut, then it doesn't, and I pick up and move on with life.

(And if the problems are too numerous relative to the value I get from the game, and if the developer seems too unresponsive, and it's making the game not worth my while... then I vote with my feet-- or, more to the point, with my wallet-- and go elsewhere.  Fortunately for me, I've never gotten close to that point with KSP.)

You'd be surprised how effective good constructive feedback (as distinguished from "yelling") can be.  Speaking as a software developer:  good constructive feedback is golden, and is a great way to influence developers.

I know it seems sometimes like "this damn game is full of holes, they're asleep at the switch"-- but as with any software, for each high-visibility thing that isn't fixed, there are a hundred time consuming things that are, which may not even get noticed.  (But would have, loudly... if they hadn't been fixed.)

[HebaruSan]

16 minutes ago, Snark said:

It's worth noting, though, that you're phrasing it wrong.

No, I'm not, and your rephrasing loses the point of the question. Other people might have good reasons for how they phrase things, and if it looks wrong to you, it might be worth asking whether you missed something.

18 minutes ago, Snark said:

So, if your complaint is about "software that has something missing that needs working on that never is", you've just described basically every single piece of software in the history of the universe, past present and future.

No, I haven't, because we're talking about a "glaring hole." Super Mario Bros is an old, simple piece of software, but its UI indicators are all fully functional. It would be cool to be able to fly or to add whole new maps, but the features are complete for what they are. I would not describe Super Mario Bros as "things that need to be worked on never are." Is the point clear yet?

18 minutes ago, Snark said:

The issue here is therefore not "they didn't give us X".  The real issue is "they gave us Y instead of X", where Y is some other (hopefully important) feature or bug fix.

Sure, but that's only from the perspective of one instant in time. There's also the long term view, over which it should be possible to address the "glaring holes" in a product if development continues long enough and is well planned. And as you noted, the KSP dev train seems to be coasting to a stop now with things like the burn time indicator left out.

The point of my carefully considered phrasing was, is there any alternate configuration of customer behavior that could have stretched development out over time so these dilemmas of yours would not have persisted, where they could fix the rover wheels and then also fix the burn time indicator, because development is continuing? For example, if we took the same number of purchases over time and just slowed them down, maybe the anticipation of more customers would encourage development to continue even now? There are reports of KSP money flooding in and being used for other things in the early days, which obviously is suboptimal if evaluated from a bang-for-buck software quality point of view.

If you don't think so, that's fine, but yet another "omg dev is hard" lecture isn't really helpful.

[monstah]

Nothing gets me faster on a KSP Forums mood than logging in after a long hiatus and reading one of @Snark's wonderfully verbose posts

Anyway, on one hand, I understand Snark when he says it's more than a just couple hours of coding. On the other hand, weighing more, is the fact that any improvement is welcome in this area. Sure, your Better Burn Time mod might not be perfect, but damn, it's a blessing. If they just integrated it as-is (with your permission, obviously), or better yet, with just the minor tweaking necessary to ensure that it's actually integrated in the core code and not a "tangential" mod-hook code (is this more than a few hours?), I believe everyone would gain from it.

[Guest]

1 hour ago, HebaruSan said:

The point of my carefully considered phrasing was, is there any alternate configuration of customer behavior that could have stretched development out over time so these dilemmas of yours would not have persisted, where they could fix the rover wheels and then also fix the burn time indicator, because development is continuing?

Personally, I don't believe so. That sort of thing is more dependent on the company willing to give the dev team more resources (time, money, help) than the customers. Even if the customers help drive priority that still depends on what the team (and company) believe is possible during the current iteration (sprint, what-have-you). In fact, I would argue that slowing down profits would have hurt KSP much more in the log term; we'd have less of a game than we have today (this based on outside observations of Squad and, no, I'm not going to elaborate).

A driving, continuous, thoroughly constructive criticism from a very large chunk of the userbase (Reddit, in the case of Squad) would likely re-prioritize things but the dev team still has to work with the resources they have (i.e. what the company will give them).

[severedsolo]

4 hours ago, Snark said:

I've seen no evidence in the game to indicate this, and I've also seen nothing in any of the modder-accessible APIs that I've tinkered with (and I've done that a lot, in the course of writing BBT).

There is evidence in the API to suggest that at one point at least, Squad were working on DeltaV. There is a method called VesselEngiUtil.GetDeltaV(Vessel) - it doesn't actually do anything (just returns 0) but it's there.

Not that it changes what you were saying of course, but I thought it was interesting.

Edited May 23, 2017 by severedsolo

[Alshain]

@regex  I just wanted to say I love that you mentioned Sprints. I don't know how this conversation went from burn times to development methodologies, but the mere imaginings of what KSP development would have been like if they used Scrum gave me giggles.

[Guest]

1 minute ago, Alshain said:

@regex  I just wanted to say I love that you mentioned Sprints. I don't know how this conversation went from burn times to development methodologies, but the mere imaginings of what KSP development would have been like if they used Scrum gave me giggles.

Wouldn't that be something, Squad delivering an MVP every month or so...  They claim it's Agile but it seems more like a modified Waterfall. Whatever, no dev house works the same. Even mine modified Scrum to suit our needs, moved the entire company over to a Scrum-type process (except for the two of us on the sysadmin team, hard to measure goal completion when it changes daily...)

[Alshain]

21 minutes ago, regex said:

Wouldn't that be something, Squad delivering an MVP every month or so...  They claim it's Agile but it seems more like a modified Waterfall. Whatever, no dev house works the same. Even mine modified Scrum to suit our needs, moved the entire company over to a Scrum-type process (except for the two of us on the sysadmin team, hard to measure goal completion when it changes daily...)

The only problem with modifying Scrum is that it usually removes all the benefits of Scrum.  You might as well stick to waterfall.  I've worked for companies that have done all 3 (waterfall, scrum, and mod scrum), and never could see an improvement of a modified scrum over waterfall.

Edited May 24, 2017 by Alshain

[Guest]

@Alshain It depends on the company and their culture, really. And all Scrum processes will end up modified; there are a lot of choices to be made within the method, at least insofar as was driven home to me by a long-time scrum master from a local game company. Probably his most salient point was constant, incremental examination and adjustment, and whether that's a generally good business strategy or straight Scrum ideology doesn't really matter to me. Every company, and even every team within a company, has to find something that works for them in order to deliver an MVP every sprint. And at the end of the day you may find a Waterfall method works best for your company or product.

[Alshain]

@regex Well, you can customize it, it's fairly open in that regard.  When I say "modified", I mean fundamentally.  One of the worst things I've seen is a company that claimed to be Scrum, but they had externally assigned team managers.  Ultimately, all feedback from the owner was eliminated because the manager was "in charge" and often times it felt as if we had no idea what the owner or client actually wanted.  Honestly, I think waterfall would have been even better.  I didn't last long at that job, eventually (actually rather quickly) I got so frustrated with the whole setup I decided to find a better place to work.

[Guest]

9 minutes ago, Alshain said:

@regex Well, you can customize it, it's fairly open in that regard.  When I say "modified", I mean fundamentally.  One of the worst things I've seen is a company that claimed to be Scrum, but they had externally assigned team managers.  Ultimately, all feedback from the owner was eliminated because the manager was "in charge" and often times it felt as if we had no idea what the owner or client actually wanted.  Honestly, I think waterfall would have been even better.  I didn't last long at that job, eventually (actually rather quickly) I got so frustrated with the whole setup I decided to find a better place to work.

Ah yeah, "customized" might have been a better choice of words, lol.

Christ, that sounds terrible...

[juanml82]

9 hours ago, Alshain said:

I understand that from your perspective as the developer of BBT, again your mod is a good mod.  I'm not saying you slacked off or anything, I would have made the same decision in your shoes.  It's not worth it as a modder unless your mod is already doing that (like KER)

However, I expect more from the developer of this game and if KER can do it, so can they.

Of course they can. But they need to balance all the stuff Snark said vs. "modders (and beta translators) will complete this game for free". The business choice is easy: enjoy the benefits of outsourced free labor

Edited May 24, 2017 by juanml82

[John FX]

At the end of the day it boiled down to a simple formula :

(money in - profit)=money left for development.

Either money in was too small or the profit was too large for there to be enough money left for development.

 

It is like the rocket equation for game development.

[Snark]

23 hours ago, HebaruSan said:

yet another "omg dev is hard" lecture isn't really helpful.

Heh, sorry about that. 

But if you ask "why are things this way?", and suppose-- just for the sake of argument-- that the answer really is "because dev is hard"... what sort of a response would you find helpful?

I'm honestly not trying to be sarcastic or dismissive here, I'm perfectly sincere.  Don't mean to lecture, nor do I claim to have the One Right Answer-- just trying to provide some perspective on a seriously asked question, from someone who's been doing this for a living for a really long time.  Take it for what it's worth.

Anyway, in case there's anyone out there who does find it helpful, here's some more "omg dev is hard" lecture: 

 

23 hours ago, HebaruSan said:

No, I'm not, and your rephrasing loses the point of the question. Other people might have good reasons for how they phrase things, and if it looks wrong to you, it might be worth asking whether you missed something.

No, I'm pretty sure I understand exactly what you meant.  Here's my understanding of your position, please correct me if I'm missing something:

1. You don't like that the feature's not there.
2. You think that Squad should have fixed it, long ago, and that they were being derelict in their duty by not doing so up to now.
3. You also believe that they're especially blameworthy if they don't do it henceforth, and just leave it in its current state.

Does that pretty much capture the essence, or am I missing something important?

Various rambling thoughts about that in a spoiler section, to spare folks the brunt of my verbosity.

Spoiler

I'm completely with you on point #1 above.  I totally understand people's frustration with the lack of a desired feature.  Heck, as a player the rudimentary stock burn time indicator bugs the heck out of me (which is why I wrote BBT, after all).  So I'm totally with you on that one.

However, when it comes to points #2 and #3... well, everything that happens has a reason.  Might be a good reason or a bad one, but there's a reason.

And having experienced many similar situations in my own work, I can tell you that there are plenty of ways that "glaring hole doesn't get fixed" can happen for reasons that aren't because someone is stupid, evil, greedy, lazy, or anything else.  It can happen for reasons that make perfect sense, and may actually be the right decision for the people working on the software-- but those reasons aren't necessarily visible from the customer's point of view.

So, when I see someone saying "Why the heck didn't the company do X?  They're wrong not to have done that!"... I can interpret the person's comment in a few ways:

• Maybe they're just venting, because they are unhappy with their experience and just need to blow off steam.
• Or maybe the "why" is an actual, sincere, non-rhetorical question, and they honestly want to know the "why".
  • ...and perhaps they're looking for a practical "so what should I/we do, to make it better?" type of advice, as well.

If the person's just venting, there's nothing wrong with that (as long as it's not done abusively, which I haven't seen anyone doing in this thread).  We all need to vent once in a while, it's perfectly natural.  But it also means that they've pretty much made up their minds and aren't going to be interested in hearing any explanation, however reasoned or well-informed, that might be a "legitimate" explanation.  In my experience, such a person's likely to take umbrage at any attempted explanation, because no matter how it's phrased, they may take it as questioning the legitimacy of their complaint, which of course would annoy anyone.

On the other hand, if they're honestly curious about the reason, then it seems reasonable to try to provide an explanation "this is why things are this way" and "here's what you can do" (if anything; sometimes there isn't).

I interpreted your statement and question as being in the latter category ("genuinely curious"), thus the answer.  Apologies if I misconstrued.

My rephrasing changes the point of the question, by design-- because the point of your original question, though perfectly reasonable from a customer's point of view, doesn't reflect the reality of how software development actually works-- at least, not in my experience over the past couple of decades of doing this for a living.

It's perfectly valid to take a customer-viewpoint approach of "This is a flaw in the product; I don't like it, I'm never going to like it; I don't care what the reasons are".  Totally legitimate.  But if that's the case... it's hard for me to see the point of asking "why is it that way?" or "what should we do?"

23 hours ago, Snark said:

So, if your complaint is about "software that has something missing that needs working on that never is", you've just described basically every single piece of software in the history of the universe, past present and future.

23 hours ago, HebaruSan said:

No, I haven't, because we're talking about a "glaring hole."

Sure, it's a "glaring hole."  But all that does is reduce my original statement from "every single piece of software in the history of the universe" to "most software in the history of the universe."

Lengthy explanation in another spoiler section, but the TL;DR is:  often, releasing software with a "glaring hole" is actually the right thing to do (not just from a company-business perspective, but also from the customer's perspective, even if they don't know it).

Spoiler

A fundamental truth about software development that is really important to understand, or none of this will make any sense:  The severity of the problem has nothing to do with the feasibility of fixing it.

"How bad is the problem" certainly affects how much you want to fix it.  But has nothing to do with whether you can.  The latter completely depends on other factors-- time, budget, staffing, etc.

There are plenty of things to work on, for any piece of software.  Including plenty of "glaring holes", at least in early development.  No software is ever perfect.  There are always bugs, feature holes, etc.  Always.

So... how does anyone ever release anything that's not such horrible crap that it goes down in flames once it hits the market?  Well, the process of developing and releasing software looks like this:

1. Make a thing.  (It hasn't been released yet.)
2. It's imperfect.  It has bugs, feature holes, etc.  But it's basically runnable, at least enough to test and evaluate.
3. Decide what the worst problems are.
4. Spend time to work on some of them.  The product is now incrementally better than it was (though still problematic).
5. Decide "is it good enough to release yet?"  If not, go back to step 2 and repeat.
6. Ship it.

The process of working on software consists of many, many cycles of steps 2 through 5 above.  Eventually you get to the point where you decide "ship it", and then you do.  Seems pretty reasonable, right?

There's nothing super hard to understand about the above-- at least in broad outline-- even for folks who have never worked in the industry.

However, understanding the rationale of step #5-- i.e. how does one decide "can we ship it", and what factors go into that decision-- is a lot more complicated and nuanced than it looks to the lay-person.

It depends on a lot of things:

• What's the target audience?  What's their tolerance for imperfection?  Would they rather have an available product that has some flaws, or would it be better to have no product at all?  (To put this in concrete terms:  Yes, the KSP burn-time indicator annoys you.  But does it annoy you so much that you wish you had never bought KSP in the first place?)
• How big is the financial commitment of the customer, relative to the value the product provides?  Somebody who spends $10K on a product is going to have much higher expectations than someone who dropped a buck on a game app for their phone so they can kill time on the bus.  (The concrete example from the customer's perspective:  Do you think KSP is so bad that you wasted your money?  You think that it hasn't provided a reasonable amount of value for the amount of money you spent?
• What's your budget?  How much time do you have to do it?  How many engineers?
• How many units do you expect to sell?  (This affects the budget you can afford to spend on production.)
• How hard is the problem you're trying to solve?  (This affects how expensive it is, in time and effort, to make things rosy.)
• Do you have any hard time constraints?  (e.g. "We have to ship by date X, regardless of the state of the product, because we're going to run out of money and we'll go out of business if we don't make that date.")
• And so forth.

Sometimes, of course, companies do make what any reasonable customer would consider to be stupid or even nefarious decisions.  There are companies out there who think of their customers as an expendable resource, to be milked dry of their money, and who cares if the customer gets screwed over-- hey, we've already got their money, right?  Such companies are generally short-sighted and stupid, since word gets out; that sort of behavior eventually catches up with you and then you lose money when people stop buying your crap.

But in my experience, most companies aren't that dumb.  They usually have good, logical reasons for doing what they do-- but those reasons usually aren't visible to the customer.  Which leads to a lot of customer annoyance.  But the fact that the customers are annoyed doesn't eliminate the fundamental calculations about why something doesn't get fixed.

It certainly influences the calculations-- "how bad is the customer pain" is one of the factors going into the "do we ship it yet" decision.  A pretty damn important one, at that.  But it is far from the only factor, and depending on the harsh realities of the situation, it might not even be the dominant one.

Customer pain is the tip of the iceberg.  It's the only aspect of the decision that is visible to customers.  The other aspects may very well be huge and inflexible... but they're often invisible from the outside.

I guess what I'm trying to say is... if you see something as a customer that you don't like, by all means get angry about it, and speak up.  But please don't assume that you're seeing the whole picture, when you're only seeing the tip of the iceberg.  Of course it's your prerogative to say "I don't care what their invisible reasons are"-- but if you do, then it becomes essentially impossible to have any practical discussion of what should be done.

You go on to say,

23 hours ago, HebaruSan said:

Super Mario Bros is an old, simple piece of software, but its UI indicators are all fully functional. It would be cool to be able to fly or to add whole new maps, but the features are complete for what they are. I would not describe Super Mario Bros as "things that need to be worked on never are."

Sure!  Absolutely, no argument there.  But if you're comparing Super Mario Bros to KSP, you are comparing apples and oranges. 

More lengthy explanation in a spoiler, but the TL;DR is:  "yes, of course it's different, because completely different situations produce different results, and Mario had the situational advantage in many ways."

Spoiler

The situations are completely different, and the deck is stacked in Mario's favor in just about every way.

• Volume.  The original Super Marios sold over 40 million copies.  The series has sold over 300 million. KSP is vanishingly tiny in comparison-- we don't have released sales figures, but "1 million" seems like a reasonable ballpark guess.  The fact that Mario is vastly more lucrative than KSP means that Nintendo can afford to throw a lot more resources (engineers, testers, designers, etc.) than Squad ever possibly could.  The gap is gargantuan.  Which means you end up with something a lot more polished.
• Risk.  Nintendo is a vast, established corporation with uncounted scads of profitable products out there, and a lucrative decades-long history.  They've got very deep pockets, and they can afford to take risks on a product because they have all their other products to carry them along.  So, for example, "spend a very large amount of money developing a product that you think will sell well, but might flop" is something they can do.  Squad, on the other hand, is pretty much a one-trick pony.  Apologies for the mixed metaphor, but they've got all their eggs in the KSP basket.  That puts serious constraints on what a company can do-- betting the business on one product is scary, and it can affect your risk profile.  Releasing a product with flaws that may annoy customers is a risk, of course... but so is spending ever-higher piles of your dwindling cash reserves to try to perfect it before you put it out the door.
• Complexity.  Quite aside from the technology difference between the 1980s and the 2010s, KSP is, simply put, tackling a much harder design problem than Super Mario had to.  Which means you're going to have a higher percentage of problems, holes, etc. for a given amount of investment.
• Environment.  Super Mario was running on a console-- and not just any console, but a console produced by the same company.  They had a completely predictable, reproducible environment.  I do not have words to express how valuable that is to a software developer-- it makes things much easy to code and debug.  KSP, on the other hand, is running on a plethora of platforms.  And even if they only shipped on one-- say, for Windows PC-- it's still a much harder environment.  Different players will have varying OS versions, RAM amounts, video cards, drivers, CPU, and so on and so forth.

So, yes.  Super Mario is a lot more polished and "complete" than KSP is.  Because it was produced in a very different situation with very different available resources, targeting a very different type of environment.  So the result is very different.

So?

Moving on,

23 hours ago, Snark said:

The issue here is therefore not "they didn't give us X".  The real issue is "they gave us Y instead of X", where Y is some other (hopefully important) feature or bug fix.

23 hours ago, HebaruSan said:

Sure, but that's only from the perspective of one instant in time. There's also the long term view, over which it should be possible to address the "glaring holes" in a product if development continues long enough and is well planned.

Sometimes it works that way, yes.  It would be great if it worked that way all the time-- certainly it would make my day job a lot less stressful. 

But, very often, it doesn't work that way, even for a company that's diligent and forethoughtful and trying to plan ahead.  The fact is, there's always more stuff to do.  And a "glaring hole" can legitimately go for a really long time-- perhaps indefinitely-- if there are always, continuously, bigger fish to fry.  Which is, alas, all too often the case, in my experience.

Heck, I've experienced this personally in my daily life on the job.  In my current environment, on my current team, there's an ...issue.  It's been around for over a year.  Without going into details, it's a royal pain in the posterior, and everyone on my team-- me, my teammates, my manager-- would love to see it go away.  But-- and here's the rub-- it would take at least a continuous week of my time, more likely two weeks, to fix.  As in, "drop everything else and do nothing but work on this one thing for a solid couple of weeks."  And guess what?  Not once in the past year has there ever been a two-week window where it would be okay to drop everything.  Because it's a pain point, yes, but there are other, more urgent pain points.  So it doesn't get worked on-- and not working on it is actually the right decision in our case, since this other stuff is genuinely more important and urgent.

I'm not trying to defend or apologize for Squad, here.  For one thing, the lack of this feature annoys the heck out of me, as a player.  For another, since I don't work there, I have no visibility into their internal workings and don't know any more about what actually happens there than you do.  Heck, for all I know, you may be right, and maybe they are being derelict in some fashion and "it didn't have to be that way."

But we don't know that.  And looking over the past 20+ years of miscellaneous crises and fire drills, I gotta say that in my experience, the cases of "there are good reasons for what happened, even when everyone was making a good-faith effort to do the right thing" vastly outnumber the "whole organization is boneheaded or irresponsible" ones.  So I'm inclined to give the benefit of the doubt.

For example, and to make things a bit less abstract:  Consider the SAS tuning in KSP.

Remember how horrible it used to be?  Remember how it would overshoot all the time and result in slow, agonizing oscillations?  Remember how you'd tell it to "hold retrograde" or whatever, and the nav ball would start going in the wrong direction entirely?  Remember how a vessel with overpowered reaction wheels would jitter like a crazed gopher after a triple shot of espresso?

It was horrible.  Certainly, for me as a player, it was a lot more impactful than the burn-time indicator.  After all, the problems with burn time only affect me when I'm executing a maneuver node, but the SAS problems got in my face all the time whenever I'm trying to steer my ship.

And it's not as if it's an insuperable technical problem.  Non-trivial, sure-- I don't mean to make light of it.  But certainly it's not any harder than solving the burn-time indicator issue-- easier, in some ways.

But despite being arguably worse for players than the burn-time, and despite being (presumably) not any harder to solve... it lasted frickin' forever.  They didn't get around to fixing it until 1.2!

So... why do you suppose that is?

• Is it because they didn't know how to fix it?  Clearly not.  They did fix it.  It's not rocket sci-- well, okay, it is, but it's well within the technical capabilities of the kind of dev who works at Squad.
• Is it because they don't know about the problem?  Absolutely not.  Everyone was complaining about this, for years, constantly and loudly.  They obviously knew about it and were well aware of the impact on players.
• Is it because they simply didn't give a damn about the players?  I strongly contend no.  During the time leading up to 1.2 (though, alas, not any more), the Squad devs were very approachable, often online in IRC and/or posting here in the forums.  They're clearly passionate, dedicated people who don't want to ship crap, take pride in what they do, and clearly want to give the players a good experience.

So:  given that they knew about the problem, had the wherewithal to fix it, and (presumably) really wanted to fix it... why the heck did it take so long to fix?

There's only one answer that makes any sense to me, and that is:  because they were busy with other stuff that was more important.  And so it literally wasn't until 1.2 that they had enough breathing space to take care of that.

Players were justifiably irate that they had to wait so long for such an important fix... but unfortunately, that doesn't change the practical realities of software development.

23 hours ago, HebaruSan said:

The point of my carefully considered phrasing was, is there any alternate configuration of customer behavior that could have stretched development out over time so these dilemmas of yours would not have persisted, where they could fix the rover wheels and then also fix the burn time indicator, because development is continuing?  For example, if we took the same number of purchases over time and just slowed them down, maybe the anticipation of more customers would encourage development to continue even now?

Well, goodness knows I'm no marketer, nor do I claim to have a crystal ball.

But if I had to take a guess?  I wouldn't be surprised if the answer to your question is "no, there is no such configuration".

Slowing down customer purchases would have sent the signal to the company "this is an unpopular product and isn't making as much money as you hoped."  It would have reduced the cash flow which is the oxygen supply of any business-- it would have reduced their ability to hire and retain developers, and therefore the amount of engineer hours they can spend on the product.  So taking a strategy like that may very well have backfired-- e.g. they may have just decided to pull the plug on KSP and go elsewhere.

More rambling on this aspect in yet another spoiler.

Spoiler

Remember, this is a small all-their-eggs-in-one-basket company we're talking about, not some thousand-shipping-titles, deep-pocketed titan like Nintendo, which can afford to take risks that little guys can't.  For the big players, if one product tanks, it's not an existential threat to the company, nor does it impact their ability to spend money on fixing that product.

To take an analogy:  Let's say I'm supposed to run as fast as I can, and you're annoyed that I'm not running fast enough, so to motivate me, you put a tourniquet around my neck and start to tighten it.  And the only way for me to release it is to run faster.  Well, that can give me an incentive to run faster... but it hurts my ability.  If the reason I wasn't going fast enough to suit your tastes was simply because I'm a lazy slacker, then sure-- the threat of strangulation certainly would make me pick up the pace.  But if I was already running as fast as I could... probably all you'd achieve would be to make me flop over dead.

Without insider knowledge of what goes on at Squad, of course, both scenarios are possible.  However, I gotta say that based on my observations of them-- and of companies in general-- the "lazy slacker" explanation seems kind of unlikely to me.

Also:  There's a fundamental problem with this idea,

23 hours ago, HebaruSan said:

if we took the same number of purchases over time and just slowed them down, maybe the anticipation of more customers would encourage development to continue even now

...namely, they have no way of knowing that it's going to be "the same number of purchases".  All they would observe is "It's not selling".  So, "If we spent a lot more on development, it would sell better and we'd have more money" is one potential interpretation, sure.  But so is "If we spent a lot more on development, we'd be throwing money down a hole, so we should pull the plug now and cut our losses."

 

[HebaruSan]

1 hour ago, Snark said:

No, I'm pretty sure I understand exactly what you meant.  Here's my understanding of your position, please correct me if I'm missing something:

1. You don't like that the feature's not there.
2. You think that Squad should have fixed it, long ago, and that they were being derelict in their duty by not doing so up to now.
3. You also believe that they're especially blameworthy if they don't do it henceforth, and just leave it in its current state.

Does that pretty much capture the essence, or am I missing something important?

No, not at all. Not even close, and I really wish you would stop projecting this attitude onto every single person who criticizes any aspect of this game or its development. I don't care at all about things like "derelict" or "blameworthy." I don't think I'm entitled to anything, and I don't think SQUAD owes me anything. I fully acknowledge that SQUAD responded to development pressures and market signals rationally (and in fact my question assumes it!). Please, please try to respond to the words people actually use rather than concocting nonsense like the above.

I am looking at my Steam software library and contemplating whether there are any actions I can take (along with my fellow consumers, possibly with some sort of explicit coordination) to end up with fewer products with "glaring holes" in them (and ideally more products without them, rather than just fewer products overall). That's it, that's all. So I'll skip to the part of your post where you finally address that question.

1 hour ago, Snark said:

Well, goodness knows I'm no marketer, nor do I claim to have a crystal ball.

But if I had to take a guess?  I wouldn't be surprised if the answer to your question is "no, there is no such configuration".

Slowing down customer purchases would have sent the signal to the company "this is an unpopular product and isn't making as much money as you hoped."  It would have reduced the cash flow which is the oxygen supply of any business-- it would have reduced their ability to hire and retain developers, and therefore the amount of engineer hours they can spend on the product.  So taking a strategy like that may very well have backfired-- e.g. they may have just decided to pull the plug on KSP and go elsewhere.

More rambling on this aspect in yet another spoiler.

  Hide contents

Remember, this is a small all-their-eggs-in-one-basket company we're talking about, not some thousand-shipping-titles, deep-pocketed titan like Nintendo, which can afford to take risks that little guys can't.  For the big players, if one product tanks, it's not an existential threat to the company, nor does it impact their ability to spend money on fixing that product.

To take an analogy:  Let's say I'm supposed to run as fast as I can, and you're annoyed that I'm not running fast enough, so to motivate me, you put a tourniquet around my neck and start to tighten it.  And the only way for me to release it is to run faster.  Well, that can give me an incentive to run faster... but it hurts my ability.  If the reason I wasn't going fast enough to suit your tastes was simply because I'm a lazy slacker, then sure-- the threat of strangulation certainly would make me pick up the pace.  But if I was already running as fast as I could... probably all you'd achieve would be to make me flop over dead.

Without insider knowledge of what goes on at Squad, of course, both scenarios are possible.  However, I gotta say that based on my observations of them-- and of companies in general-- the "lazy slacker" explanation seems kind of unlikely to me.

Also:  There's a fundamental problem with this idea,

...namely, they have no way of knowing that it's going to be "the same number of purchases".  All they would observe is "It's not selling".  So, "If we spent a lot more on development, it would sell better and we'd have more money" is one potential interpretation, sure.  But so is "If we spent a lot more on development, we'd be throwing money down a hole, so we should pull the plug now and cut our losses."

 

Thanks for the response. I suspected as much, but I figured it wouldn't hurt to ask.

[steuben]

Quote

Is it because they didn't know how to fix [SAS tuning]?  Clearly not.  They did fix it.  It's not rocket sci-- well, okay, it is, but it's well within the technical capabilities of the kind of dev who works at Squad.

Actually, it is control theory. It shares some math kinship with rocket science, and some of the applications are rocket science. In the specific cases it is simple with a known model, the math is well controlled. In the arbitrary model case, which KSP presents it, it gets... difficult. Even when using the very basic PID controllers that IIRC they were using. 

PID, Proportional Integral Derivative, controllers require about 110 to 150 hours of class time. Assuming you've got basic algebra down, about 40 hours if you have calculus down. If you have the knack for math, and you want to understand them. The fancier controllers H-infinity, sliding mode,  require much heavier math than basic calculus, and additional time to learn the controller besides. But are frickin' sweet in some applications.

That being said I can see why it would have taken several versions to nail it down.

Working on a similar problem to the burn time calculator, I can see why they went with a close enough algorithm. Any kind of  accurate prediction is invoking heavier math than I care to use on a daily basis. And is deeper math than most people know exists... even in rumor. 

Besides that's what correction burns are for.

 

 

[Snark]

9 hours ago, HebaruSan said:

I am looking at my Steam software library and contemplating whether there are any actions I can take (along with my fellow consumers, possibly with some sort of explicit coordination) to end up with fewer products with "glaring holes" in them

Definitely a fair question.  I note that you did in fact start the exchange with perfectly reasonable, matter-of-fact question in the beginning:

On 5/23/2017 at 9:49 AM, HebaruSan said:

Any thoughts as a professional software engineer on how we as customers/users can prevent situations like this, where things that need to be worked on never are? Should we have refused to buy KSP until it had a working burn time indicator? Should we have sought refunds when we discovered pieces like this were missing?

To which I directly responded, in the same spirit,

On 5/23/2017 at 10:19 AM, Snark said:

The short answer is:  Provide frequent, good, constructive feedback, somewhere that the developers can see it.

And then continued with illustrative examples and rationales, but it was basically all around the theme of "constructive feedback = helpful".  If that answers the question, then great-- probably would have been good for both of us to just stop there.  It also included my attempt to provide a more useful/relevant way of thinking about it (e.g. think "I'd like X instead of Y" rather than just "I'd like X"), since I've found that feedback tends to be more effective when one understands the situation that the recipient is contending with.

[Snark]

9 hours ago, steuben said:

Working on a similar problem to the burn time calculator, I can see why they went with a close enough algorithm. Any kind of  accurate prediction is invoking heavier math than I care to use on a daily basis. And is deeper math than most people know exists... even in rumor.

Actually, for burn time, the math isn't the problem.  In fact, it's almost laughably simple, just a bit of algebra tacked on to the rocket equation:

1. You know the dV involved (i.e. the magnitude of the maneuver node).
2. The rocket equation tells you how much fuel you need to use to get that much dV.
3. Use engine thrust + Isp to calculate how much fuel per second your engine burns.
4. Divide fuel-used by fuel-per-second.
5. Bingo, there's your burn time.

The fact that the math is so simple is why so many people underestimate the difficulty of the programming task.  I know I sure as heck vastly underestimated it.

The reason why it's hard, rather, is all the other stuff:  keeping track of the ship state, finding all the engines, dealing with their various thrusts and Isps and orientations and so on and so forth.  That's complex enough even if you just do what BetterBurnTime does.  If you want to get fancier, like KER, and actually model staging and fuel flow and such, it really gets gnarly.

So, it's not that it's "hard" in the sense of "have the brain of an Isaac Newton"... rather, that it's complicated because of all the infinite ways one can configure a spacecraft in KSP.  So it's a labor-intensive, time-consuming job.