|
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 |
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
