Quality in coding ...

Member 2479452

The advantages of high quality coding are unchallenged from a technical prospective. Now, what about the economical aspect ? Is it really worth paying the additional cost of quality, economically speaking, in terms of time namely ? I guess that to answer this question in an undisputed manner, the same project would need to have been conducted in the long run both at say 80% quality level, and at 100% quality level, and the cost of ownership of both implementations compared during a (say) 5 year period. These experimental conditions seem fairly unpractical though. Could you guys share your views with me on this point ? Or direct me to relevant studies on the subject ? Does high quality really pay back ? Thanks in advance for your contributions

Pete OHanlon

Poor quality may mean an early delivery, but it will also mean a complete nightmare in bug fixing and maintaining software. Bad practices and poor code are expensive to fix later on. Bottom line - do it right the first time, and cut down on the costs later on.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

My blog | My articles | MoXAML PowerToys

realJSOP

That pretty much qualifies as a stupid question.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Scott Dorman

You have to look at the cost it takes for fixing a bug during development before the product has shipped and after it has shipped. Typically, it is easier (meaning less time) to fix the bug during development where things are a bit more flexibile because there are no external dependencies (clients) that might have created workarounds to deal with the bug. The higher the code quality, the higher the overall application quality will be. Also, as a developers code quality increases their sense of ownership increases. As the sense of ownership increases so does the desire to continue writing quality code. Eventually you end up with a sort of self-fulfilling prophecy concept. Bottom line, it is always more cost effective for a bug to be found and fixed as early as possible in the product lifecycle.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

PIEBALDconsult

Yeah, what they said. Well, there's quality and then there's quality. Certainly the application should be bug-free, but that's only one type of quality. The application should also be well-engineered (perhaps even documented). This leads to: 0) Ease of finding the cause of a bug 1) Ease of fixing a bug 2) Ease of adding features after the application is released (without adding new bugs) An application with the first type of quality but not the second may be less desirable than an application with the second but not the first.

Member 2479452

Agreed. Its's definitely the second type of quality I am referring to. And even the "third" one, that you are hinting, that would bring along beauty in design, and elegance in implementation. The first kind of quality you are defining, ie bug-free coding, may even not be quality at all, but simply what a plumber gives when he leaves the premises having left no leaks in the pipes. Especially since good sense teaches that coming back to fix the holes is at your own cost, as a plumber as well as a developper. Now the question is : Provided the client would agree to pay this desirable application as you name it, would he get the best deal so doing ? Would not he be paying too much ? Should we both (client and developper) agree to stop at the quick and dirty AND bug-free stage ? In your words, is the desirable aspect of the application something the client ought to pay for ?

PIEBALDconsult

You get what you pay for. A full-time employer should get the works. (Unless they specify otherwise.) Someone looking for quick and cheap on RentACoder probably only needs the first type. If they later need more features they can have it completely redone by a different developer.

Member 2479452

Fair enough. I am sure your response will qualify in any smart response competition.

Lost User

It's _extremely _hard to measure the quality of the code. Even quantity is hard to measure, since you can't just count lines. Some lines are from templates, others are generated, lots is handcoded and some is hacked. My grandfather used to put the maximum effort in planting his veggies in the yard. It didn't matter if the seeds looked as if they were of less quality then previous years. He knew that he had to maximize the effort in order to get the maximum result. Now, you can sell software that's not complete, or not fully functioning. Creepier, that's whats most people do. Hospitals are a lot more carefull, they want a guarantee that everything does work a 100%. If you write the drugs-distribution module for a program, then strive for perfection. You don't want to save $50 here whilst killing an old woman somewhere else, just because of a bad counter in the list. The economical aspect of a hospital that's rounding up it's lawyers should not be dismissed easily. As to your experiment; it wouldn't be representative, as there are too much other variables in play.

I are troll :)__

KungFuCoder

I think it's more to do with client education and management sanity Did a project last year that realistically was around 4 weeks but was budgetted at 2 weeks becouse otherwise the client would have said its too expensive and they wouldn't get the job. Not suprisingly it all went horribly wrong and way over the 2 week budget largely due to inadequate testing resulting in a p*ssed off client and a finanicial mess due to the lack of budget. (Ironically I later found a postmortem document from the first wave of the project detailing exactly the same problems I hit and how the management would avoid them in future - mutter,mutter,grumble) Essentially their opinion was that quality was only acceptable if it gave a budget figure matching the clients expectations. Whereas I can see the need to have a cost the client wil accept, if you have to remove all testing and quality to acheive it then it's guaranteed to backfire on you and lose any chance of repeat business from that client. The majority of the projects were run this way, maybe not quite as bad but generally borderline between acceptable and untested/unplanned. They've since made 20% of the staff redundant (me included) and have some on a 4 day week. Personally I don't think they'll make it through the next couple of years. My current employer would rather argue that testing/ quality is something that it's in the clients best interests to pay a bit more for and is looking at recruiting extra staff. That's the choice really. Low quality = cheap quote that goes wrong and annoys the client. Higher quality = more expensive quote but with a decent chance of delivering what you promised and getting the client to consider you for their next project as well. If the client can't actually afford to pay for what they want then they need to be persuaded to either reduce their requirements or find someone cheap and accept that they will have problems with it. Comes back to the classic "You can have it cheap, quick or correct - pick two." Could waffle on for ages but I think that sums it up imho.