So my last post ruffled some feathers, but Steve hit the nail right on the head in his commments, and it was sort of the subtext of what I was saying:
All this kerfuffle about "software craftsmen" and "code quality" and "best practice" misses the ultimate fundamental truth :
Good Developers Write Good Code, Instinctively
Let start with a funny statistic ... it certainly applies to drivers, I'm sure it applies to developers too (and almost any group of people) ...
80% of developers think they are above average!
Our logical brains can't help but admit that at least 30% of developers are therefore deluded. Our mathematical brains can't help but admit that 50% of developers must be totally average or below average. And yet, most of us think we are above average developers. I would boldly go further, and put myself in the top 20% of developers - I like to think I at least have a damn good idea who the 20% above me are and why they are better.
If you are a "good developer" you will write "good" code. It will probably use a dozen standard patterns, maybe without you even knowing what they are called, it will have low coupling, high cohesion, be easy to test, easy to extend, hard to modify, avoid duplication and abstract code behind well thought out interfaces. And yet despite all that - you may well have never heard of software patterns, OCP, ISP, DIP, unit Testing, DRY, YAGNI, etc etc etc
Before The Renaissance
There was a time, which sadly I am old enough to remember, when we didn't have all these fancy names, and yet we pretty much did what all the enlightend are doing today.
We may not have had "unit testing", but we had "test harnesses", and we may not have had automated tests running after every build, but we had QA people using our test harnesses to verify our code.
We may not have had software patterns, but we all used factories, observers and singletons.
We may not have has SOLID, but we wrote good decoupled code, well abstracted, easy to test and easy to maintain.
None of These Things Are New
While many like to go on almost holy crusades about these wonderful new inventions, some of us know that these are just evolutions of things good developers have been doing since programming began. Sure they are now formalised, they have great names, they have been refined to be more automated and more efficient - but at the end of the day - good developers already did this stuff.
What concerns me more is how "new" these things seem to some of the holy crusaders. I remember code I wrote in 6502 assembler that had these principles applied (you try writing games in 3.5kb of RAM if you don't apply DRY), I remember code I wrote in COBOL on a PDP/11 that had "factories".
I remember working on a RAD team in an investment bank, long before RAD had meaning. We delivered software fast, direct to the customers, with rapid feedback and weekly releases. We sat with the traders, we were "Agile" and "Lean" long before anyone thought of proper words.
These great software practices were not invented, they were formalisations of things we were already doing.
All Of These Things Are Good
Before anyone decides to rip my head off and banish me to the pits of hell, let me state - all of these practices are good. More over, these practices are (probably) the pinnacle of our current understanding of development practices garnered over the last 30 or 40 years - and we should strive to write code with these things in mind. In 5 years I have no doubt all these things will have evolved, and there will be new best practices. Half of these things only apply to Java and C# anyway - in the world of F#, Erlang, Ruby and Python there are new principles and best practices.
Formalisation of all these practices, principles and methodologies is good - it helps promote understanding and gives us a way of communicating.
The thing is, the real "above average" developers were probably already doing this - and all that code they wrote for the past 30 years is probably still running your bank accounts, processing your taxes and helping keep your aircraft in the sky, precisely because they already did.
Below Average Developers Will Always Write Below Average Code
No way to avoid this I'm afraid - we can talk about the need to raise the bar, to raise the average, to help those below average developers write better code - but fundamentally, below average developers will always write below average code. The above average developers need to recognise this, and understand that they will always feel they are being held back by the lower 50%, and they are always fixing the code of the lower 50%, and they are always doing more than their share.
And one last question... are you sure YOU are above average? I'm not sure myself, in fact my most common comment in interviews is that I am not the best C# developer in the world by a long way, I am rarely the best C# developer in my team for that matter. Am I in the top 20%? Probably by my own standards and measures - that doesn't mean I am by everyone else's measures.
10-06-2009 9:09 AM