|
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 |
|
|
|
|
|
But this wasn't my mess... 
Someone messed up the posting mechanism in CP
Anyway, releasing twice with good quality isn't the same as releasing a bad version!!!! 
|
|
|
|
|
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.
|
|
|
|
|
Of course you're right - and then you can spend all the time available now that you've released "on time" cleaning up the mess made by the defective-but-on-tim version.
Simply put a disclaimer on all of your opening screens: use at your own risk!
Totally Brilliant!
| "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 |
|
|
|
|
|
That's one of the biggest flaws of software development professionals.
Thankfully not all professions follow this line of thinking.
Of course there are unpredictable things, and I'm not the master of delivering the full scope always on time, but saying that delivering on-time equals delivering a "defective-but-on-time version" puts a lot in question the professionalism of the team and specially of whoever manage it.
- If to deliver on-time we need to de-scope things from the release, do it.
- If you reach the release date and you don't have the core functionalities done then someone messed up with the estimates. If you have your metrics in place, the alarms should have been triggered already way before the release date.
- If only by the release date you know (or you tell the client) that you won't be able to deliver on-time, then this is enough for a serious client to never pick you again or worse, you start paying penalty fees.
Bottom line:
- Improve your processes in order to mitigate the risks.
- Deliver often.
- Keep the client up-to-date with the current status of the project (without lying) and involve him when decisions have to be made.
|
|
|
|
|
Your bottom line is missing a few components (but they're implied).
"User be damned"
As for:
AlexCode wrote: If only by the release date you know (or you tell the client) that you won't be able to deliver on-time, then this is enough for a serious client to never pick you again or worse, you start paying penalty fees.
And how about the client's attitude when he receives defective goods: with your name on it? I'm sure that will encourage them to seek more of your quality workmanship the next time they want to reduce the profitability of their enterprise.
Where I code they learned a bitter lesson: if you don't care if it works, outsourcse it. It'll be on the desktops in no time at all, and you'll have saved time and money which can be better spent on putting out the fires, fixing the damage, and reentering data.
| "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 |
|
|
|
|
|
You're putting it in a too catastrophic way 
If you reach the release date and the status is a catastrophe, then you won't solve it by postponing the release, you have to cancel it all together ans schedule a new one (which is different than not respecting the release date).
Cancelling a release is a serious thing and needs to be assessed so that it won't happen again.
Ignoring the release date and release it a week after will shortly become a common practice and no one will ever care about the release date anymore (no one ever respected it anyway right?).
This is much more a process and discipline thing for the team than anything else.
Managing a big team in a loosely manner is half way to disaster (one-man-show or small teams too but not as destructive).
|
|
|
|
|
... to be as close as possible to the release date, but don't release known bugs.
Enough companies have released buggy code to meet the defined day (heck, MS release beta code and make people pay for it up to SP1) - and users hate it.
I remember the PCZone magazine review of "Frontier: First Encounters" review, where instead of screenshots two pages were covered by a picture of a turd wrapped in a yellow bow because the game had been released way before it was ready.
Buggy code can wreck the user impression of your product: they remember the problems, not the good bits.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Yes.. this is well said case.
Buggy code make the bad impression of the product. And believe that it may stay for long time and can questionable to even usage as well.
Better to deliver only those part that are bug free and user would be Happy to use. User can ask for more part later if found easy to use and proper functional part early.
Kind Regards,
Shivam Sharma
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
