And you are here why?

/via http://geek-and-poke.com/geekandpoke/2008/2/4/the-art-of-programing.html “ How do we build quality software? ” It’s a pretty simple question to ask, but one in which the answer can take pages. For starters, what do we mean by  Quality ? We could get into the whole definition of  Quality , and go off on a digression about the false dichotomy of separating  Truth  And  Quality , about the need to fuse  Rationality  and  Romanticism , and then end up wandering off and reading  Zen and the Art of Motorcycle Maintenance  all over again. Mind you, that would be my attempt at ignoring the original question (See?  Thats  why I could never be a politician!), and we can’t have that, can we? The thing about  Software Quality  is that so much of it falls into a “ I know it when I see it ” category (with apologies to Oliver Wendell Holmes). Everybody has their own take on what it actually is, though you...

“QA testers do not provide assurance; they help provide analysis and feedback.”  (•) Ask yourself the following —  • Does your team believe this? • Internalize this? • Do they all implicitly have tests with each of their commits? • Do they care about code-coverage? • Are the tests explicating quality? Testing, and QA, are not just about checking functionality — they are about embedding quality in your system, in your processes, and in your maintainability. To summarize, you should • Test throughout the process  not  only at the end  : Test early, test often, and start testing as early in the development process as you can • Build maintainability (and quality!) into the code  : Looking for places you didn’t meet the specs is a never-ending task. Instead, write for fault-tolerance/reliability, and then find bugs where you  weren’t  reliable • Understandability of your code-base is vital — test for it  : Oh,  you  may know ...

James Hague ( Programming in the 21st Century ) points out that we really, really shouldn't be focusing on Optimization.  To quote In any modern discussion of algorithms, there's mention of being cache-friendly, of organizing data in a way that's a good match for the memory architectures of CPUs. There's an inevitable attempt at making the concepts concrete with a benchmark manipulating huge--1000x1000--matrices. When rows are organized sequentially in memory, no worries, but switch to column-major order, and there's a very real slowdown. This is used to drive home the impressive gains to be had if you keep cache-friendliness in mind.    [...] Linked lists are a worst case, potentially jumping to a new cache line for each element. That's damning evidence against languages like Haskell, Clojure, and Erlang. Yet some naive developers insist on using Haskell, Clojure, and Erlang, and they cavalierly disregard the warnings of the hardware engineers and use ...

I could get into the whole definition of Quality, and go off on a digression about the false dichotomy of separating Truth And Quality, about the need to fuse Rationality and Romanticism, and then end up telling you to Just Go Read Zen and the Art of Motorcycle Maintenance .  Mind you, that would be my attempt at ignoring the original question (See?  Thats why I could never be a politician!), and we can't have that, can we? Back to Software Quality - the underlying issue in defining it is that it really depends on where you are standing.  Lets just assume that you know what you care about vis-a-vis methodology, i.e., you want modular code, written in erlang, using Strong OTP Principles, etc, etc. etc.   At this point, you should probably look for Software Quality based on the people involved.  i.e., if you have quality people, you'll probably have quality software.   ( Joel Spolsky has a great writeup on this, which I am absolutely ...