3 ms·
Your approach seems like it would reduce the likelihood of implementation-time surprises. It also seems like different sections would satisfy different audience
by tejohnso 6y ago
Your approach seems like it would reduce the likelihood of implementation-time surprises. It also seems like different sections would satisfy different audiences. Do you have any book recommendations?
- IgorBog61650384 6y agoTwo books I that were instrumental for me to learn how to explain the architecture of my software clearly to other people were "The Architecture of Open Source Applications" Volumes I and II (http://aosabook.org/en/index.html http://aosabook.org/en/index.html)
- Spearchucker 6y agoI do indeed. Here's a complete list of books I recommend when asked - https://www.wittenburg.co.uk/Work/Books.aspx https://www.wittenburg.co.uk/Work/Books.aspx The one that made the biggest impact on my approach to architecture is "Designing Solutions for Your Business Problems: A Structured Process for Managers and Consultants" by Betty Vandenbosch. The one that made the biggest impact on me in ever is "Wicked Problems, Righteous Solutions" by Peter DeGrace and Leslie Hulet Stahl. Lots of forehead slapping and kicking myself ensued. Even more applicable today than it was in 1990 when written. "Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister comes as a very close second. Not directly architecture or technology-related is "The Story Factor by Anette Simmons". It... changes you. Really useful for technical writing.