|
You can make it "as bug-free as humanly possible", while still making it easy to debug/fix.
Who the f*ck came up with this poll?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Any code "as bug free as humanly possible" will have bugs or create bugs when other featuers are added or changed.
Therefore code that is well designed, linear, understandable and easy to fix trumps a fine tuned messy pieces of code in the long run.
Besides, good code makes it easier to spot bugs before release so by achieving the second option you get much of the first one.
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
|
|
|
|
|
So, I was introduced to the idea of MVP or Minimum Viable Product... I hated it with a passion at first, but the client I was with had a long history of delivering precisely zero projects in the last x number of years. Now that I've been working under this model, I have a couple of observations:
1) MVP definitely means that you MUST revisit a released product. You have to circle back and make sure not only that it's working, but that it's meeting the initial expectations.
2) MVP is hard because you want it to be "perfect", but it never will be.
3) MVP provided better solutions to the user. The users (and subsequently BA's) don't always know how to articulate what they want, what they need, etc. Now, you can call out our PMs and BAs for failing you, but the best way on a small team that I've found is incremental MVP.
It's not for everyone. But it damn sure improved our quality of delivery. The users were happy - they saw us trying to solve the problems, and could see their feedback alter the course of the project. Management was happy - we were finally delivering SOMEthing. The developers were [mostly] happy - we were finally getting some kind of feedback that was meaningful.
Again, not every environment will benefit from this. But taking the time to put spinny-hubcaps on a program that doesn't do what the user NEEDS will generate a lot of ill will...
|
|
|
|
|
Both. With any decent seasoned developer those two options are really are one. Unless we are taking over existing project developed by an amateur developer then we should try to meet option one as much as possible. Option 2 is fire fighter route.
|
|
|
|
|
In my opinion, there should be as few bugs as possible. It saves support time, customers time, and leads to much happier customers. Also, buggy software hurts a company's reputation.
Clean, well-structured, code is also important.
|
|
|
|
|
Do like Microsoft and many others, release then let your customers Beta test (or even Alpha)
|
|
|
|
|
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.
___ ___ ___
|__ |_| |\ | | |_| \ /
__| | | | \| |__| | | /
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
