This raises some good points -- I'm sure it must drive business owners around the bend the way software's so imaginary, yet plays such a vital part of the success or failure of some businesses.
For me, quality, as it applies to software, is a measure of how little trouble the software's going to cause, where trouble is defined of some combination of time and money to fix.
Quality is important because as the quality of the code decreases, the time and money required to improve it, or even keep it up date, increases -- this is technical debt. And in addition to time and money, there is also the opportunity cost -- if a customer wants a feature in 30 days, but that can't be done with the existing staffing levels because they're too busy bailing water, the company loses out on the opportunity to make another sale.
The title of this section is the key quote that I remember from The Art of Quality. Building a quality software system is a mindset, an approach to the craftmanship of writing lines of stuff and getting them to successfully run a business.
A quick and dirty solution is something that needs to be revisited as soon as possible. If not, it quickly becomes permanent, just One More Quirk in the established complexity that we drag around.
Writing code needs to start with quality in mind -- for me, this includes Test Driven Development, so that the developer can prove that the code really does what it is supposed to do.
In reply to Re: The dangers of perfection, and why you should stick with good enough
by talexb
in thread The dangers of perfection, and why you should stick with good enough
by redhotpenguin
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |