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 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
[…] This is what I argue all the time in web design though I’ve never said it as eloquently as Code Simplicity: 1. It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of […]
Assuming the number of maintenance issues in a system is proportional to its size, you also need to consider the extra time it takes to isolate and fix a problem in a larger system.
That’s why I believe the relation between maintenance effort and system size is not linear:
In terms of complexity analysis, your second statement amounts to
m = O(c)
I would even claim that
m = O(c log c)
or
m = O(c^2)
Yeah, I actually really thought about your comment a lot, and I think you’re right. A more mathematically accurate statement would be something like:
The Effort of Maintenance is a function of the complexity of the system.
But I’m concerned that some people wouldn’t really know what “is a function of” means.
“The Effort of Maintenance is proportional to the complexity of the system.”
I think this is a fine sentence; it’s simply using the English meaning of “proportional,” not the mathematical definition.
To state it so as not to bother mathematicians, you could say:
“As the complexity of a system increases, the Effort of Maintenance increases.”
Or if you don’t care whether non-mathematicians understand you or not:
“The Effort of Maintenance is a strictly increasing function on the complexity of a system.”
đ
(If you think too much about that last statement, you’ll realize that there is no way to mathematically measure the complexity of a system, and yet you _can_ simply examine two systems and determine their relative complexity.)
Basically. đ
I rate enthusiasm even above professional skill.
There is no time for cut-and-dried monotony. There is certainly time for work. And time for love. That leaves no other time!
[…] This is what I argue all the time in web design though I’ve never said it as eloquently as Code Simplicity: […]