Microsoft Patterns and Practices is an extreme case of my theory about consultants. These guys appear to have never shipped anything that will be used by real users. That wasn’t always true. Early versions of the Data Access Block were quite useful. But then they started building examples that showed every possible facet and feature they could think of. And people started using these examples as guidance. Probably because P&P told them to.
The problem was, these things were too complicated for any real use and too complicated for a mere mortal (or even one of those rockstars. or was it ninjas?) to be able to extract just the little bits that could help them. And so people just started using these things whole hog, even if they only really needed 10% of the functionality. And don’t get me started on how big consulting firms (like the Big 6, or however many are left these days) love to use them as a basis for their lowest bidder projects that overrun schedule and budget…
What’s even worse is that typically these things do not follow sound software development principles. To them, OO is a typo where someone forgot to include the "W" (WOO!). People use these things as guidance to learn from. There’s an idea that there is nothing worse than to lead an innocent to sin. I’m not calling them evil or anything, but this guidance isn’t doing anybody who’s learning how to code in .Net any favors.
And of course, most sample code has this problem. In the sample code accompanying an article or a presentation, sometimes it is necessary to leave out the parameter checking and error handling code so that your point is clear. Its not the greatest thing, but its usually worth the tradeoff. It might be nice if maybe we started including the "well written" version in our sample code downloads.
The problem is, P&P ships these things as guidance. They implicitly say – if you write your code like this, everything will be great. And that’s probably true for version one but the omissions and issues of version one tend to live a long time. Not following good OO and development practices makes it hard to maintain and improve the application and that’s no fun.
Don’t take any one source as the guide for how you build software. Microsoft has provided a lot of very good tools and some very good guidance about how best to use those tools. But that guidance does not apply to every situation and some of it really doesn’t apply to any. Make sure you look at all sample code (or even open source project code) with open eyes. The author probably has a viable solution to a problem and it might even be your problem. But don’t assume it is the best solution for your needs.
Shipping software is hard. Even if you are just packaging it up lightly so you can put it on a couple machines in Accounting down the hall, once it leaves your protected little world, anything can happen. And usually does.
And so we have TDD and BDD. Code reviews. Pair programming. Code coverage reports. Programmer testing. QC testing. QA testing. Performance testing. You get the idea – we have a lot of ideas about how best to make the transition of our software out to the real world as smooth as possible by making sure the software is good enough.
Good enough. That’s the key words here. Unless you have written a very trivial application, you will never ship something bug free. Think about that for a second. It’s depressing if you let it get to you. Now, think about some of the things that count as bugs – some of them are issues because the software doesn’t work the way the user expected. Or other things you couldn’t have possibly envisioned anybody doing with your software. It happens.
If you try to fix all of the possible issues, you will never ship. This leads me to a theory I’ve been toying with, the one that has to do with shipping software: Never trust a consultant who hasn’t shipped software in X years.
I haven’t decided yet exactly how many years. Maybe you just have to go with your gut. But the more I read from industry luminaries who espouse things like all code must be covered by tests that were developed in a TDD fashion or that you have to develop on the trunk so you can continuously deploy, the more I think that my theory might just be worth something. 1
I’m not saying to forget about this advice. Its good advice, in theory. But don’t take it to an extreme. Extremes tend to cause pain.
1 In fairness, I’ve been a change agent at various points in my career. I know that sometimes you have to make an extreme statement (and follow through with it) in order to break old habits and effect change. Ask me about stored procedures sometime…
In the current edition of the ThoughtWorks Technology Radar one item they suggest is to create a technology radar for your own company. As I have been tasked with tracking what tools and technologies we use and might use, it seemed like a excellent suggestion. It’s a great format to present this information in a very readable and usable fashion.
And then the reality sets in. I don’t know how to make that pretty little target-like graphic and populate the dots. It seemed like I could use Excel. But try as I might, the radar chart type just wasn’t doing the job. So I looked to see what my drawing tool of choice, Visio, could do for me. Again, no dice.
So, as a last resort, I went to PowerPoint. And then it occurred to me – the content and general idea of how the items relate is what is truly important. And I probably didn’t just have 4 classifications I cared about. Plus, I want to be able to show the items that have been rejected or retired. So I came up with a flatter chart that does the trick. I have a page for each class of technologies, which reduces the clutter a bit. It also allows me to have many different classifications, which better serves my purposes.
You can of course use whatever phases you’d like for your chart. The first 3 columns in my chart are for technologies that are being evaluated. The fourth column is for technologies currently in use, the last two for technologies that we are weaning ourselves from. The bottom chart is for items we have rejected and retired, as well as a holding spot for technologies that we had been researching but stopped looking at for the moment because of some changing priority.
The actual items themselves are just text boxes. This makes them easy to move around, which allows you to easily update the chart with any changes. I’m planning to release a new version of this internally every month. You could do it whatever frequency makes sense for you’re company.
You can download a sample slide to use as a basis for your chart here. Just duplicate the slide for every classification you want to track.