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 seventh in that series. I hope you enjoy them as much as I did:
In the software industry, we've been chasing quality for years. The interesting thing is there are a number of things that work. Design by Contract works. Test Driven Development works. So do Clean Room, code inspections and the use of higher-level languages.
All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.
That's the magic, and it's why unit testing works also. When you write unit tests, TDD-style or after your development, you scrutinize, you think, and often you prevent problems without even encountering a test failure.
Perhaps I've made it seem like I'm on the side of the pirates. Just to make it clear that I'm not sailing under the jolly roger: In my own view, piracy is wrong. It's wrong even when the people making and selling the game are senseless, self-destructive fools. It's wrong even if the game sucks. It's wrong if you're broke. It's wrong even if "you weren't going to buy it anyway." It's wrong and I don't do it, ever.
It is not my intention to preach at pirates and get them to change their habits. I'm not anyone's mum, and it's not my place to tell people how to act. I actually think that having lots of people repent of piracy right now would be horrible. The managers would conclude their monstrous policies were working, and we'd get a double helping of the same, forever after, in every game they put out.
Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM's clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.
It's definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM's.
I am not at the mercy of some big up-front UML diagrams or "non-agile" models grounded in getting something wrong in its entirety and very thoroughly before you take measures to fix it (or even begin to detect it).
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Thanks for the recognition.
For what it's worth, I believe that the cure against UML-style big up design is in rapid prototyping and iteration, while constantly reevaluating the parts that are the most important. My boss is twice my age and carries scars from big failed UML projects (even if she also came from big successful UML projects) and has helped shape the way we work into something that's both correct, thorough and has allowed us to turn on a dime when necessary. It helps to know your domain, work with smart people and use great tools that you already know.
Posted by
Jesper
on Jun 25, 2008 at 01:26 PM UTC - 5 hrs
"I believe that the cure against UML-style big up design is in rapid prototyping and iteration, while constantly reevaluating the parts that are the most important."
I think the same. In fact, I'm trying something a bit new at the moment where I have a one(ish) line description of the application, I start to build it, and refine daily/weekly.
It may work in this case because the base is a fairly common application, but it would be interesting to test it on something less common.
Anyway, thanks for the comment and the quote. I thought you put it better than I could have.
Posted by
Sammy Larbi
on Jun 26, 2008 at 07:27 AM UTC - 5 hrs
I feel I have more to say on this... You can easily fool yourself, like so many have, into thinking that rejecting UML and its ilk is just for want of playing the design by ear. Rather, it's a bit like planning a cross-country car journey and deciding and memorizing the exact route, including stops, beforehand. But what if that gas station or restaurant you had planned on stopping by was closed? What if traffic was heavy somewhere, or the road was closed, or an entirely new road had been built since your map was drawn?
Planning isn't insane, but relying entirely on planning and considering every deviation disastrous clearly is.
Posted by
Jesper
on Jun 26, 2008 at 12:11 PM UTC - 5 hrs
Great points again. I think I may turn this into a blog post in the future. Thanks for the idea, if you don't mind me using it. =)
Posted by
Sammy Larbi
on Jun 26, 2008 at 02:32 PM UTC - 5 hrs
I'll be happy to see if a longer post comes out of this discussion. I'm still fashionably young (not yet 23) and relatively inexperienced, although as you might be able to tell I've been thinking about this for a while. Exactly where "UML-style" and "agile-style" development both fail and where the sweet spot lies is something I haven't seen much written about; I suppose mud-flinging is more expedient and satisfying.
Posted by
Jesper
on Jun 27, 2008 at 12:02 PM UTC - 5 hrs
