|
Hi Karsten, U are absolutely right. But the question is not specific to Apps. It may include traditional windows based software, web forms apllication, MVC website, Windows services, Web services or WCF Serices.
Happy Coding...
|
|
|
|
|
Please don't let managers see this poll. It will only confirm to them that there are (at least) three options.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Too late
|
|
|
|
|
I don't wait for all the features I might ideally need to get feedback!
But I don't release (known) bug!
+ it kind of depends if it's internal or external project.
For internal project can release every week!
For external, you can release beta or intermediate state product as long as:
1. it's non buggy
2. feature are appealing enough...
|
|
|
|
|
In moderen apps (like for iOS or Android) you have some update features, so you can rapidly release. The problem is the test and review phase.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
...I wouldn't have a job.
A developer's subjective conclusion of what is "right" will always differ to that of the customer's subjective conclusion of what is "right," try as each might to "nail it (all the features *just the way the customer wants*) on the head".
Oh, sure, I ship a tight product with negligible defects to the extent everyone agrees the product is "just right".
But, gecause customer needs and wants change, while it is just 'right' at the onset of the project, once implemented, there are always changes.
Hence, I remain employed.
|
|
|
|
|
I used to work for a software publishing firm and we did not ship until the product was bug free. We did not delude ourselves in thinking the product was totally bug free, but it was shipped with no known bugs.
We put serial numbers on the (at the time) diskettes and when a customer called with a compliant, customer service would get their serial number and look in the defect database to see if it had been fixed in a later release. (Quality in the works, we'd still be working at it) And if found, would send them a new copy. If not, the problem would be referred to the programmers and when fixed, the serial number would be noted that started shipment of the improved product.
Contrast that, with another company I worked for that released to deadline regardless of the number of known bugs. The last product had been shipped with over 150 known bugs and we were given a list of new features to be added to the next release and the deadline. I asked management if we were going to fix any of the known bugs and I was told, only if they interfered with the installation of the new features. In other words, no.
The CEO when off to a user conference with the intent of describing all the new wondrous features that were going to be added to the next release.
I get the feeling that they met him at the door with a baseball bat and made it clear that if the product didn't work, they didn't care how many features it had.
Development was halted and an all out bug fixing project was put in its place. I won't go into the horrors that followed because a non-technical committee was in charge of deciding what bugs and the priority they had in being fixed. (It's a saga)
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
If you release on time but with buggy code, the next project won't get assign to you. There are always excuses for running late, but no excuses for being error.
|
|
|
|
|
.. they also don't pay if you never ship.
So.. everybody ships code that mostly works but still has some bugs. The only question here is what's your tolerance for bugs in the code you ship.
The happy case for core functionality absolutely must work, or there's no point shipping. For the rest, its a judgment call on whether they are serious enough to delay shipping for. Lots of factors go into that judgment.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I think (hope) that everyone always wants to do their best from the beginning.
The problem however is that businesses at times will have to make a release even if it means the software may have bugs in it. The reason being is that the release is timed to market capitalization and as you slip on dates you lose customers, aka $$$.
|
|
|
|
|
Although I stopped calling it Kirk's Law...
You cannot simultaneously choose the size/scale of the building AND it's completion date in a vacuum.
Yet management does this with software all of the time!
Build the Empire State Building. Twice as tall. By Noon tomorrow. (Okay, 3pm, but you're pushing it).
The reality is:
- Quality is a requirement
- Resources/Features are the variable
- Time is the result, and that has to be Clearly within REASON!
|
|
|
|
|
|
... just needs to be "good enough".
|
|
|
|
|
That beside the point. What if you can't get it to be "good enough" within the given time?
|
|
|
|
|
Then I prefer not to ship it until it is "good enough", as a compromise between shipping on time or waiting until it is my best possible work. As an aid to that, I always try to set expectations early and often.
|
|
|
|
|
Naturally you wanna perform the best and publish code that is 100%, but we're not in candyland.
The reality is more like a mix of all the choices and most likely code will be released that is more 85%, plus a ton of bugs and glitches. Then patches, patches and more patches.
Everything else, is wishful thinking.
|
|
|
|
|
It depends on the application.
I hope the guys writing software for flight control or nuclear power systems have a slightly lower tolerance for errors in shipping code.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
An internal web app can iterate much faster and deploy incremental changes as they're written.
On the other end of the spectrum, a desktop app delivered to a customer with a very bureaucratic IT process needs to have everything done and working when it's delivered because the turnaround for an update on their end is months to a year.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Agree.
I'm working on medical equipment software, which won't pass regulatory approval if any bugs left unfixed.
My second job is automatic warehouse management systems, which supposed to be running 24/7 for years, ones they commenced. Leaving a bug in such a system might cost you millions.
From other hand, leaving a non-critical bug in a generic web-site to fix it later might be a good idea.
|
|
|
|
|
The projects I work on are constantly changing, so releasing a few updates that need a couple of bugs fixing live is not really an issue which is a good thing as the boss likes to tell PR companies and partners release dates that are fixed in stone...
|
|
|
|
|
Unfortunately, at my current position I am not very busy, but the benefits of that is I can make sure the product that goes out the door is nearly bug free. When I develop test plans and implement various black and white box tests, and stick to them, my releases go pretty smooth.
My previous employer's only request was "get it done!" I heard that once a week. The problem with that way of doing business is you end up with a technical deficit(What is Technical Debt?[^]). I used to spend 75% of my week fixing and supporting legacy applications, leaving me little time for new development. The new development was rushed, so that became junky too. It is approximately 20 times more costly to fix a defect when in production than compared to during the design phase. The effect of this is you can never catchup; thus, you have technical debt.
|
|
|
|
|
And sometimes software get rewritten because building new one with new functionalities costs less than duct-taping the existing one. I always believe in do it right, do it once and don't leave headache for others.
|
|
|
|
|
No matter how critical the employer/client thinks something new should go out, the end customers can always wait for something new. End customers experiencing something wrong are lost customers.
|
|
|
|
|
Dave Clemmer wrote: End customers experiencing something wrong are lost customers.
Very true.
|
|
|
|
|
It's easy to say "yes" to an employer or client that wants something delivered in a certain time frame. It's hard to say "no". I've had clients be pretty mad at our team for telling them "no" about delivering things too early. Almost always, we end up building the clients' trust in that we are focused on the success of their businesses.
|
|
|
|