This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: We Do Not Live In Textbooks
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Firefox lead Ben Goodger posts on the well-explored topic of perfection vs. the real world, or Pragmatism vs. Perfection as it might more snappily be captioned. Apple chose to cut corners in the way they fixed bugs in the Safari rendered. This did not meet with approval from the KDE team trying to remerge the fixes back into their tree. Apple chose getting code to customers over doing the job perfectly. That's their prerogative, based on their needs. The KDE team are likewise entitled to their opinions, which are based on their priorities. Friction occurs when one team assume that their own worldview is axiomatic; that it is a Rule Of The Universe, rather than just one way of seeing the world.
A while ago, I was talking over database design with a contact. I talked about the way in which the database for one of our projects was defined (this is something I'll post more about; it's a big project announced at E3 on the 17th, so when real-time passes that date I'll be allowed to say more). He was pretty scathing about it. "This is all wrong", he said, "it's not normalized properly".
My response was to point out the reasons for its existence; that it held the data for a project which had started more than eighteen months ago and at that time had been heading in a rather different direction. That the requirements for the data had changed radically. That the budget for the whole project was tight and that, most importantly of all, the system had delivered what was required when it was required. In other words, it works, and works well, despite differing from his preferred Right Way To Do It. That it doesn't meet his textbook definition of the perfect database structure is not really that important a factor. Sure, given the time to redo the whole thing from scratch we'd have used a different approach; but this is true of every project, everywhere. Until you're done, you won't know the best way to do it. The real world, which pays the bills, gets the casting vote.
Beer being the excellent social facilitator that it is, we moved on from the point of potential disagreement and ended up considering the many ways in which the pursuit of perfection can lead software engineers astray. The perfect toolkit that is unusable because of its complexity. The perfect operating system that tries to be all things to all users and ends up having to violate its own axioms[0].
I'm a great believer in pragmatism, having worked (in my younger days) on a system that strove to be perfect and grew to be a monster, never quite meeting the actual needs of the users because of striving for the stars. Aim at the heavens by all means, but that's a direction, not a goal. Because we all fall short of perfection.
[1] Just to forestall the usual rash of rude emails, I'm referring to Windows here - the GUI is the axiom and Microsoft's recent conceding that a command-line shell is a good (and maybe even better) way to control remote servers is the violation of that axiom. You can, of course, insert your own Un*x-based example, should your personal opinions be more suited to it.
Previous Topic
