Three months ago, I wrote an article Random Thoughts on IT Automation. I think it’s a pretty good style for capturing ideas without worrying much about content organization and flow. So I decide to use it again on software design which I have been practicing and thinking for many years.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
• A good software design starts from the problems it tries to address, not the frameworks/APIs it can rely on.
• Software design is a dynamic process. It changes over time.
• The biggest value of a software design is to force the team to think through the critical decisions, and bring everyone on same page.
• A design committee only improves a design when an open minded member can make final calls. It turns out not true in reality, so most designs by committee are bad.
• A software design is not part of final deliverables. Stop when it’s enough for implementation.
Principles and Tools
• Design principles are easy, but how to apply them on a right project in a right way is hard.
• Apply software design patterns only when you have to. In most cases, design patterns are liabilities due to misuse or over use.
• A good metaphor simplifies a design and makes it easier to learn and follow.
• A basic goal of software design is to divide a complex problem to smaller and more manageable components/modules.
• Not all frameworks/APIs are created equal. Use them only when it justifies the effort to learn and the cost of inclusion and maintenance. Be conservative and selective!
• UML is nice, but not a must. Don’t try to standardize on design languages.
• If you can generate code with a model, then the time to build the model is most likely longer than to write code directly.
• One way dependency is good because it means code reuse; two way dependency is bad because it means two modules are still tightly coupled.
• Only software code fully and exactly describes the behavior of a system. A design does not.
• Unlike code, a design is not testable with strict and consistent procedures.
• Work hard for simple designs, not smart designs.
• A good design must be consistent in concepts, terminologies, structure, interfaces, and protocols.
• Be realistic on a design: don’t expect it to solve all possible problems, but existing and potential problems; don’t expect it to be all correct, but to change over time; don’t expect it to cover all aspects, but to improve over time; don’t expect it to be perfect, but consistent and simple.
• A design is to guide the implementation afterwards. If it’s not understood by all stakeholders, its value is compromised significantly. Therefore simplicity is a must.
• Don’t go extreme on design principles and guidelines. Nothing is absolutely correct in all contexts.
• Whoever designs an architecture should follow through its implementation, and be held accountable for its success or failure.
• A good software architect must have gone through a full cycle of a project including maintenance phase in which the results of many design decisions finally show up. This first-hand experience cannot be learned anywhere else.
• A good architect should be a good coder, at least in early days of her career. Without good sense of implementation, an architect may come up with nice diagrams but not implementable.
• Small projects share almost the same design principles as large projects, therefore are good places to accumulate architecture experiences. So are open source projects.
• The audiences of software designs are human beings and human beings only.