My house is somewhat eclectic. The core of the house was built in 1954 and it had 3 bedrooms and one bath. The original owners, as they got too frail to manage the steps to the second floor where that one bathroom was, put on a new master suite on the first floor adding one more bedroom and another full bath. Finally, after we had our two kids, we decided to add on instead of moving, and did some remodeling and in addition to a bunch of other things we added another bathroom.
Three bathrooms, built in 3 different decades, over a span of about 50 years. And I can assure you the oldest bathroom still has the original fixtures – my wife complains about it periodically, so you know its true. Granted, I’m sure some of the hardware has been updated, but maybe not.
This evening I replaced to water supply line to the toilet. Once I diagnosed that the leak was in that small section of pipe and its permanently attached fittings, I went to the hardware store to buy a new one. I never bothered to take the measurements, much less write them down. I went to the local hardware store and went right to the plumbing aisle. I tracked down supply lines and found they come in all sorts of lengths. But they come with only two types of connectors – one kind for supplying a faucet and one for supplying a toilet. Sure, there could have been other more esoteric options that were outside of my field of vision, but my statement holds true for every length of flexible pipe on the rack.
I picked up the shortest length, because the shutoff is on the wall, and I had a vague idea of the length I needed. I pulled out the old supply line and double-checked to make sure the connectors before I seated and tightened everything. It was an unnecessary step – the connections were of course correct.
What does this have to do with technology? Well, in terms of hardware, technology is pretty much in the same place. Most parts, especially cabling, are standard and easy to mix and match.
Software is a different story, isn’t it?
Of course, we can look at the tried and true examples of how you need Word to edit a Word document (not completely true anymore). And how you can’t use .Net Remoting to connect to a Java RMI application. And so on.
But what about the cases in your own applications? Sure, if you are building a simple system you know all of the pieces will fit, because you hand carve them to fit. But as you introduce more and more pieces, you find its harder and harder to have all of the pieces communicate. Its virtually impossible to swap out one piece for another.
Unless you plan for it. Those of you that know me well know I’m an advocate for minimal documentation and planning. But that doesn’t mean all documentation and planning are bad. Far from it – the right documentation is utterly important, unless you like getting calls at 3 AM. And its not planning that’s bad – its rigid adherence to an unchanging plan.
So, when I say plan for it, I mean you should have well documented interface contracts. Where possible, you should use a common infrastructure for passing commands and queries. Isolate your business logic and domain objects behind request/response objects and DTOs. Program to an interface, instead of an implementation. Yes, much of this is cliché these days. But that doesn’t mean it isn’t good advice. Taking the time to think about the connections and operations will save you time in the end. Trust me, I see it all the time. Some of it is even my fault.
Eric Kepes 