Geeks and especially programmers often have strong belief in "doing things right". People have remarked on this tendency, and given it a variety of negative characterisations: obsessive-compulsive, irrational, making a moral issue out of a pragmatic question.
As a geek and a programmer, I put my hands up to this stereotype - it doesn't affect us all, but enough of us (myself included) have some degree of it that I don't think it's inaccurate. However, I believe that far from being a drawback, it's arguably a vital component of a gifted developer.
I think this urge toward technical correctness comes from three main sources:
Good programmers spend a lot of their time thinking in details - they have to, to be able to write reliable code. Programmers who gloss over or fudge details write buggy code with unhandled and unknown edge-cases.
Importantly, this code usually "sort-of" works most of the time (or at least, the obviously broken bits quickly get patched), and then occasionally fails spectacularly and catastrophically... at which point it's also usually blamed on the programmer who wrote it, rather than the manager who specified an over-complex requirement, or who provided an unreasonably small amount of resources (time, money, manpower) to achieve it.
Being a programmer is 50% artistic and 50% autistic, so it's hardly surprising that programmers can be a bit Aspergers-y about their code, especially when they're likely to carry the can for any catastrophic failures caused by it.
Any programmer who isn't a journeyman or hack does the job because they like to create things, and as you get better mere creation isn't satisfying - instead you want to create things of beauty.
It's been noted before that (many or most good) programmers are makers - we need to feel that what we're creating reflects our abilities - something we'd be happy to put our name to - and we like delivering good, reliable, flexible, well-designed systems.
Banging out code or design you know is buggy, unreliable, inflexible or has unhandled edge-cases is simply not rewarding in the slightest. It's like hiring an artist to paint a wall blue, or hiring a sprinter to walk slowly to the shops for you.
To be fair, this is a very wishy-washy, non-business-oriented motivation, but I'd go so far as to say pretty much all the best programmers suffer from it - it seems to go with the territory, and not just from programmers, either - chefs are notoriously histrionic, artists are notoriously high-strung about their work and musicians are notoriously unstable or prone to mental illnesses. I don't think you can have excellence without pride in the work, and I don't think you can have pride in work without disillusionment and frustration when you're forced to churn out work you know is crap.
I've been privately or professionally involved in software development for around 15 years. I've worked in a variety of companies, in a variety of languages and systems, and with a variety of different management styles.
Across all companies, management structures, languages, technologies and system there are only two things I'm utterly certain of:
- Given the choice between a longer/more expensive design and a simpler, less flexible one, management will almost always say "design it to the current requirements, because we'll never need <hypothetical scenario X>, and it would be a waste of time to build a system which takes it into account".
- From the date of hearing this, within six months to a year they will discover a pressing, immediate, unavoidable and business-critical need for scenario X... and if they don't react well to being told that this will now take longer to accommodate, they often react really badly to being gently informed this is the result of the decision they took several months previously, at which point you (or your predecessor) informed them that this would be the consequence if they ever encountered scenario X.
Personally I try very hard to avoid taking dogmatic positions on anything, but in the years I've spent programming (especially professionally, when you're most likely to have to compromise on the design or implementation to hit deadlines or budgets), I - literally, with no exaggeration - don't believe I've ever heard "we'll never need that" and then not had to implement it (whatever it was) within a few months of that date.
This only has to happen a few times (especially when you're responsible for cleaning up the mess) before you become firmly convinced that creating a system that's any less flexible than you can possibly manage is ultimately tantamount to just fucking yourself square in the ass.
There are reasons...
So yes - there are a number of reasons why programmers are obsessed with Doing The Right Thing, and why we tend to react with aesthetic revulsion to the idea of fudging designs, or hard-coding things for convenience.
Some of them are unfortunate but understood and accommodated in other disciplines - try commissioning an artist to produce art for your offices then ban him from using anything except potato-prints, or tell an architect (for deadline/budget reasons) to design you a building that they know damn well could fall down at any moment.
Others are actually vital aspects of being a programmer that you can't easily switch on and off - athletes have to be fit, programmers have to be anally-retentive and precise - and that you really wouldn't want to do without in your dev team.
Lastly, if you're a non-technical co-worker or manager, programmers often have a lot more experience working on software projects than you do, and have learned hard-won lessons you aren't even aware are available to learn... particularly lessons where they have to pick up the pieces from their own (or other people's) mistakes.
So yeah, geeks can be hard to work with. But then the guy who knows where the landmines are buried can be awfully prescriptive about where you put your feet as you navigate through a minefield, too. And unless you want your feet blown off, it's often worth listening to them.