Subscribe in your feed reader
In the context of The Equation of Software Design, it is now possible to reduce the primary principles of software design into just two statements:
- It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of Implementation.
- The Effort of Maintenance is proportional to the complexity of the system.
And that is pretty much it. If you all you knew about software design were those two principles and the purpose of software, you could evolve every other general principle of software development.
-Max
hehe… I’m still looking for the principle of Zero Effort for implementation AND maintenance. Maybe basic principle could be had here … “zero effort is unattainable”.
I fully agree, but can we align this to agile principles like “Simple Design” in XP?
Well, I don’t really buy into any particular existing software methodologies. So if somebody wants to say “Oh, this sounds a bit like some XP principle, and could work with it this way,” and that helps somebody, that’s great. But if the purpose is just to align the ideas because XP exists and somebody thinks that everything should fit with XP, then I don’t think that’s so great. Usually the folks who want to fit everything into their particular software methodology have something to gain personally–for example, they’re consultants for that methodology, or they wrote a book about it and want to sell more books. Not that there’s anything wrong with selling books or being a consultant. But there is something wrong with forwarding a set of ideas solely because one profits from them.
-Max
I would like to see some examples of how you could evolve the rest of the principles. It would be interesting to observe this thought process and reasoning patterns involved.
Hmm. Okay, here’s a few simple examples:
We know that complexity leads to more effort of maintenance. What leads to complexity? Well, one thing that we can show leads to complexity is tight coupling of system components. So we can evolve a principle of loose coupling simply by looking for methods of reducing complexity.
We want to reduce the effort of maintenance. So, we’d spend a bit of time observing what takes up our maintenance time. Fixing bugs certainly takes up quite a bit of that time. So wouldn’t it be great if we could eliminate bug maintenance by catching them before they exist? With a bit of experimentation, we would probably evolve the the idea of automated testing.
It’s even simpler if you trace the lower-level principle back to these higher-level simplicities.
It works for pretty much every software development principle, except for HCI principles, which I would consider a separate area.
-Max