Software design: basic principles
Wednesday, 20. February 2008, 10:50:58
6 months ago I delivered a training named "Object Oriented Design for Developers". To be true, it wasn't only OOD, but also contained design ideas from Functional Programming; it should probably be called "Software Design for Developers". Its purpose was to help developers make the leap to software designers. It tried to give them the principles, mindset and techniques used in designing software. The training should have been followed by practicing in a real-life project, under supervision.
To be fair, I have to say that it was too theoretical, missed laboratories and examples and was probably too difficult to digest for most attendees. That's why I plan to completely rewrite the training materials and to add the missing pieces. But I digress.
There are a few basic ideas that need to be understood by anyone who wants to be a good software designer.
Any person's brain is too small to be able to design complex systems.
This doesn't apply only to software, but to all areas of engineering. What does it mean? We shouldn't design complex systems? Certainly not. We should continue designing complex systems, but keeping in mind the second idea:
Because our brains are too small to design complex systems, we need to manage complexity.
In the pure spirit of this blog, I can only notice that this is related to the human factor:
All design methodologies we're using are driven by limitations in the human brain.
Structured Programming, Object Oriented Programming, Functional Programming, Service Oriented Programming and so on are just methods we're using to manage the complexity, because our brains are too small to easily and completely design complex systems. If you want to design software, it's very important to understand those ideas.
Starting from those three ideas, people have derived rules for software design and development. Let me enumerate ten of them:
If you are interested about learning more on the subject, read this. For some people, it may be surprising ;-).
I'll talk about it soon.
Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu
To be fair, I have to say that it was too theoretical, missed laboratories and examples and was probably too difficult to digest for most attendees. That's why I plan to completely rewrite the training materials and to add the missing pieces. But I digress.
There are a few basic ideas that need to be understood by anyone who wants to be a good software designer.
Any person's brain is too small to be able to design complex systems.
This doesn't apply only to software, but to all areas of engineering. What does it mean? We shouldn't design complex systems? Certainly not. We should continue designing complex systems, but keeping in mind the second idea:
Because our brains are too small to design complex systems, we need to manage complexity.
In the pure spirit of this blog, I can only notice that this is related to the human factor:
All design methodologies we're using are driven by limitations in the human brain.
Structured Programming, Object Oriented Programming, Functional Programming, Service Oriented Programming and so on are just methods we're using to manage the complexity, because our brains are too small to easily and completely design complex systems. If you want to design software, it's very important to understand those ideas.
Starting from those three ideas, people have derived rules for software design and development. Let me enumerate ten of them:
- Rule of Modularity: Write simple parts connected by clean interfaces.
- Rule of Clarity: Clarity is better than cleverness.
- Rule of Composition: Design programs to be connected to other programs.
- Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
- Rule of Simplicity: Design for simplicity; add complexity only where you must.
- Rule of Robustness: Robustness is the child of transparency and simplicity.
- Rule of Least Surprise: In interface design, always do the least surprising thing.
- Rule of Silence: When a program has nothing surprising to say, it should say nothing.
- Rule of Repair: When you must fail, fail noisily and as soon as possible.
- Rule of Extensibility: Design for the future, because it will be here sooner than you think.
If you are interested about learning more on the subject, read this. For some people, it may be surprising ;-).
I'll talk about it soon.
Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu
