Why most engineers cannot sell stuff
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
If you have an innovative product, customers will put up with quality problems. Once your product has competitors and becomes more of a commodity, quality and cost become important.
Robust Services Core | Software Techniques for Lemmings | Articles
<p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
<em>The fox knows many things, but the hedgehog knows one big thing.</em></p> -
If you have an innovative product, customers will put up with quality problems. Once your product has competitors and becomes more of a commodity, quality and cost become important.
Robust Services Core | Software Techniques for Lemmings | Articles
But ... a product - no matter how innovative and original - that is riddled with bugs gets remembered for the bugs, not the originality: when a competitor appears it's mentally compared against the buggy version, not the latest. Remember the Frontier: First Encounters[^] debacle? A "premium product" so riddled by bugs that PC Zone illustrated it's review with a turd tied up in a pretty bow: even making it shareware couldn't shift the bug-fixed version. It's a risk!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt -
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
You better learn to think in use cases. If the customer is only using the solid parts of your product he is fine. He should never leave the "happy path". Else he is doomed by the gods of software ... X|
Press F1 for help or google it. Greetings from Germany
-
But ... a product - no matter how innovative and original - that is riddled with bugs gets remembered for the bugs, not the originality: when a competitor appears it's mentally compared against the buggy version, not the latest. Remember the Frontier: First Encounters[^] debacle? A "premium product" so riddled by bugs that PC Zone illustrated it's review with a turd tied up in a pretty bow: even making it shareware couldn't shift the bug-fixed version. It's a risk!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
True. The quality needs to be improved in subsequent releases, or the product will get displaced.
Robust Services Core | Software Techniques for Lemmings | Articles
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
As long as they are not critical bugs like database corruption, its fine. Cosmetic bugs like some strange GUI behaviour are mostly tolerable. For Version 1, I mean.
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
I think you are lucky they only sold a product with bugs... Customer - depending on the actual use - may live around those bugs... I had several case they sold plans on paper... And then notified me that the feature should have been delivered yesterday... :wtf:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
This is so true and it happens all the time. God is an engineer, he made all good things - with bugs. The devil is in sales, requires money to get into the state park. And runs a gift shop outside the gate that sells bug spray at elevated margins. Bless sales, they have no brains but the gift of gab and get commission on sales and find it just fine to lie. They have a clear conscious because heck, they didn't make the thing. And in a matter of seconds could be selling something else somewhere else if this one doesn't fly. These people are both a dime a dozen but truly good ones are hard to acquire. Engineering knows absolutely it's a cobbled together POS. - For Pete's sake, don't let em talk to anyone, they'll bring us all down! And if this doesn't fly the poor old sod has to go sell himself to another company without the good looks and gift of bs trying to sell his skills to someone who might not be an engineer. :omg: So, yeah. :-D And look! It's another day.
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
Most of those clients don't realize there's a danger; the data they are seeing might be incorrect due to the bugs, but still they act on it. Would you step into an airplane with buggy software for its autopilot? Would you buy a ticket? :D Who's legally responsible for any damages that arise from the results? And what kind of software? Please don't answer something medical :suss:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
But ... a product - no matter how innovative and original - that is riddled with bugs gets remembered for the bugs, not the originality: when a competitor appears it's mentally compared against the buggy version, not the latest. Remember the Frontier: First Encounters[^] debacle? A "premium product" so riddled by bugs that PC Zone illustrated it's review with a turd tied up in a pretty bow: even making it shareware couldn't shift the bug-fixed version. It's a risk!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
Don't underestimate the importance of improvements! If customers see that every new release has a good handful of significant improvements, they tend to accept those bugs and deficiencies that are not yet fixed, assuming that they will be taken care of in the next release. Or the one after that. I have been working on products where we always had implemented and tested a few improvements that had been requested for some time, but we deliberately left them out of the current release - it had enough already. We had new release every few months, and those things we held back was to have an extra buffer just in case we ran into problems getting other functionality / fixes up for the next release - then we could throw in the reserve of improvements had on store. Customers found all our releases really worth the upgrade cost, even though there were still several unsolved problems. There is a classical study, it must have been in the early 1970s, of the IBM OS-360, analysing the development over time: Over 36 (or was it 37?) releases, the number of known issues formed a marked sawtooth pattern: rising for 4 to 5 relases, then a major cleanup was done, and then a new sawtooth built up for 4 to 4 releases... But even after those major cleanups, the number of known issues was around one thousand. (That was one of the observations of the study: How remarkably stable this figure was over 36 releases.) You soon learn to be pragmatic. Or, most of us do. Coming out from University, we believe that we can create perfect, error free software. No, we can't. We can just keep on handling one issue at a time, and thereby we all the time cause new issues.
-
This is so true and it happens all the time. God is an engineer, he made all good things - with bugs. The devil is in sales, requires money to get into the state park. And runs a gift shop outside the gate that sells bug spray at elevated margins. Bless sales, they have no brains but the gift of gab and get commission on sales and find it just fine to lie. They have a clear conscious because heck, they didn't make the thing. And in a matter of seconds could be selling something else somewhere else if this one doesn't fly. These people are both a dime a dozen but truly good ones are hard to acquire. Engineering knows absolutely it's a cobbled together POS. - For Pete's sake, don't let em talk to anyone, they'll bring us all down! And if this doesn't fly the poor old sod has to go sell himself to another company without the good looks and gift of bs trying to sell his skills to someone who might not be an engineer. :omg: So, yeah. :-D And look! It's another day.
-
Don't underestimate the importance of improvements! If customers see that every new release has a good handful of significant improvements, they tend to accept those bugs and deficiencies that are not yet fixed, assuming that they will be taken care of in the next release. Or the one after that. I have been working on products where we always had implemented and tested a few improvements that had been requested for some time, but we deliberately left them out of the current release - it had enough already. We had new release every few months, and those things we held back was to have an extra buffer just in case we ran into problems getting other functionality / fixes up for the next release - then we could throw in the reserve of improvements had on store. Customers found all our releases really worth the upgrade cost, even though there were still several unsolved problems. There is a classical study, it must have been in the early 1970s, of the IBM OS-360, analysing the development over time: Over 36 (or was it 37?) releases, the number of known issues formed a marked sawtooth pattern: rising for 4 to 5 relases, then a major cleanup was done, and then a new sawtooth built up for 4 to 4 releases... But even after those major cleanups, the number of known issues was around one thousand. (That was one of the observations of the study: How remarkably stable this figure was over 36 releases.) You soon learn to be pragmatic. Or, most of us do. Coming out from University, we believe that we can create perfect, error free software. No, we can't. We can just keep on handling one issue at a time, and thereby we all the time cause new issues.
That seems shady to me at first blush, but it makes perfect sense, and if it leaves the customers happier than they would otherwise be who am I to argue? :)
Real programmers use butterflies
-
I think you are lucky they only sold a product with bugs... Customer - depending on the actual use - may live around those bugs... I had several case they sold plans on paper... And then notified me that the feature should have been delivered yesterday... :wtf:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
On a Friday once, I was sitting in a meeting between my boss and a client. "Oh, yes. We support that device." "Oh, we didn't see it in the list." "Well, you have an older demo version that doesn't show it. We'll send you the updated one on Monday if you like." "Yes, please" Guess what I and the hardware driver guy were doing that weekend!
- I would love to change the world, but they won’t give me the source code.
-
On a Friday once, I was sitting in a meeting between my boss and a client. "Oh, yes. We support that device." "Oh, we didn't see it in the list." "Well, you have an older demo version that doesn't show it. We'll send you the updated one on Monday if you like." "Yes, please" Guess what I and the hardware driver guy were doing that weekend!
- I would love to change the world, but they won’t give me the source code.
Burying the boss? :laugh:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Burying the boss? :laugh:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
In the 1980s I worked for a company that built robots and they used Gates & Ballmer's BASIC to run the thing. One guy had printed the whole thing out and it was a stack of fan-folded paper over a foot high. We were finding bugs fairly often, most of which were introduced by us. It was actually fairly handy to have an embedded BASIC interpreter available. Performance could have been better but you really can't/couldn't expect much out of an 8086+8087.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
just sit back relax and let the customer do all the bug testing... just be ready with the shovel when the shit hits the fan !
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
Don't underestimate the importance of improvements! If customers see that every new release has a good handful of significant improvements, they tend to accept those bugs and deficiencies that are not yet fixed, assuming that they will be taken care of in the next release. Or the one after that. I have been working on products where we always had implemented and tested a few improvements that had been requested for some time, but we deliberately left them out of the current release - it had enough already. We had new release every few months, and those things we held back was to have an extra buffer just in case we ran into problems getting other functionality / fixes up for the next release - then we could throw in the reserve of improvements had on store. Customers found all our releases really worth the upgrade cost, even though there were still several unsolved problems. There is a classical study, it must have been in the early 1970s, of the IBM OS-360, analysing the development over time: Over 36 (or was it 37?) releases, the number of known issues formed a marked sawtooth pattern: rising for 4 to 5 relases, then a major cleanup was done, and then a new sawtooth built up for 4 to 4 releases... But even after those major cleanups, the number of known issues was around one thousand. (That was one of the observations of the study: How remarkably stable this figure was over 36 releases.) You soon learn to be pragmatic. Or, most of us do. Coming out from University, we believe that we can create perfect, error free software. No, we can't. We can just keep on handling one issue at a time, and thereby we all the time cause new issues.
Member 7989122 wrote:
If customers see that every new release has a good handful of significant improvements, they tend to accept those bugs and deficiencies that are not yet fixed, assuming that they will be taken care of in the next release. Or the one after that.
Then... what the heck are we still doing with Windows? :rolleyes: :rolleyes: ;P ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
We developed a product. It was really done in a bad way, by patching up resources from different teams. I did not like it at all. When I use it myself, I could see at least a dozen glaring issues. Just because we couldn't allocate resources into bug fixes, even the basic bugs were left alive. I had quoted an estimate of 2 weeks to give a final build (If someone's allocated for the bug fix) BUT The sales team tried the product in it's current state. Went straight to demo with the customer. Now they've sold it. Customers are signed up. They are using it, with all the bugs showing up randomly. And even the customer says they are happy And waiting for the next build. Strange. Totally different ideas. Now we are allocating resources to fix the bugs and make it good one. I'm known for perfecting till the last bolt is tightened. I guess I'm a bad seller. It's really a tough thought to sell a product with known bugs. I'm just imagining how brave & courageous Bill Gates & Ballmer should have been. :rolleyes:
-
Member 7989122 wrote:
If customers see that every new release has a good handful of significant improvements, they tend to accept those bugs and deficiencies that are not yet fixed, assuming that they will be taken care of in the next release. Or the one after that.
Then... what the heck are we still doing with Windows? :rolleyes: :rolleyes: ;P ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Windows gaining the required features, improving on the most used ones. Snarky question: Did you turn off feature usage reporting yelling "Don't you dare spying on me, Mickey$oft!!!" ?
