Laziness may be one of the Seven Deadly Sins, but it can be a virtue in software development. As Matt Osbun observed:
https://twitter.com/jetpack/status/563712928097251328Robert Heinlein noted the benefits of laziness:
https://twitter.com/jetpack/status/562440343334170624See the full post on the Iasa Global Site (a re-post, originally published here).
Laziness may be one of the Seven Deadly Sins, but it can be a virtue in software development. As Matt Osbun observed:
https://twitter.com/jetpack/status/563712928097251328Robert Heinlein noted the benefits of laziness:
https://twitter.com/jetpack/status/562440343334170624Even in the military, laziness carries potential greatness (emphasis mine):
I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent — their place is the General Staff. The next lot are stupid and lazy — they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent — he must not be entrusted with any responsibility because he will always cause only mischief.
The lazy architect will ignore slogans like YAGNI and the Rule of Three when experience and/or information tells them that it’s far more likely that the need will arise than not. As Matt stated in “Foreseeable and Imaginary Design”, architects must ask “What changes are possible and which of those changes are foreseeable”. The slogans point out that engineering costs but the reality is that so does re-work resulting from decisions deferred. Avoiding that extra work (laziness) avoids the cost associated with it (frugality).
Likewise, lazy architects are less likely cave when confronted with the sayings of some notable person. Rather than resign themselves to the extra work, they’re more likely to examine the statement as Kevlin Henney did:
It’s far cheaper to design and build a system according to its context than re-build a system to fix issues that were foreseeable. The re-work born of being too focused on the tactical to the detriment of the strategic is as much a form of technical debt as cutting corners. The lazy architect knows that time spent identifying and reconciling contexts can allow them to avoid the extra work caused by blind incremental design.
Napoleon nearly avoided his Waterloo.
Two days prior to the battle, Napoleon managed to divide the Prussian army from its Anglo-Dutch allies under Wellington. With the bulk of his forces, he attacked the Prussians while his subordinate, Marshall Michel Ney, screened Wellington’s forces dribbling in from Brussels. Napoleon’s main body had beaten the more numerous Prussians and he called on Ney’s I Corps, nearly twenty thousand strong, to fall on the Prussian right and complete the victory. Ney, meanwhile, called for I Corps to continue on to him and sweep away Wellington’s forces.
The French I Corps marched back and forth between the two battles, taking part in neither. Had either allied army been decisively defeated, then the outcome could have been much different. As it turned out, Wellington’s army was reinforced in the nick of time by the Prussians, and together they made Waterloo synonymous with downfall.
Uncertainty is an ever-present factor in the design and development of software. It is extremely important to recognize and acknowledge that uncertainty in order to mitigate it. Given that choices carry the risk of locking you into a particular approach, increasing flexibility by deferring commitment is a logical technique. One of the principles of Real Options is “Never commit early unless you know why”.
However, another principle of Real Options is “Options expire”. Decisions cannot and should not be deferred indefinitely. Failure to choose is a choice in itself and all the more dangerous if its nature isn’t recognized.
Architectural choices are architectural constraints. However, it should be recognized that constraints provide structure. Just as the walls that bound a building define it, so too design choices define systems. The key is that the definition of the system aligns with its goals and retains as much flexibility as possible.
Commitment can bring with it its own set of anxieties. Second-guessing is human nature and circumstances can be remarkably fluid. Once committed, however, radical change should be approached more carefully. Ignoring the cost of changing directions can be as much a source of analysis paralysis as failing to decide in the first place. It’s better to get into the battle with your best effort than to march around in circles hoping for something a little better.
Have you ever worked with someone with a talent for asking inconvenient questions? They’re the kind of person who asks “Why?” when you really don’t have a good reason or “How?” when you’re really not sure. Even worse, they’re always capable of finding those scenarios where your otherwise foolproof plan unravels.
Do you have someone like that?
If so, treasure them!
In a Twitter conversation with Charlie Alfred, he pointed out that you need a predator, “…an entity that seeks the weakest of the designs that evolve from a base to ensure survival of fittest”. You need this predator, because “…without a predator or three, there’s no limit to the number of unfit designs that can evolve”.
Preach it, brother. Sometimes the best friend you can have is the person who tells you what you don’t want to hear. It’s easier (and far cheaper) to deal with problems early rather than late.
I’ve posted previously regarding the benefits of designing collaboratively and the pitfalls of too much self reliance, but it’s one of those topics that merits an occasional reminder. As Richard Feynman noted, “The first principle is that you must not fool yourself – and you are the easiest person to fool.”
Self-confidence is a natural and desirable trait. Obviously, if you’re not confident in your decision, you should probably defer committing to it. That confidence, however, can blind us to potential flaws. Just as innovators overestimate consumer interest in their product, we can place too much faith in our own decisions and beliefs. Our lack of emotional distance can make it easy to fool ourselves. In that case, having someone to challenge our assumptions can be invaluable.
Working collaboratively increases the odds that flaws will be found, but does not guarantee it. Encouraging questions, even challenges is a good start – you don’t want to cause a failure because people were afraid to question the design. However, groups can be as subject to cognitive biases as individuals (for a great overview, see Thomas Cagley Jr.’s excellent series on the subject: July 8th, July 9th, July 10th, July 11th, and July 12th). No bad news is not necessarily good news.
Some times you have to be your own predator.
Getting ideas out of your head is helpful in getting the distance you need to evaluate your ideas in a more objective manner. Likewise, writing and/or diagramming forces a bit of rigor and organization, making it easier to spot gaps in the design. The more scrutiny a design can withstand, the more likely it is to survive in the wild.
When the wolf’s at the door, you’ll want to rely something that’s been proven, not pampered.
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, was destroyed.
While the Oracle’s advice was arguably accurate, it definitely wasn’t helpful. The ambiguous answer conveyed more certainty than was warranted. While Croesus was complicit in his downfall (what’s that saying about “assumptions”?), the Oracle must also accept some blame. Failing to convey the uncertainty was a betrayal.
Just like Croesus, contemporary decision makers crave certainty. Executives are frequently called upon to synthesize multiple viewpoints, many of which may be outside their area of expertise, into a coherent decision. An expert’s opinion of what’s “right” can be a seductive thing. Likewise, technologists are often uncomfortable with ambiguity, and rightly so. Implementing contradictory requirements is difficult, to say the least.
Uncertainty, however, is a fact of life. Pretending that it does not exist is neither honest, nor effective. Picking a number without any basis in reality does not serve to eliminate it. In fact, elimination of uncertainty is a fool’s errand. As Tom Graves stated in “Who will lead us out of our uncertainty”:
But that tag-line is kinda interesting – because the only valid answer is ‘No-one’.
Oh, no doubt there’d be plenty of people who would offer to lead us out of uncertainty. Yet the reality is that in every case they’ll either be a fool, a fraud, or both. The blunt fact is that uncertainty is a fact of life: there is no way to ‘lead us out of uncertainty’ – because ‘certainty’ is itself a delusion about a world that does not and cannot ever actually exist.
A tweet from Charlie Alfred provides the alternative:
@ruthmalan @bulldozer0 Learn to be comfortable with the ambiguity you can’t control, and attack with passion the ambiguity you can effect
— calfred (@calfred) April 30, 2013
Just as weather is composed of many simple physical processes whose interplay results in a chaotic whole, so too are systems (both human and machine). While we may have a firm understanding of the behavior of the various components, as our scope widens, our certainty must decrease. Tweaks to those low-level components must be tempered by the knowledge that the consequences may go beyond our intentions.
Under these circumstances, the phrases “It depends” or “I don’t know” become the honest answer. It is important to remember, however, that Ruth Malan’s definition of a good architect, one who can tell you what it depends on, applies.
Given the uncontrolled variables of network speed, client machine capabilities, site traffic, and network traffic (just to name a few), anyone who guarantees a page load time for an internet application would be Tom’s “a fool, a fraud, or both”. The genuine article would explain why a definite answer was not possible, what actions could be taken to test the capability in question, and what could be done to improve the chances of meeting the requirement when faced with various challenges.
Human systems are just as chaotic and uncertain, subject to circumstances beyond an individuals control. Akio Toyoda, President of Toyota, was recently quoted in the New York times:
“Have we really turned into a company that will be profitable and continue to grow no matter what happens to its business environment?” he asked.
“I am not sure yet, is my honest answer. An unprecedented crisis even beyond the scale of the Lehman shock may happen again,” Mr. Toyoda added. “We’ll only know the answer when such events actually happen.”
It takes a certain amount of courage to say “I don’t know”. “It depends” is not always the answer that people want to hear. However, in the face of uncertainty, they are the right answers. Awareness of uncertainty arms you to deal with events as they arise. A false sense of certainty is comforting, right up until it’s shattered.
Architect: Would it make sense to only host the UI on the SharePoint front end servers and put the other layers behind a service on another box?
Consultant: Naw, that would be stupid.
If you’ve read more than a couple of my posts, you may have noticed that I’m something of a fanatic about pragmatism. The blog was only a little more than two weeks old when “There is no right way (though there are plenty of wrong ones)” was published, and it’s been a recurring theme since. Whether designing a system or designing the process under which systems are developed, context is king and very little is truly absolute.
In the exchange above, the consultant in question didn’t need to ask about load on the front end web servers, dependencies, etc. before deciding that the idea was “stupid”. Any contextual information that might require deviating from the script appeared to be unwelcome. As it turned out, that wasn’t the case. The consultant was actually a very talented and flexible individual who had a momentary lapse in people skills. That momentary lapse, however, could just as easily poisoned the well and ended the collaboration before it started.
Most would understand that “stupid” is one of those words best avoided in all cases. However, words like “right”, “proper”, “good”, and “best” are frequently used as are “easy”, “quick”, and “cheap”. All of these are meaningless without context (and extremely subjective, even with it). Some can be positive or negative depending on the circumstances – is it shoddy “cheap” or inexpensive “cheap”? Ostensibly positive terms can seem like a weapon when you’re on the receiving end – if my way is “proper”, that would imply that your way (assuming it differs) is “improper”.
Just as lock-in creates a danger when designing, mental lock-in can lead to communication failures. Whether it is a matter of shutting down the conversation or misinterpreting it as such, the result will be the same. In my opinion, inadvertent offense is actually worse in that you’ve offended the other party and aren’t even aware of it, which can lead to unexpected issues in the future.
Another danger inherent in these words is the mindset it can foster, both in ourselves and others. We’re ill served when no one will challenge us and worse off when we’re too certain of our own skill. A few weeks back, the saying “strong opinions, weakly held” made the rounds on Twitter. It defines “Wisdom as the courage to act on your knowledge AND the humility to doubt what you know.” I’ll agree with Liz Keogh that it’s probably too much to ask for from a human, but it’s a worthy goal nonetheless.
So, does this mean that I’m advocating verbal pacifism? Hardly, I enjoy a good mental wrestling match too much for that. I do, however, recommend knowing when to be diplomatic (customers) and when to be nurturing (mentoring). As in everything, striking a balance and molding to the situation is key.
The animation at the right depicts the culmination of an illustrious career. Obviously, it was not a happy ending. Vice-Admiral Sir George Tryon, Knight Commander of The Most Honourable Order of the Bath and Commander in Chief of the British Mediterranean Fleet, secured his place in history by giving an ill-considered order and then refusing to have it questioned. His stubbornness cost 358 lives (including Tryon himself), one battleship sunk, a second damaged and the loss of his reputation.
Much has been said about George Tryon’s charm of manner, and the rest of it, but in truth he was, at any rate when officially engaged, a very brusque and dictatorial man. Unfortunately he was a ‘viewy’ man too, a man of theories…
(A description of Vice Admiral Sir George Tryon, from a July 1893 article in Society Journal Talk via Wikipedia)
On June 22, 1893, Vice Admiral Tryon ordered the eleven ships under his command to steam in two columns towards the shore. The two columns were to turn inward, reversing their direction of travel and proceed out back out to sea. However, insufficient space was left between the two columns for them to safely execute the turn. An officer questioned the spacing and was sent packing. When the officer leading the column opposite Tryon’s, anticipating the impending disaster, was slow to begin the turn, the signal “What are you waiting for?” was sent. This public reprimand yielded compliance with the order and the debacle was set in motion. Only when the collision was both imminent and unavoidable did Tryon attempt to alter course. The lead ships of the two columns, Victoria and Camperdown, collided, causing Victoria to sink with the loss of over half her crew.
Prior to the collision, George Tryon’s career had been spotless. He had risen steadily through the ranks and been knighted for his service. Most ironically, he was a progressive leader and extremely active in promoting initiative in his subordinates. Unfortunately, his surly manner toward those same subordinates led to their being terrified of him.
In “Gods and Mortals, Part 1”, I outlined the importance of collaborative design over attempting to dictate. The point of this little history lesson is that actions speak louder than words. Giving lip service to collaboration and challenging your assumptions is not enough. You must actually be open to suggestions and questions, welcoming them as an opportunity to teach and learn. The more skillful you are, the less likely people are to challenge you. The less likely people are to challenge you, the more likely you are to need that challenge. The last thing you need is to discourage those who may keep you from wrecking your career.
I first witnessed this early in my career when “the architect” would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture.
(K. Scott Allen, from “Whiteboard Architecture”)
The discussion I wish to provoke is: Is it the sole responsibility of the software architect to provide the architecture?
Or is it that the architect is best competent, skilled, verbal, and positioned to help the team (or organization) to produce the most appropriate architecture?
(Ilan Kirschenbaum, commenting on “Architecture versus Design”)
It’s easy to accumulate a backlog of ideas for posts, particularly when you write in your spare time. This one has been waiting in the wings for a while, to be forced out onto the stage by Ilan’s comment on my last post. It’s one I should have addressed a long time ago, because it touches on one of the biggest threats to software architecture: some of those who call themselves architects.
“Ivory Tower Architects” are a long standing embarrassment to the discipline. Likewise, “Architecture Astronauts” and those in love with patterns for patterns’ sake are frequently used to justify the opinion that architects provide no value. Worst, in my opinion, are the Olympians, descending to the mortal realm to dictate to the lower beings. Alone, or in combination with the above types, the “God of Architecture” is particularly adept at alienating the rest of the development team. This alienation leads to ignoring the need for architectural design, or hoping that it will emerge in some coherent form, to the detriment of the product and its users.
In “Agile Architect – What is it?”, Ilan outlined a more collaborative role for the architect:
Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)
The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.
The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.
In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.
I strongly agree. Leadership (paired with responsibility) is necessary, but a more inclusive approach makes sense from several perspectives:
The last bullet point cannot be over-emphasized. Although he was discussing enterprise architecture, Tom Graves made an important point in “Analyst, anarchist, architect” regarding the applicability of the Hegelian triad of thesis, antithesis, and synthesis to architecture:
…the antithesis is not a negation of the thesis, but a challenge to the assumptions on which the thesis is based – which then leads to a synthesis that makes real practical sense.
It’s not impossible to achieve that challenge to your assumptions when working solo, but it’s far from easy. I’d argue that one characteristic of a good architect is making efficient use of available resources. In my opinion, using the team to improve the quality of the architectural design as well as their understanding of it sounds like an efficient use of those resources. In the words of Roman philosopher Seneca the Younger: “Even while they teach, men learn”.
Form Follows Function 