#begin
The next topic to cover is reversibility. But what is reversibility exactly? Well what David and Andrew mean is that your system must be flexible enough so you can reverse or delay decisions as you write your code. This topic has been one of much debate because at some point you absolutely have to make such decisions. You have probably heard the sentence: “Good software architecture allows you to put of big architectural decisions till the last responsible moment”. But when IS the “last responsible moment”. Sometimes it can be very useful to make decisions early on. This will reduce complexity, over engineering and might jump-start development. Imagine that you would write a game but you put of using Unity3D vs. Unreal till the last responsible moment. How much will you effectively get done this way? Maybe some core gameplay, web and database logic which you can compile into DLL’s to share among these engines but further than that, not very much I guess.
But there absolutely must be flexibility in your systems so you can reverse on your decisions if you have to. Remember I explained about the databases we swapped in the previous episode because it became too slow yet we had a orthogonal system and thus could rip it straight out. Such decisions should be easy to make. If they aren’t your code is not reversible.
So let’s see what David and Andrew have to say about it. Well, the first interesting thing they mention is the fact that if you follow their advise of DRY, decoupled code and the use of what they call meta data, then you don’t have to make many critical, irreversible decisions anyway. This is great since, as we also learned in The Philosophy of Software Design, you don’t always make the best decisions the first time around. Remember the Prof. Ousterhout’s practice of ‘designing it twice’? So we don’t want to go all-in on some technology yet later find out we can’t hire the right people for the job, or maybe something sinister like vendor lock-in.
Oh and now they mention something really coincidental and I’ll quote it: “Suppose you decide, early in the project, to use a relational database from vendor A. Much later during performance testing, you discover that the database is simply too slow, but that the object database from vendor B is faster.” This is the exact thing I’ve described in the previous episode. They also specifically mention the fact that most projects would at this moment be totally screwed. At about the time-frame this book was written, around 2000, software was often design with a database first mentality. So this would have posed a major problem. Luckily, people came to their senses and made the database an afterthought as Uncle Bob would call it. The database is a detail, an IO-device, not an architectural decision!
What the authors are getting at here is that the mistake many people take is that they assume any decision must be set in stone and never change thus not preparing for any contingencies that might come up. So in software, there can never be final decisions! They are always fuzzy. They have impact as well as consequences. Software evolves and this decision could as well.
So the idea is to create flexible architecture which not just includes, flexible code but also flexible architecture, deployment and vendor integration. We’ve talked about this a lot already in previous episodes. If you follow either Uncle Bob’s of Prof. Ousterhout’s advise you will get there. My personal taste often orients to some flavour of component based architecture since, all major parts can just be components so including deployment and vendor products.
Andrew and David even go as far as taking the host OS for you application into consideration. Fortunately, Unity3D takes care of that for us. But again, consider the time this was written, there were not many fancy web-apps or smartphones so the concept of what we now call cross-platform development didn’t really exist in the modern sense of the word.
So try to keep the “big” architectural or structural decision behind some abstract interface and try to inject these, let’s call them components, automatically. Because, if things are added automatically, they can be removed automatically as well. So no manual labor is involved with replacing stuff. This is utopia I guess. But in essence the authors are right. But this will keep your code reversible.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments