Old office buildings used to be designed much like homes: stone walls, plastered ceilings, wooden floorboards. Spaces to fill with furniture and people. Flexibility and change were not part of the plan.
That changed in the middle of the last century, with things like raised floors and suspended ceilings becoming the norm. This allows lighting, electrical, and telecomms services to be moved around to where they're needed. Office buildings also tend to be designed such that the internal walls are non-structural, so they can also be taken down and rebuilt easily without affecting the overall integrity of the building.
In this example, different parts of a building's function are insulated from each other, so that changes can be made to one element without affecting others.
The same thinking is useful in software. Different functions in an application should be insulated from each other.
This kind of insulation shows up in a number of techniques. Subroutines and modular programming were early examples, followed by message queues, client server, and object orientation. These are not mutually exclusive, just different tools to divide systems up in different ways.
To be effective, this kind of thinking has to be introduced early on in the design process, and like any tool you have to know how to use it. A poorly-designed object-oriented system can be just as much of a maintenance nightmare as early sixties spaghetti code.
Whatever the technique, the objectives of good insulation are pretty much the same. Each part of the system has its own special job to do and doesn't need to worry about how any other part works. This breaks the coding work down into bite-sized chunks, each with clear objectives. This not only makes the coding easier, it makes everything easier to test. It also means you can make changes to a function and be confident that your changes will not have unintended consequences elsewhere.
Imagine the chaos at home if the simple act of plugging in the vacuum cleaner caused the toilets to stop flushing. Laughable? Maybe, but that is pretty much the state many poorly-insulated software applications find themselves in.
Subscribe to:
Post Comments (Atom)
Posts
9 comments:
Hi from a fellow AtoZ blogger, I have featured your blog on my post today
http://wp.me/p2Eu3u-h6
Mmm... I must say that I haven't the foggiest about coding. Although the thought of one thing not working impacting on another does sound really bad.
Learning lots as you lead us through the alphabet.
Hi Ian .. that would distress me .. the hoover not working is bad enough, but I managed to fix it, but the loos not working at the same time - now that would be very serious! Not funny!!! Cheers Hilary
I actually have a laundry room lightswitch that kills my sound system. *shrugs* Houses are strange things.
This principle definitely applies in the work force, eh? All the parts working in harmony but not trying to do the other person's job?
Man, whoever was supposed to do this with my work computer failed. I have it crash a couple times a day, usually for something as simple as trying to close a browser window. Not sure what that's about expcpt that it's about time for upgrades....
That is exactly the reason I became an IT manager, rather than a programmer all those many years ago. I'm sure the programmers wished I had done neither! I had to laugh at your comment on my halo post regarding shining your bald head, because that is exactly what my husband said.
Hi Rosie, thank you!
Misha, it happens when you mix things together that should be separated, so changes also get hard to separate.
Delores, glad to hear it.
Hilary, worse would be if fixing the hoover broke the loos. That is often what happens in software.
Crystal, yep, that sounds like the kind of thing I'm talking about :)
Hart, computers as a whole have gotten a lot more stable, but they still throw up these things that have you asking "How the heck did doing this cause that to happen?"
Deanna, great minds think alike!
Post a Comment