[Kerbal Space Program patch 1.1.2 is now live!]

2 hours ago, JJE64 said:

EVERY job can say the same thing. Software/game development isn't special, except that it is apparently exempt from customer service concerns. The plumbing comparison is valid because we're not talking about the type of business, we're talking about the way you do business  

I did buy a product. I bought a computer game that was billed as released and marketable. I didn't invest in a Kickstarter project, I didn't join a club, I bought a product based on advertising and a promise of a good in exchange for currency. 

And as for those who think Squad would be justified in throwing up their hands and saying screw it and moving on, I would remind you of two things:

1.  Squad isn't a software company. This is a one-off thing for them. There isn't another project for them to go to, this is their whole deal  

2.  Bigger, actual established development houses have folded for less. This is a very competitive industry and Squad is lucky to have found a niche. The one product they make has never been stable and if they walked away from it now, it would probably be the end of Squad as a game maker.  If EA released a comparable game next month that actually worked as advertised, I'd be willing to wager that the vast majority of casual KSP players would buy it and KSP would go down as a footnote in game history, largely forgotten until it got rereleased as a gold classic on GOG in five years  

I bought this game at 1.0. As soon as it was released commercially I was one of those who said "shut up and take my money!"  I've since talked others into buying it and even bought it as a Christmas gift for one of my kids. But I'm sorry, as someone who DID buy a finished product, I've been sorely disappointed in it. 

 

I keep hearing complaints about Squad's 'customer service' as a core argument here, but really I would like to know what constitutes Customer Service in this case?  I understand the decision to release with a few undiscovered bugs was a bit hasty, but consider that they're pressured if they don't, and then griped at when they do.  They're working constantly to try and get the new stuff working right, but apparently that's STILL not good enough.

 

If I were to turn around and say I am the new self-appointed Customer Service Representative for Squad (Disclaimer, I'm not, this is a hypothetical), what would you like me to do about your product failure, good sir?  I can give you things like the list of bugs they are (or were) checking into.  What more would you like?  I could tell them, fix the bugs, but they're already working on that.  I could tell them not to release until it's ready, but then people will tell them to hurry up and release.

What is a complaint you have that Squad NOTCustomer Service can address for you?  Do you have a suggestion on how to solve it that we haven't looked into?

 

Dropping out of silly character, keep in mind that a LOT of bugs also don't show up during in-house testing, and only after the product has been released to the wild do some truly weird glitches start being found.  Things like this likely wouldn't be noticed by in-house staff.

 

 

Now, were this me making decisions, I'd actually look into an open beta a lot sooner than what was done.  Nothing finds bugs faster and more creatively than volume of users.  In the job I worked last year, I was tasked with hunting for bugs in OUR software for a few weeks.  53 bugs, 10 of them CTD priority, 5 of those requiring absolutely convoluted steps to reproduce.  Sometimes you have to deliberately do unusual things to the software to make it puke up errors.  Plug in numbers for letters, letters for numbers, check boxes that don't apply, drop down menus you don't need to, run subroutines that aren't relevant...  Ugly stuff.

 

[Kerbal Space Program patch 1.1.2 is now live!]

7 hours ago, JJE64 said:

You know, I started writing this whole long post about this thing and then I realized it just doesn't matter what I think.

But then there's this:

 

See, the thing is, it doesn't matter if we work in the industry or not.  We're a special group, known as "paying customers" who are dissatisfied with a product that has never worked as advertised.  If I pay a plumber to fix my pipes, I expect them to be fixed.  If I buy a car, I expect it to work.  If they don't, and the response you get from the people you paid was "you're not a plumber, you don't understand... if you think it's so easy, go to plumber school", well, there's a phrase for that... it's called "poor customer service".  If I buy a car and the engine does weird stuff, I expect the manufacturer to make it right, I don't need to be an engine expert or a car builder to have that expectation.  

But hey, the community will work to fix the lapses... as with ATM and DTL.  People are writing mods on their own time, creating patches on their own time, just to make the game playable.  It should be playable on day 1, and mods should add to the game, not make it functional.  But, admittedly, I'm not a software developer... I'm just some schlub who dropped his $40 on the table expecting to get a playable game.

Enjoy your vacation guys.

 

Your sentiment might make sense if comparing software engineering to plumbing was even remotely... Well, comparable.

 

See, your plumbing isn't like a program.  Your plumbing is more like a single line of code.  When your single line of code is broken, you can see it's broken and you know what's wrong and where.  You can pay the software engineer to come in and fix that one line of code easily.  The problem is found, you've directed him RIGHT to it.  It gets fixed.

 

Most people who answer you: "You're not a software engineer, you wouldn't understand" fall back on such a response because making people understand is a long and time consuming task.  Explaining the problems in software development is a time-consuming, and inefficient task.  The time spent telling you all about what's broken is time wasted.  You can't fix it, why bother wasting time explaining anything further?  If you take your car to the shop for repairs, or get your plumbing worked on, 'you' (to refer to most average people) can barely wrap your head around the problem as it is before you add in the industry jargon and knowledge of national/international standards.  And this is a simple problem that you can physically see(smell;hear;feel) and find.  The guys working on your stuff might humor you if you seem to at least understand what's going on to begin with, but will try and keep it short and simple.  They're there to fix it, not instruct you.

 

Now, looking back at your plumbing example...  I said that your plumbing is more like a single line of code.  If you want your plumbing example to hold water (pun not intended), then a program isn't your plumbing.  A program is plumbing, for an entire city.  Imagine, if you will, a city of 500,000 people, with a grand total of 10 plumbers to find and fix any leaks.

 

TEN PLUMBERS to cover a hundred square miles of buildings ranging from single-family homes, to sprawling office complexes and industrial facilities.  They have to go in, find the leaks, and fix them one at a time.  This, is programming.

Now, imagine that your ten plumbers are working with blueprints and schematics for a water distribution system built by someone else.  Now they have to keep things patched up and flowing without even intimately knowing everything going on below their feet.  This is programming on top of an engine, like KSP is built on top of Unity.

 

Now, imagine that you have ten plumbers, and then about a thousand people wandering around an otherwise empty city designed to hold 500,000, randomly shouting about how a water fountain isn't working in a park, or a toilet won't flush, or the shower's cold.  Imagine now, that only 100 of those people actually give detailed information about the problem.  Like the address, floor, room, and any other observations they discovered once they realized something was busted.

 

This is the reality of the situation a dev is presented with.  Hundreds of thousands of potential points of failure, policed by ten on-the-payroll workers, bombarded by failure reports with only a fraction of said reports actually useful enough to find and fix the problem.  And what makes it even better is that as useful as the failure reports are, they flood in from non-employees.  These are 'phone in' reports from customers who might have just woke up to discover their kitchen flooded.  Everyone wants their problem fixed, NOW.

 

People, across many program dev projects and boards, just seem to fail to understand this concept.  It's no wonder 'You're not a programmer, you wouldn't understand' has become the mantra.  You really aren't a programmer.  You really DON'T understand.  Your product isn't something that's been under constant development and improvement for a hundred years (cars), and it's not some simple break that's easy to find and fix (plumbing).  Software engineering just isn't the same kind of product/service that people are used to.  The reality is that it's FAR more complicated while still being all but On-Demand.  This is 'the standard', or really, compared to a lot of indy-devs,  above the standard.  You want that 'perfect and complete' feel in your software?  Look at the kind of money and product you get:  Microsoft's Windows operating system.  Easily $300 for the lowest end copies, still needs some patching after every new version, been in development and constantly built upon for almost 30 years now, and uses a small army of codemonkeys for said development backed by one of the largest companies in the software world.

 

Let me clarify something for you:  You spent $40.

You didn't buy a product.

You invested $40 in a project that is likely to be ongoing for another half-decade.  Buckle down and grit those teeth.  Sometimes it will be painful.  I've been waiting for the return of 64 bit and a fix for a major memory leak since this time last year.  A few more weeks to fix some additional bugs popping up?

 

I can wait.