Two Books Every Top Software Architect Should Read
Are Your Lights On?: How to Figure Out What the Problem Really Is by Donald C. Gause; Gerald M. Weinberg
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
The Design of Everyday Things by Donald A. Norman
“But, they seem nothing to do with software!” You say.
You are right. But remember the blog title has a keyword “top.” If you want to stand out in any profession, some of the extra skills may well be outside your typical set as others expect.
The same is true for software profession. I assume you already know the basics of software programming, process, design patterns, etc., so another programming book doesn’t help you much to the top technically.
Let me explain why and how these two books help you.
The first book teaches you how to find out a real problem. How many times you see people try to solve a wrong problem? Software is designed to solve real world problems. If you miss the problem in the first place, you would shoot a wrong target resulting in no achievement in end.
Sounds like the product mangers should read this book more than an architect? Absolutely true. Remember in the book Mythical Man-Month, the role of architect is described very much like a PM today. A top architect sometimes influences the product more than a product manager in most technical companies.
After reading this book, I changed many of my thoughts regarding the problem and resolution strategies. For example, the problem is defined as the difference between things expected and things perceived. Does it mean all the problems are subjective? I will leave it to you to figure out.
The second book is written by a psychologist who had studied many things like the design of door handles. He summarized several basic principal guidelines to design everyday things.
- Visibility. Make the relevant parts visible. From its appearance, the user should be able to tell the state of the device and the possible actions.
- A good conceptual model. It could have several versions from the designer to the users. If they match, it’s quite user friendly; otherwise hard to use. Help the user by visually communicating a good mental model of how the system works.
- Good mappings. Help the user determine the relationship between actions and results, controls and effects, by using natural mappings.
- Feedback. Give immediate feedbacks to users about the results of their actions and the states of the system.
I believe these guidelines are well applicable for software even for API design. Wouldn’t be nice if we could make the software like everyday things? When it comes to API, the concept model is the object model. If you have a clean object model that is consistent with others’ perception, your API will be easy to be consumed by other developers.
To summarize, if you can design a software to address real problem, and make it work like everyday things, your software will succeed. So will you!
That is why I highly recommend these two books to you.