|
Deliver your proper code in proper time... 
|
|
|
|
|
I prefer to deliver proper code
|
|
|
|
|
to deliver proper code.
I was "adviced" to deliver in time.
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.
|
|
|
|
|
Surely that's the whole point of agile practices . Let features slip not quality ?
|
|
|
|
|
Multiple selection, with the number selected limited to 2.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
To me "completed properly" means that the release meets the agreed to quality standard, however high or low that standard is. You have or should have a process for effectively finding and dealing with issues. You have or should have a quality standard that is agreed to both by the employer/client AND the team. If a new version doesn't make the standard for the employer/client or the team, it doesn't go out the door.
When releases are sent out that are not completed properly, that says to me that either the quality standard is not defined, or not properly adhered to.
|
|
|
|
|
Where is the choice to strip out features?
I can get the core 90% of the project done on time and bug free - that is the critical part the business needs... it is all the outliers, pet projects, add on's, and scope creep issue items that need to be stripped out. Send that stuff out as a next release, if there is a justifiable ROI.
|
|
|
|
|
I admit that there are times when it's acceptable to release an application with a known bug if that bug is hard to reproduce and is an uncommon edge case. It may be the case that the cost of fixing these sorts of bugs delays the application to the point where it starts to hurt the business (angry customers, missing a payment milestone (where there may even be a penalty to pay) etc).
I doubt anyone here would ever seriously consider releasing a buggy application, but it's finding the optimum balance between releasing as close to the deadline as possible, and keeping everyone happy. And that is a lot harder than it sounds.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
It's been a long time since I got paid to develop software professionally, but in that time an application worked, or it didn't go out the door. Releasing software that didn't work wasn't done, until Microsoft made it standard practice. It's still entirely unacceptable and unprofessional, and outright fraud to charge customers for programs that don't work perfectly out of the box.
Will Rogers never met me.
|
|
|
|
|
One of my previous employers said that there are times when it makes more marketing sense to "shoot the engineer" and get the (possibly buggy) product out of the door than wait for a perfect product. It appears that most people are willing to forgive bugs in a product; they are less willing to forgive delays.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Option 2 (I prefer to release my best possible work, even if that means release dates slip) is best from Developer's point of view but he should be ready to answer the "whys" of project manager and the client. Because client always ask you why you given the date if you don't know by when you can deliver your best possible bug free solution.
Happy Coding...
|
|
|
|
|
But the managment has deadlines, often with reputation issues and contractual penalties. We are now sitting and coding for the annual Cebit and it wont wait til were done 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
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".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
