What really is 'good enough' for a late project?

Question

It seems like management always is saying how the project is late, then we have to figure out what is good enough to go live fast. The problem I find is that we tend to focus on the features that the client wants more than some basic features that I would think a web app should just have by it's very nature.

For example we spent more time talking about whether adding a noscript tag to inform users the site requires javascript should be added to the list of feature requests than the time it would have taken me to add it to the master page and then push it out.

Is there some good method for determining what things should be there to be good enough? How do I know what things my app should be expected to do at bare minimum?

We don't even add data validation sometimes because there is no time. It seems like there should be some basic bread and butter things in an app but so often all we care about is the things the user actually sees.

This is not the ideal way to make software in my opinion, but how can you know what good enough is?

Answer 1

Everyone has their own standards of good enough; on one level, "good enough" is "whatever you can convince people to pay you for."

However, if you want to enjoy your work, I suggest that "good enough" should be "something you are proud of making."

Answer 2

Customers drive features. They don't so much drive architectures, engineering, and such. Frankly your users could care less if you are using Html 3.0 strict or CSS 3.1 or XHTML. They just want it to work. I have found that you need a team to care about all the hidden stuff in order for it to be done correctly. The bottom line is that most apps ship with "good enough" code because make sure you have clean code and refactored code isn't what brings in the money.

Of course, most of us know that this stuff is important. Well designed database with good indexes are important to performance. Well designed code with classes that are "SOLID" lead to easy to maintain and extend application which means new features will be more stable.

So, customers drive features but the team drives quality. Make sure you put time into your estimates to ensure you are doing proper testing, getting good coverage, doing perf testing, etc. That has to be engrained into your team from the start. Code reviews and learning lunches help drive this type of motivation. If devs want to spend time writting new code rather than troubleshooting and debuging this stuff should be important to them. Even if it isn't visible or important to the customer. And good management understand this stuff.