Richard Monson-Haefel Quotes
“Although well meant, many things that are designed just to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use and to fulfill that use well. Effective generality comes from understanding, and understanding leads to simplification.”
“Generalization can allow us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it.”
“A good architect should lead by example, he (or she) should be able to fulfill any of the positions within his team from wiring the network, and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.”
“As has been said elsewhere the architect is the interface between the business and the technology team, the architect must understand every aspect of the technology to be able to represent the team to the business without having to constantly refer others. Similarly the architect must understand the business in order to drive the team toward their goal of serving the business.”
“The idea that schedules can be shortened in order to reduce cost or speed up delivery is a very common misconception. You‘ll commonly see attempts to require overtime or sacrifice ―less important scheduled tasks (like unit-testing) as a way to reduce delivery dates or increase functionality while keeping the delivery dates as is. Avoid this scenario at all costs. Remind those requesting the changes of the following facts:
- A rushed design schedule leads to poor design, bad documentation and probable Quality Assurance or User Acceptance problems.
- A rushed coding or delivery schedule has a direct relationship to the number of bugs delivered to the users.
- A rushed test schedule leads to poorly tested code and has a direct relationship to the number of testing issues encountered.
- All of the above lead to Production issues which are much more expensive to fix.”
“Every decision we make for our projects, be it technology, process or people related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.”
“In the end, all vendor products and application architectures are constrained by the same fundamental principles of distributed computing and underlying physics: applications, and the products they use, run as processes on computers of limited capacity, communicating with one another via protocol stacks and links of nonzero latency. Therefore people need to appreciate that application architecture is the primary determinant of application performance and scalability.”
“Design is a discovery process, as we implement we discover new information, often impossible to know up front. By accepting that design is an ongoing and empirical process in a forever changing world, we learn that the design process must be flexible and ongoing too. Clinging onto your original designs and trying to force them through is only going to end up with one result so you need to learn to understand that it will never look like that.”
“As you work in requirements meetings to design software, pretend that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true. Your customer is not your customer. Your customer‘s customer is your customer. If your customer's customer wins, your customer wins. Which means you win.”
“To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It‘s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.”
“Many software projects get software architects involved only in the design phase, then they move to other projects or the consultation contract ends. How can they ensure that their deliberate architectural decisions have been implemented correctly? Their decisions will be at best good intentions unless they follow-through with them.”