|
Unless option 1 implies code that is hard to debug (spaghetti code!  ) then these aren't even truly opposites. Option 1 doesn't exclude an implied option 2 
|
|
|
|
|
In a perfect world we should strive for bug free code, however, in the absence of a perfect world we should at least expect code to have code that easy to maintain.
|
|
|
|
|
In both the options we end up writing an app that is in debug-mode and is fixed and published —
In my opinion, it all depends. Sometimes a defensive approach to programming can be deemed helpful, I really would appreciate a program to tell me straight away, "I am not playing fair", than to say, "Program not responding." Oh and I want the updates pretty timely, than 2 months late when I no longer am interested in the app itself.
And there is no bug-free code, there are always bugs in the app. I have had experiences where there were bugs enough in the code base that they ended up being features for our app  No kidding, we were once building a minimal chat based app, where we required a group ID and the ID of the person adding (which was expected to be the Admin only), but later discovered that this bug can be a feature and now anyone can add members to the group. Funny and unsecure, yes, but was a great shot.
So in the nutshell, coding depends. You cannot tell what to do, but defensive approach can really help you out.
As they say, embrace failure.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
What kind of software we are talking about here?
Something that runs medical devices or nuclear plants? Make sure it's bug free. Even more than humanly possible.
Social networks? The buggier, the better...
|
|
|
|
|
I was thinking the same, it all depends on the circumstances. I for example try to go as bug-free as possible, not because I create medical applications but because my customers are professionals, not consumers who tend to give less of a damn about stupid bugs but when your customer's hour costs somewhere around 200€, then you better give him tools he can actually work with.
|
|
|
|
|
Kirill Illenseer wrote: when your customer's hour costs somewhere around 200€, then you better give him tools he can actually work with.
specially if he is going to bill you the hours he can't work due to your buggy software
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.
|
|
|
|
|
Hasn't happened to me yet, but a customer who's going to leave you for good for horrible service is worse, than a customer whom you pay a reimbursement but then can keep billing. Granted, I don't know if that happend as well as my product manager keeps customer relationships, I'm "just" the techie behind the scenes. Yet, said PM dropped "That customer's important, we better take care of their particular situation NOW or we're in trouble" every now and then.
|
|
|
|
|
Kirill Illenseer wrote: Hasn't happened to me yet,
I have almost been there, my customer had to pay the final customer 10k/day until he finished the project due to mechanical issues. Software was not involved, so I was safe, but still not a nice situation.
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.
|
|
|
|
|
What industry sector was that, out of curiosity?
|
|
|
|
|
Automation
Clause "delay fine" required by final customer to be included in the buy contract of a production machine and totally underestimated by my customer. Machine delivered some days after deadline but/and not working as required in the specifications for some weeks.
Project ended in big red numbers.
Luckily... not for me
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.
|
|
|
|
|
Happened to me recently in my private life. Ordered a kitchen, the company delivered half and doesn't want to tell me when I can expect the rest of the kitchen. The contract doesn't include any late fees, but whne selling to private customers, there's law that implicitly adds the obligations to deliver in-time. Called my insurance. We'll see how that plays out.
|
|
|
|
|
I've done my share of software for medical devices and we spent a hell of a lot of time debugging, testing and often rewriting code before any release. Injuring a patient is a sure fire way of getting the FDA on your tail.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
This question is comparing architectural patterns to actual code implementation. Apples and oranges.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Yes, the comparison is lopsided, but in my experience I found exactly those two kinds of programmers. The ones that focus on building a good architecture and those who create messy code "but it works so it must be good, why should I care about the architecture?".
The second kind drives me mad because sooner or later I have to expand or maintain their garbage, which is of course completely not integrated with all the rest of the code - even theirs sicne they develop as inspirations strikes them.
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
|
|
|
|
|
I think you pretty much just defined the difference between a Jr. and Sr. dev.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Except that in my experience the Sr. developers are the ones you imply to be Jr... and they're 20 years senior to me.
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 you're arguing that experience is a negative factor in terms of code quality and architecture, I think you'd best present something more concrete. To be fair, though, the idea of a study of code quality vs demographics is interesting, but would be intensely difficult to approach objectively.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: If you're arguing that experience is a negative factor in terms of code quality and architecture,
Nope, just explaining that seniority doesn't mean necessarily better judgement and ranting that in my case I have to cope with their messy works.
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
|
|
|
|
|
- Ensure the code well structured, modular, extensible but hard to debug and fix.
- Ensure the code written as simple as it could and easy to debug and fix.
___ ___ ___
|__ |_| |\ | | |_| \ /
__| | | | \| |__| | | /
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
