I guess it depends on how you define "quality".
From the business point of view, I'd rather have code with a solid ROI than "consistent", "standard", "well layed out" code that doesn't do what it's supposed to or does it very poorly.
Despite what some have said here, I've seen highly consistent, well-documented, easy-to-read code, that just plain doesn't get the job done, or does it so poorly it's useless. One of the worst code solutions I've ever seen was a hierarchy resolution that used 3 procs, 2 UDFs (one of which was recursive), multiple nested cursors, several temp tables (with no indexes or primary keys, of course). It was well documented, nicely laid out, highly readable, and followed all of the company's rules for naming conventions, et al. It also started timing out less than a week after it went into production. I replaced the whole thing with a single function with a single recursive CTE, and it's been running beautifully ever since. But one of the developers here says he gets a headache whenever he tries to read any of my code, because I don't lay it out the way he wants it.
Like everyone, I'd rather have both quality and consistency, of course. But if I really do have to choose between the two, I'll take quality. No hesitation, no equivocation, no regrets, definitely quality.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon