|
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
|
|
|
|
|
yes, it's my choice. Couldn't select anything from poll
|
|
|
|
|
I agree get what you can out the door, even if all the features are not there but be sure what you do release is solid.
You only have one time to make a first impression!
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
OriginalGriff wrote: ... to be as close as possible to the release date, but don't release known bugs.
Yes, I think that's the best answer, otherwise your customer may abandon you.
Kevin
|
|
|
|
|
Someone has to say it, reduce functionality in consultation with the client but NEVER release a known bug.
In corporate, I find deadlines are artificial, placed by a manager on what they think is possible
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Depending on situation and client, of course, but overall I like to release as soon as I've got something working (and working good).
At my previous job this worked pretty well. The customer saw progress and could test (and sometimes use) their software even before the deadline. It also meant they could give feedback so the software would be even better suited to their needs when the final version was released. And the best part is that when you miss a deadline no one really notices because they've got working software already (and you can always say you missed it because you changed feature X or Y and added feature Z after they tested something).
Wait, isn't that called Agile? 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Time is the Money, if you deliver your product On time it will surely make customer happy, If you give tons of functionalities but slips date, then it will not put so much impression on client as you are already too late to give software.
First impression is always be the last impression, Try to cover main functionalities and release it on time with too much work on UI, you can update it anytime
I think "Better three hours too soon than a minute too late."
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Releasing on time might seem good at first, but if you continually release buggy systems on time your customers will eventually lose faith in you. They will also stop paying you for support since "nothing" you release works.
My plan is to live forever ... so far so good
|
|
|
|
|
The same will also happen if you keep releasing late.
At the end it's all about managing expectations.
In my opinion, you have to respect the release date but you should have processes in place that allow you to know way in advance that by that date you won't be able to deliver everything you promised.
At that point, start speaking with the customer and figure out a solution.
It can even be postponing the release date if the client prefers, but it's usually much better to keep the date but leave some features out for the next release.
If the client know this in advance and is involved in this decision they feel in control and most of all they will be able to explain their superiors what's going on.
|
|
|
|
|
The same will also happen if you keep missing the release late.
At the end it's all about managing expectations.
In my opinion, you have to respect the release date but you should have processes in place that allow you to know way in advance that by that date you won't be able to deliver everything you promised.
At that point, start speaking with the customer and figure out a solution.
It can even be postponing the release date if the client prefers, but it's usually much better to keep the date but leave some features out for the next release.
If the client know this in advance and is involved in this decision they feel in control and most of all they will be able to explain their superiors what's going on.
|
|
|
|
|
Your view has helped me out.
My employer know avoid contracting out - they've had a couple of on-time junk delivered (yes, from India) and now realize that those of us with a personal stake in the company will do our best to get it done as soon as possible . . . and importantly . . . no sooner.
When it comes down to a choice of reputations, the long term view is heavily weighted toward quality (vs. the havoc that we and others have endured).
I keep my job/reputation by getting it done right the first time (almost) always - sometimes ridiculously fast. That, of course, is because I invested (and was trusted to so invest) my time to do it right the first time and anticipate a future modification or enhancement.
Shoving out the door in a hurry generally is the slowest way to get things done.
| "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 |
|
|
|
|
|
I disagree 100% with the claim that "On time it will surely make customer happy." The customer will definitely not be happy unless you deliver on time, complete, and bug-free (and maybe not even then, but that's a different discussion). The problem is that software engineering, by definition, is something whose duration cannot be accurately predicted. It takes what it takes. So if you promise to deliver on a particular date, you MUST be prepared to accept bugs and/or missing features if necessary (and it almost always is), and have a plan for dealing with those after delivery.
As an engineer, I would always prefer to do the job right the first time and release nothing until I'm satisfied it's done. In the real world, of course, that's not always possible because those who control the purse strings have a limit to how much they're willing to spend to get the job done. But any manager, sales droid, or customer who expects to be able to specify a hard date for completion of a software project is, IMHBAO, an idiot.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
