Planning for the Future

Alex Campbell griped a bit earlier about how much of a complete pain in the butt it is to maintain an overly complex system. Demonstrative/educational reasons aside, it's quite unnecessary to build platform flexibility into a system when the platform has already been decided. Yes, I do realize that punch card based data providers do not support stored procedures, but sometimes it's just easier to code for a SQL-92 database provider than to build an abstract data factory layer that can handle anything, including cuneiform tablets. Anyways, that got me thinking ... do folks in other fields think with the same “what if they change their mind later” mindset ...

Home Builder - We feel uncomfortable giving you just a standard two-car garage. What happens if you want to change your primary transportation to an earth mover or a pocket bike? No, we're going to set it up so all you have to do is extend the length and distance on a few poles, and viola!, new garage. Bricks? Well, no of course not, that's not flexible enough ...

Chef - Hey! Don't put mayonnaise directly on the sandwich! If the patron gets halfway through dinner and wants mustard instead, he would have to scape the sauce off of the meat and probably have to get a whole new bun. It's much more flexible to mix the mayonnaise with a flavorless gelatin solution to make it a semi-solid and allow the patron to peel it off and change it to whatever sauce-block she wants.

Privacy Fence Builder - Hmm ... having the gate over here doesn't make much sense. If we need to move it later, it's a pretty complicated process. We'll just build the entire fence out of gates, and lock the ones we don't need. Of course, if we want a gate in between two gates ... hmm ....

Any others I'm missing?

3 Comments

  • ooh ooh. do Doctors/Surgeons. perhaps the patient will change his mind about this kidney transplant so we should install it as an external module instead of embedding it with the rest of the, erm, source code.

  • It's funny you mention those metaphors. I was in a meeting one time, and the client was talking about how they wanted to make a change that would've affected all 3 tiers of the application, the architecture of it, etc. They totally weren't able to understand why some much would have to change.



    I ended up saying something like, "Imagine that after attempting to fix a faucet that didn't work you realized the reason it didn't work was because there were no pipes or plumbing at all in your house. Changing the faucet isn't the only change that's needed."



    That apparently was clear enough and they understood things after that.

  • Thanks Alex! This is a much more amusing illustration of what I was trying to put forward.

Comments have been disabled for this content.