I have recently been studying the implications of Agile on enterprise and technology architecture. As a part of that I was looking through traditional architects relationship to other team members (structural engineers, construction, plumbers, electricians, etc). This has always been a passion of mine as a student of professions but this time I was looking
Laziness may be one of the Seven Deadly Sins, but it can be a virtue in software development. As Matt Osbun observed: I often refer to myself as a lazy developer. Occurred to me that people might not get the reference. pic.twitter.com/zmjDZjkTd6— Matt Osbun (@MattOsbun) February 6, 2015 Robert Heinlein noted the benefits of laziness:
As I was reading Roger Sessions' latest white paper, "The Thirteen Laws of Highly Complex IT Systems", Laws 1 and 2 immediately caught my eye: Law 1. There are three categories of complexity: business, architectural and implementation. Law 2. The three categories of complexity are largely independent of each other. That complexity in these categories
Can a team of experienced, empowered developers successfully design the architecture of a product? Sure. Can a team of experienced, empowered developers successfully design the architecture of a product without a unified vision of how the architecture should be structured to accomplish its purpose? Probably not. Can a team of experienced, empowered developers successfully design
YAGNI: You Ain't Gonna Need It. Sound bites are great - short, sweet, clear, and simple. Just like real life, right? Seductive simple certainty is what makes slogans so problematic. Uncertainty and ambiguity occur far more frequently in the real world. Context and nuance add complexity, but not all complexity can be avoided. In fact,
Henry ("Any customer can have a car painted any color that he wants so long as it is black") Ford was not an advocate of customer development. Although there's no evidence that he actually said "If I had asked people what they wanted, they would have said faster horses", it's definitely congruent with other statements
One of my earliest posts on Form Follows Function, "There is no right way (though there are plenty of wrong ones)", dealt with the subject of trade-offs. Whether dealing with the architecture of a solution or the architecture of an enterprise, there will be competing forces at work. Resolving these conflicts in an optimal manner
When Croesus of Lydia considered going to war against the Persian Empire, he sought advice from the best available source of his day - the Oracle at Delphi. He was told that attacking the Persians would mean the end of a mighty empire. Armed with this "knowledge", he attacked and a mighty empire, his own,
Many see ambiguity as antithetical to software requirements. However, as Ruth Malan has observed: Pick your battles with ambiguity careful. She is a wily foe. Not to be dominated. Rather invited to reveal the clarities we can act on. Make decisions with the understanding that we need to watchful, for our assumptions will, sooner or
