|
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
