|
2.
..and then refactor to decrease the codebase.
Having simple code is not enough, you need simple code and very little of it.
The knee-jerk reaction against this is typically: this won't work for every project.
In theory, sure, sounds plausible.
In practice, however, you can always get away with simple code and very little of it.
I believe the problem is people, and how we describe and approach a problem.
The problems are always content with simple solutions. They don't seem to care either way.
|
|
|
|
|
KBZX5000 wrote: In practice, however, you can always get away with simple code and very little of it.
My project involves quite a bit of complicated math, and I've become convinced that there's no way to write simple code for it. The real world that we're trying to model is way too complicated.
|
|
|
|
|
Doing the math yourself.
Either you work in complete isolation of the internet or you're being paid specifically to advance the field of mathematics.
If neither is the case, you should not write the math yourself, and use a maintained math library instead.
Problems in the implementation are much faster spotted when 1000+ people are using it, reducing costs for testing, maintenance is zero-cost / done for you, and it's peer reviewed for quality.
Math is like a drug. It might give you a temporary rush and feel gratifying, but you shouldn't be doing it on the work floor.
Just say no.
|
|
|
|
|
Actually, advancing a field of physics isn't too far away from the truth: the only other people doing this kind of applied physics is our competitors.
My company makes and sells vibration test equipment, and my part is working on the software that controls the shakers based off of the accelerometer data. Now while there's a lot of vibration research that's been done, it's not exactly a hot topic in academia. And it certainly hasn't been developed into software libraries. (Although have you ever looked at code written by a scientist? It works, but it's not optimized and is often rather messy). Thus we develop a lot of it ourselves, which is just as well because we often need to tweak it as we take into account other stuff such as electronic noise or unconsidered vibration cases.
Also, when you do one thing to the signal at one point, you need to account for it another point in the signal analysis. So if you aren't careful, the code devolves into a big mess very quickly. Which is difficult when you're trying to fix a customer's problem as quickly as possible so they can get on with their product testing.
|
|
|
|
|
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;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
