Posted by Sam on Jan 28, 2008 at 06:46 AM UTC - 6 hrs
I don't like to have too many microposts on this blog, so I've decided to save them up and start
a Programming Quotables series. The idea is that I'll post quotes about programming that have one or more of the
following attributes:
- I find funny
- I find asinine
- I find insightfully true
- And stand on their own, with little to no comment needed
Here's the second in that series. I hope you enjoy them as much as I did:
Now we can see that although each language provides abstraction mechanisms, and lets you build new abstractions with the mechanism, new kinds of abstractions give us new ways to express relationships. These things can be abused, of course, but nothing can save you from this: If you don't let your Architect play with Domain-Specific Languages, what is to stop them from configuring everything in your application with XML?
(Note the acronym tag)
The earlier Ages were times when people were unsure how best to deliver business value through software development. They piled process on top of process, hoping that by finding and perfecting the right process they could ensure timely delivery of valuable software in a predictable way. When it didn't work, they logically assumed the best approach would be to do even more of the stuff that wasn't working, and to monitor the stuff very tightly with high-ceremony process controls.
Then again, all one has to do to out-perform a traditional development team is Not Suck. It doesn't even require agile development methods. Obviously, to Not Suck is a great step forward. But surely it isn't your ultimate professional goal!
Language expertise is fine, but it isn't the most valuable thing out there. If someone programs conscientiously, I can work with them. I have a lot of respect for people who write solid code despite not having completely up to date language knowledge. Language knowledge is easy: you read, you think, you try. And, you can catch up. Conscientiousness, though, is the thing that really matters. Next to it, language expertise is easy.
It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge. They "enable" features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns - at least most of the patterns in the "Gang of Four" book - make code bases get bigger. Tragically, the only GoF pattern that can help code get smaller (Interpreter) is utterly ignored by programmers who otherwise have the names of Design Patterns tatooed on their various body parts.
Steve Yegge, Code's Worst Enemy (Really, you should read the whole thing. It's important.)
Last modified on Feb 10, 2008 at 12:38 PM UTC - 6 hrs
Comments
Leave a comment
Nice quotes! I think Dave Nicolettes are the coolest. There was a whole thang when Yegge wrote his post, including some other postings noting that only Steve Yegge would even consider creating and maintaining 0.5MLoC a spare time job for a single programmer! I gotta say though that it seemed to me he was putting up a bit of a straw man with the "most professional programmers don't worry about code base size". Now if he'd said Java programmers I might have agreed :->
Posted by Peter Bell
on Jan 28, 2008 at 01:06 PM UTC - 6 hrs
I don't know - I think I might agree that most professional programmers don't really ever think about it. Maybe if you are attaching another meaning aside from "paid" to professional, then I could see it. I might like to count all the LoC I maintain. Not because I think it would approach that (and even if it did, it'd not be in a single project), but just out of curiosity. I really like Dave's quote about all you have to do is "Not Suck." That really hit home. I also got a real big kick out of Reg's "also known as..." bit. Glad someone else appreciates these nuggets =)... thanks for that!
Posted by Sammy Larbi
on Jan 28, 2008 at 01:32 PM UTC - 6 hrs
|
Me
|
