|
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
