|
I think, no one produces bugs just-for-fun.
There is only ONE way to produce code, and we all go that way: Try to not make a defect program, but one, that works.
Bugs are a natural part of every software product.
The mindset "it compiles, so ship it" happens nowadays more often, but that's in many cases not the dev's fault. It's deadlines, it's "but we promised it to the customer", it's bad management and marketing.
Today, if you look at Steam or in any App store, even in professional standard software market, it all is full of "early access", "public beta", "preview version" things...
Today, software is shipped LONG BEFORE it is even CLOSE to being feature finished or tested.
Same as cars, where you have to happy if it runs for ten years (in the 70's and 80's cars had an expected lifetime of 20+ years!), it's with software. The lifecycle of one version is not measured in years, it's more months, sometimes even weeks.
9 out of 10 "releases" are only bugfixes from the previous versions. Everything is "patched" twice a month, ...
Yes, of course, the internet, the stores, the "online" world allows us to push fixes in short time to the customers... but honestly:
If you'd taken the time to do intense testing and FINISH your product version before you ship it, would be MUCH better for the customers!
I don't say "everything was better in the past", but when I only leave my PC off for a week, I need an hour or more before I can be productive due to 21 windows updates, 4 patches for each of my development environments, and then an office patch here and an update there...
Where are the times, where you could just START an application and you were ready to go? Every sh***tty app welcomes you with "oh hey! there's a new version available! Updating..." dialog.
So the real question here should be:
Why are we so forced into releasing bugggy software? How can we wake them up, that they are doing no good?
|
|
|
|
|
It's almost majestic that people will pay for the privilege of testing code. It's become so common on the game front, though, that almost anything other than a AAA title will almost invariably do that to maintain working capitol.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
A really well thought out post to a weak/confusing survey.
Mike Barthold wrote: Why are we so forced into releasing bugggy software?
IME, it's the lack of testing/dogfooding. It's definitely something I could do better at!
"Go forth into the source" - Neal Morse
|
|
|
|
|
2 words.
Profit. Margin.
Software development is costly and hard to sell. Got to keep the stakeholders happy somehow.
|
|
|
|
|
How do you ensure that code is easy to debug?
The only methods that came to my mind are using intermediate variables, asserts, and trace outputs.
Intermediate variables make the source code larger with the chance to introduce new errors. The other two are also falling into the category "ensuring that code is bug free as possible".
So there is no choice for me.
|
|
|
|
|
Jochen Arndt wrote:
Intermediate variables make the source code larger with the chance to introduce new errors.
I have to disagree with that. Something like:
integer slack_space = <cryptic expression>?3:4;
adds significant meaning and intent (compared to an anonymous inline version and assuming "slack_space" is well chosen), reduces the mental workload when the code is revisited, and certainly adds less chance of introducing errors than typing in the same expression twice or more.
In my experience, however, very few programmers actually code like that.
-- modified 26-Jun-18 14:10pm.
|
|
|
|
|
Member 10664505 wrote: integer slack_space = <cryptic expression>?3:4;
adds significant meaning and intent (compared to an anonymous inline version and assuming "slack_space" is well chosen), reduces the mental workload when the code is revisited, and certainly adds less chance of introducing errors than typing in the same expression twice or more. I concur completely, also it makes it easier to debug/update expressions and if the same expression might be used more than once it makes it faster too (and in certain scenarios performance are functionality).
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
If we can't make code easy to debug then how we can sure it is bug free.... LOL
|
|
|
|
|
You make your code "bug free as humanly possible" by making in it "easy to debug and fix", and "releasing" is seldom a developers decision but a managers one!
|
|
|
|
|
agree, also depends on target deployment i.e. how easy is to push the changes after fix.
|
|
|
|
|
Mehdi Gholam wrote: You make your code "bug free as humanly possible" by making in it "easy to debug and fix" Agreed.Mehdi Gholam wrote: "releasing" is seldom a developers decision but a managers one We have a (cue Pomp And Circumstance[^])CHANGE CONTROL BOARD who decides when we release software and what bug fixes are in each version.
Software Zen: delete this;
|
|
|
|