|
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.
|
|
|
|
|
You beat me to it!
Worked for a large company that had a release named 9/9. It was due on September 9. They had over 100 consultants in a room testing the release (not including the ones coding it) and still had to remove functionality to meet the hard and fast deadline. The code was pulled a few days after the release cause of a "small" bug. Turns out that the system billed the customer every time a search failed, but kept searching all retail and warehouse locations. Ended up putting over 100,000 USD on somebody's AMEX card looking for inventory that it couldn't find!
Hogan
|
|
|
|
|
He's know for "It ain't over 'till it's over".
If it's buggy it's not done. You may as well release it the day the assignment is given with just a popup that says "Not Ready" - but hey - you've met the deadline.
So, it ain't done until it's respectably stable and won't create any problems.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
First of all, if you wait for the application to be perfect you'll never release it.
On the other hand, I believe that it's important to respect release dates, otherwise why have them in the first place?
It's here that project management gets into the picture.
Classifying which are the core functionalities of the release and making sure those are rock solid.
Finish those and as much as you can of those that have a low complexity but have a big impact, and... Release!
Another good practice is to release often (Every 2 weeks?).
Releasing often enforces a lot of good practices. Especially it enforces the usage of a Continuous Integration system, otherwise it's just mad work.
If you automate your release process through all the environments (Dev, Staging, Pre-Prod, Prod...). You really don't need all these environments but I strongly encourage to have at least one environment between Dev and Prod.
Relese even more often to this intermediate environment so that others can test what's being developed and devs can have a faster feedback. Faster feedback means less wasted time and better final result.
Complying with these processes you'll see that you'll be able to know way in advance if you're going to miss the release date of not (it's only in 2 weeks anyway) so you can start adapting and rearranging things so that you keep the date but skip a couple of foreseen functionalities.
|
|
|
|
|
Duplicate your own post, back-to-back: Excellent example of getting it out the door quickly!
(And not cleaning up, afterwards).
Thumb's Up!
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
