|
|
|
|
|
by beachy
236 days ago
|
|
I read a great article a while ago (can't remember where) when they tasked some embedded guys with building a somewhat complex front end app. When it was done, there were no bugs. Not a single issue. They asked the embedded guys how they had accomplished it. They said "we didn't know bugs were allowed". Many people have never authored or even been involved with a high quality piece of software, so they just don't know what it looks like, or why you'd want it. You'd think that someone in the exec team would have some personal pride and ownership in the code and would want to flush out bugs and improve quality. But nah. |
|
The requests to my team are:
build what product says
close out 90% of the defects you find by priority order
deliver in the priority of feature > security > accessibility
once delivered move on to something else we only have time to work for 3 months on an initiative before we move on
These requirements don't end up with a well working product. They end up with gaps in product, defects that are obvious, non-accessible site. Things take time to polish and be made right, but that's not what is requested. Wanting to iterate and measure isn't important because its not more features.