|
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.
|
|
|
|
|
One thing I've learned over the years between saying "yes" and "no" depends on the experience of the developer team. Most professional developers don't afraid to say "no".
|
|
|
|
|
Dave Clemmer wrote: No substitute for getting it done right
The substitute is called ignorance.
|
|
|
|
|
We deploy small, functional pieces in the fastest amount of time. Our sprints are 2 weeks long, which is very aggressive.
However, I think deploying crap, quickly or slowly, is still deploying crap; the end user experience is, well, crap.
modified 16-Feb-15 12:44pm.
|
|
|
|
|
Slacker007 wrote: We deploy small, functional pieces in the fastest amount of time.
Are you speaking of "deploy" in the sense of send-to and start-using-in the development team, and with beta-testers, or, are you speaking of (I hope not) deploy to end-users/customers in-the-field ?
What is true is that the movement of apps to-the-cloud (as in Adobe PhotoShop, for example) can enable frequent feature installs and upgrades and fixes, given the right app architecture. But, for many legacy systems the day of being in-the-cloud and frequent-whatever are a long way off.
In any case, I believe there's no one-size-fits-all for every development scenario.
I admit to being very skeptical about Agile's claims (I view it as yet another manifestation of a typical better-software-development cult).
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
We design, and implement only what we can get done in 2 weeks and deploy to DEV within that 2 weeks, usually toward the end, it depends. Then it spends the next sprint cycle, in DEV/STG for testing. If it passes muster, we will deploy to prod within 15-20 days from start of development.
It is my opinion  , that most developers (not all) have no clue about Agile, and they fear the unknown - so they are full of excuses why Agile is not correct for them or their way of life. I find this funny, because I used to be like that, too.
Agile, like anything is what you make of it. It is not an answer to all the riddles of life, but rather an answer to a few, for sure.
I will sing the praises of Agile, until another mistress comes along.
-- Steve
|
|
|
|
|
Regardless of whether or not you are following an Agile process, if your team doesn't know ahead of time whether or not you are marching steadily towards a successful release and are not communicating and dealing with blocking factors and issues, there is something wrong with the process!
If you know and can communicate that you are on a path towards a major slip, you can plan to make adjustments to the features and/or team as needed.
|
|
|
|
|
1st option is useless & danger sometimes
|
|
|
|
|
I have different preferences than those of the company I work for.
There is a bit of compromise that happens from both ends. I would always want to hand in my best work, where as the company would always want to meet its deadlines. Sometimes I have to compromise on the quality of work that I deliver and sometimes the company has to compromise on the time that the project gets delivered. But at the end of the day, my preference doesn't mean much... at the end of the day it's about getting the job done on time, whatever it takes. The grey area being, 'done' of course.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
R. Erasmus wrote: I have different preferences than those of the company I work for.
But the premise was Quote: It's your project and you're calling the shots.
Kevin
|
|
|
|
|
Missed that part... srry, but I won't change much I said. I'd still compromise as I'd probably have a customer I'm doing the project for who would also give deadlines (probably unreasonable). If it was the companies project, the main reason for them having different preferences than me would be because they want to please the customer. Which produces the same end result.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
that mean I prefer killing features, but not releasing nasty code. I see a big difference between the code isnt work at all or it is crashing or is making problems.
If such a situation is in reach I bargain with the managment to reach some compromise.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
It may sound silly, but software like construction never ends with the phrase "on time". There is always something that needs to be done. Instead of saying the software will be ready on x date, we should focus on a delivery range. I worked for a company that did this. Once a release was done, the boss would meet and talk about our goals for the next release. We would outline features and discuss a target. Then our release would be something like May 2015. That gave us a range of time to deliver in. Similar to agile, we would complete features and then start more. When May approached, we would finish up what we were working on and start testing. We always tried to deliver early, but had a buffer.
Using this method, we were not late and people knew what to expect. Everywhere I have worked that had a hard date missed.
Hogan
|
|
|
|
|
If I remember correctly, both Mozilla and Blizzard have a "it's ready when it's ready" philosophy when it come to releasing new versions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
