February 2009
Beginner
222 pages
5h 23m
English
Content preview from 97 Things Every Software Architect Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.
Chapter 53. Challenge Assumptions—Especially Your Own
Timothy High is a software architect with more than 15 years' experience with web, multitiered client-server, and application-integration technologies. He is currently working as a software architect for Sakonnet Technologies, a leader in Energy Trading and Risk Management (ETRM) software.
—Timothy High
WETHERN'S LAW OF SUSPENDED JUDGMENT STATES (in a rather tongue-in-cheek fashion) that "Assumption is the mother of all screw-ups." A more popular take on this would be, "Don't assume—it makes an 'ass' of 'u' and 'me'." But when you are dealing with assumptions that could cost thousands, if not millions, of dollars it's not always a laughing matter.
Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a tradeoff (performance versus maintainability, cost versus time-to-market, and so on). In more formal approaches, it is common to record along with each decision the context of that decision, including the "factors" that contributed to the final judgment. Factors may be functional or nonfunctional requirements, but they also may just be "facts" (or factoids...) that the decision-makers found important (technology constraints, available skill sets, the political environment, etc.).
This practice is valuable because listing these factors ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access
More than 5,000 organizations count on O’Reilly
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.Julian F.
I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.Addison B.
I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.Amir M.
I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.