You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
7 behaviours to avoid in a software architecture role
Over the years, I’ve had the opportunity to work in architecture roles alongside experienced software/technical/solution architects. Through observing others and my own trial and error, I’ve learned a little bit about what not to do in these roles (because it’s often easier to reflect on what didn’t work rather than what did). Even though I lean towards the idea that everyone should be architecting the system rather than having architects solely responsible - I recognise that some organisations are far from that ideal, and it’s those folks I hope find this list helpful. So here it is, 7 behaviours to avoid if you’re in a software architecture role:
1. Don’t ignore the engineering team
If you’re not “hands-on” with the engineering team either through writing or reviewing code or deep in the technical discussions, then the likelihood is you aren’t close enough to the problems and the individuals on the team. If you’re not feeling their pain, then you are probably lacking the empathy and understanding to provide effective guidance. If you find yourself in this position, I would consider beginning with one-on-ones and pairing with engineers as the quickest way to increase empathy and understanding. Then look to participate in feature kick-offs, technical design discussions and code reviews where necessary.
2. Don’t ignore the domain
It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering. That said, you’ll want to avoid being a communication bottleneck too, so it’s important to teach, translate and document domain context and business value for the engineering team. This is where techniques like value-stream mapping, event storming and domain-driven design can really help.
3. Don’t prescribe or mandate architectures
For the most part, our industry has moved past the notion that a system’s architecture is designed in isolation (or in an ivory tower) and handed-off to engineers to deliver. However, it definitely still happens. Software architecture and development should be inter-weaving activities, with feedback from one influencing the other. Keeping that feedback loop as short as possible will likely lead to better outcomes. So if you would like to design and create more resilient systems and your organisation tends to mandate or prescribe architectures; consider how you can best empower engineers to make sound architecture decisions instead. Working with the engineers to agree on a foundation of architectural principles and accepting that architecture is never done, it should evolve and change over time are good places to begin (see the Building Evolutionary Architectures book for more on this).
4. Don’t just seek architectural consistency
Consistency certainly has a place in organisations that build and maintain many systems in order to to help prevent complexity. In my opinion, it’s better to see it as a guideline that will likely have exceptions. Simply seeking or worse, enforcing consistency is a sure-fire way to slow the team down, squash innovation and reduce learning opportunities.
5. Don’t forget about the current architectural state
It can be useful to model a target architecture based on agreed principles and in collaboration with engineers (see #1 and #3 above). However, it must be founded in all the nuance and understanding of the current architecture. Anything else could lead towards a doomed rewrite, an unhappy team or a failed pitch to some confused engineers.
On a similar note, I’ve seen many conversations where stakeholders begin to assume the target state is in fact the current state. This can have significant downsides for the engineering team, for example; a sense of moving too slow, missed tasks that were presumed completed or a lack of appreciation upon completing a large chunk of technical work. Stakeholder discussions about target state may need to include regular reminders about the current state.
6. Don’t get too attached to the desired architecture
It can be easy to fall into the trap of attaching an opinion to your identity, particularly if you’ve got the task of providing a technical direction for an engineering team. New information and unforeseen circumstances will emerge, so any target state will 100% change. As these scenarios surface, you will need to keep an open mind to adapt your view and the direction. A fixed view will only hold back progress. As mentioned in #3, the architecture should be going through constant, incremental change.
7. Don’t let review processes stagnate
As an architect in a large organisation you are likely to be responsible for or actively involved in architectural and security review processes, either as a reviewer or seeking a review. These processes are often change approval reviews that give the green-light for a production release. They can be long and drawn out, unclear in their value, involve reviewers who have zero context, and result in unwanted or unnecessary outcomes; making them the perfect candidates for resisting change. As a more senior figure, an architect should be working hard against that intuition. They should seek to understand the purpose and value of the review process and relay it to others. They should be leading or guiding engineering teams through these processes, particularly for the first time. But most importantly, they should be constantly pushing to improve, reduce or potentially remove a review process depending on its purpose and added value.
There you have it! Hopefully I’ll learn even more things to avoid in future but for now, avoid these and you should be good; or at the very least better than a bunch of scenarios I’ve witnessed. For more advice on the topic of software architecture, check out these excellent reads too:
Full-stack developers are in fact stuck at mid-level. Spare yourself from suffering – don’t go down that path
Back in those times when I just started learning how to code, I trusted the old wise weasels with their “Programming languages don’t matter” mantra. I grew obsessed with the idea of some day becoming a developer who can do just anything. That guy who transfers his experience from one technology to another and transcends the minutia. But that idea failed miserably.
The obsession with knowing it all
I learned C# and .NET across different application domains (asp.net, wpf, xamarin), js/ts (react/redux, node) and convinced myself that I had the power to do anything I wanted. My thinking was abstracted, I was efficient in several programming paradigms at the same time, and I had practical skills in all aspects of professional software engineering. I was all set for ridiculing those 40-something seniors with their addiction to a single technology, who had spent half their life to fathom what I could grasp in a week’s time. I was close to declaring that going deep into some knowledge domain was for morons who were happy to have the same job for the rest of their lives, whereas I was abstracted from it all.
I thought everything was just the same old thing, so I kind of saw a consistent pattern. Now when my job involved coding in some ludicrous Python, I would go, ‘Give me some time to have a quick read through the spec, and I’ll be all set to work with this shit at a senior level. Why, what complications could probably be there of the kind I haven’t seen before?’ And so I fell prey to the detail-neglection cult. Let juniors fiddle with the details, seeing that they are incompetent with abstraction.
Knowledge gaps are subtle and not immediately visible
I once cranked out a design based on abstract classes in TypeScript, and got ridiculed because apparently nobody does it this way in TypeScript. I certainly pretended that my colleagues were hopeless idiots. It used to help before, but that time it left me with a bad aftertaste.
Your reputation of a good developer can disguise your knowledge gaps both from your colleagues and yourself. You therefore are ignorant of an enormous number of critical specifics, but of course you can’t see them, exactly because you don’t know about them.
That’s when my bad streak started. Poof! I had no idea about the types of indexes in SQL. Bam! I forgot when I should call a static constructor in C#. Oops! I couldn’t implement IDisposable correctly without looking it up on Google. Oh, and I was trying to mutate the state of a react component.
I then suspected that my abstraction was not really working. That the types of technology I was dealing with were different after all and that details mattered. Each technical ecosystem has its own unique best practices. Your .NET experience won’t hurt when working with jvm, but it can’t replace it. My self-assessed skill of ‘having learned how to learn’ turned out a play of imagination. My learning speed was no faster than that of others. This realization came way too late.
My skill was just a bag of conflicting ideas — I was being torn apart with bits of knowledge from here and there. I did not automatically become a senior Jack-of-all-trades. Instead I became a multi-skilled mid-level developer, a laughing stock for 40-something seniors who had mastered one technology. Thus, I realized that choosing the path of full-stack was a mistake.
Beating myself up about it
The problem is, businesses need full-stack developers. No, not the imitations like me, but versatile seniors, the guys who have five years of experience in each of the full-stack technology under their belts.
However, these unicorns don’t exist, so businesses go for self-deception. They take a mediocre mid-level engineer who specializes in three big-time technologies and call him a senior full-stack developer. This job title turns the engineer into an impostor and serves as an inexhaustible source of an inferiority complex. Any ordinary developer who focuses on just one technology knows it better. Now I can admit to not being ready to collaborate on equal terms with people who are much better than me at something. Otherwise it’ll be a week before I’ll have beaten myself up to death.
Self-recrimination is a huge malady in our industry, but we cure it with the wrong remedy. We exchange proclamations of how we are superheroes surrounded by assholes. We deny such thing as senior devaluation, we keep saying we underestimate ourselves, we just need to throw away our humbleness and believe in our internal goddess of software development. We think we need to put on the arrogance hat and give the finger to anyone who has too little faith in us.
Well, we just need to acknowledge that development is hard not only to outsiders, but also to us. Not knowing about something at any given moment is OK. If you have a gap, it doesn’t mean you are worth any less and have to be expelled from the community.
But somewhere at the deepest level of self-reflection we are still beating ourselves up. Full-stack developers curse themselves for not having deep knowledge of technology. Single-discipline experts lament that they don’t have a broad range of skills.
Learning in breadth vs learning in depth
Here we have the same old dilemma: you can either learn in breadth or in depth, but not both at the same time. I noticed an interesting side effect: when you start learning a new technology, the old one seems less interesting. But in the IT world, if you don’t refresh your knowledge of technology within a year, it makes you obsolete.
If you want to keep being a full-stack developer, you will have to make yourself read through the release notes of some TypeScript, testing all of that as you read, even if you don’t feel like it. Still, you will be miles away from a developer who codes everyday specifically in TypeScript.
The major problem of this conflict is that we have no idea of what’s best. We, and especially businesses, want it both ways. To have everyone have the right, in-depth skills.
I don’t know what’s best, but I know how it feels from the standpoint of a full-stack developer. You will spend much more time learning, compared to single-language developers. This will go on as long as your career lasts, and still you’ll lack their level of proficiency.
You will be welcome everywhere, but nowhere really at home. Despite your enormous efforts, every guru of the next big thing will foam at the mouth claiming you are not worth to be called a senior.
You will be stuck at mid-level for ever.
I for one decided to stick to my path. I could try learning something really in-depth, I could retrain for management (the field where superficial knowledge is an industry standard), but I’ll rather stay the way I am and will endure suffering until I really learn everything about anything.
The Proven Path to Doing Unique and Meaningful Work
In June of 2004, Arno Rafael Minkkinen stepped up to the microphone at the New England School of Photography to deliver the commencement speech.
As he looked out at the graduating students, Minkkinen shared a simple theory that, in his estimation, made all the difference between success and failure. He called it The Helsinki Bus Station Theory.
The Helsinki Bus Station Theory
Minkkinen was born in Helsinki, Finland. In the center of the city there was a large bus station and he began his speech by describing it to the students.
“Some two-dozen platforms are laid out in a square at the heart of the city,” Minkkinen said. “At the head of each platform is a sign posting the numbers of the buses that leave from that particular platform. The bus numbers might read as follows: 21, 71, 58, 33, and 19. Each bus takes the same route out of the city for at least a kilometer, stopping at bus stop intervals along the way.”
He continued, “Now let’s say, again metaphorically speaking, that each bus stop represents one year in the life of a photographer. Meaning the third bus stop would represent three years of photographic activity. Ok, so you have been working for three years making platinum studies of nudes. Call it bus #21.”
“You take those three years of work to the Museum of Fine Arts in Boston and the curator asks if you are familiar with the nudes of Irving Penn. His bus, 71, was on the same line. Or you take them to a gallery in Paris and are reminded to check out Bill Brandt, bus 58, and so on. Shocked, you realize that what you have been doing for three years others have already done.”
“So you hop off the bus, grab a cab—because life is short—and head straight back to the bus station looking for another platform.”
“This time,” he said, “you are going to make 8×10 view camera color snapshots of people lying on the beach from a cherry picker crane. You spend three years at it and three grand and produce a series of works that elicit the same comment. Haven’t you seen the work of Richard Misrach? Or, if they are steamy black and white 8x10s of palm trees swaying off a beachfront, haven’t you seen the work of Sally Mann?”
“So once again, you get off the bus, grab the cab, race back and find a new platform. This goes on all your creative life, always showing new work, always being compared to others.”
“Stay on the Bus”
Minkkinen paused. He looked out at the students and asked, “What to do?”
“It’s simple,” he said. “Stay on the bus. Stay on the f*cking bus. Because if you do, in time, you will begin to see a difference.”
“The buses that move out of Helsinki stay on the same line, but only for a while—maybe a kilometer or two. Then they begin to separate, each number heading off to its own unique destination. Bus 33 suddenly goes north. Bus 19 southwest. For a time maybe 21 and 71 dovetail one another, but soon they split off as well. Irving Penn is headed elsewhere.”
“It’s the separation that makes all the difference,” Minkkinen said. “And once you start to see that difference in your work from the work you so admire—that’s why you chose that platform after all—it’s time to look for your breakthrough. Suddenly your work starts to get noticed. Now you are working more on your own, making more of the difference between your work and what influenced it. Your vision takes off. And as the years mount up and your work begins to pile up, it won’t be long before the critics become very intrigued, not just by what separates your work from a Sally Mann or a Ralph Gibson, but by what you did when you first got started!”
“You regain the whole bus route in fact. The vintage prints made twenty years ago are suddenly re-evaluated and, for what it is worth, start selling at a premium. At the end of the line—where the bus comes to rest and the driver can get out for a smoke or, better yet, a cup of coffee—that’s when the work is done. It could be the end of your career as an artist or the end of your life for that matter, but your total output is now all there before you, the early (so-called) imitations, the breakthroughs, the peaks and valleys, the closing masterpieces, all with the stamp of your unique vision.”
“Why? Because you stayed on the bus.”
Does Consistency Lead to Success?
I write frequently about how mastery requires consistency. That includes ideas like putting in your reps, improving your average speed, and falling in love with boredom. These ideas are critical, but The Helsinki Bus Station Theory helps to clarify and distinguish some important details that often get overlooked.
Does consistency lead to success?
Consider a college student. They have likely spent more than 10,000 hours in a classroom by this point in their life. Are they an expert at learning every piece of information thrown at them? Not at all. Most of what we hear in class is forgotten shortly thereafter.
Consider someone who works on a computer each day at work. If you’ve been in your job for years, it is very likely that you have spent more than 10,000 hours writing and responding to emails. Given all of this writing, do you have the skills to write the next great novel? Probably not.
Consider the average person who goes to the gym each week. Many folks have been doing this for years or even decades. Are they built like elite athletes? Do they possess elite level strength? Unlikely.
The key feature of The Helsinki Bus Station Theory is that it urges you to not simply do more work, but to do more re-work.
It’s Not the Work, It’s the Re-Work
Average college students learn ideas once. The best college students re-learn ideas over and over. Average employees write emails once. Elite novelists re-write chapters again and again. Average fitness enthusiasts mindlessly follow the same workout routine each week. The best athletes actively critique each repetition and constantly improve their technique. It is the revision that matters most.
To continue the bus metaphor, the photographers who get off the bus after a few stops and then hop on a new bus line are still doing work the whole time. They are putting in their 10,000 hours. What they are not doing, however, is re-work. They are so busy jumping from line to line in the hopes of finding a route nobody has ridden before that they don’t invest the time to re-work their old ideas. And this, as The Helsinki Bus Station Theory makes clear, is the key to producing something unique and wonderful.
By staying on the bus, you give yourself time to re-work and revise until you produce something unique, inspiring, and great. It’s only by staying on board that mastery reveals itself. Show up enough times to get the average ideas out of the way and every now and then genius will reveal itself.
Malcolm Gladwell’s book Outliers popularized The 10,000 Hour Rule, which states that it takes 10,000 hours of deliberate practice to become an expert in a particular field. I think what we often miss is that deliberate practice is revision. If you’re not paying close enough attention to revise, then you’re not being deliberate.
A lot of people put in 10,000 hours. Very few people put in 10,000 hours of revision. The only way to do that is to stay on the bus.
Which Bus Will You Ride?
We are all creators in some capacity. The manager who fights for a new initiative. The accountant who creates a faster process for managing tax returns. The nurse who thinks up a better way of managing her patients. And, of course, the writer, the designer, the painter, and the musician laboring to share their work out to the world. They are all creators.
Any creator who tries to move society forward will experience failure. Too often, we respond to these failures by calling a cab and getting on another bus line. Maybe the ride will be smoother over there.
Instead, we should stay on the bus and commit to the hard work of revisiting, rethinking, and revising our ideas.
In order to do that, however, you must answer the toughest decision of all. Which bus will you ride? What story do you want to tell with your life? What craft do you want to spend your years revising and improving?
How do you know the right answer? You don’t. Nobody knows the best bus, but if you want to fulfill your potential you must choose one. This is one of the central tensions of life. It’s your choice, but you must choose.
A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality.
Betteridge's Law of headlines is an adage that says any article with a headline or title that ends in a question mark can be summarized by "no". Those that know me would not doubt my desire to subvert such a law. But this article goes further than that - it subverts the question itself. The question assumes the common trade-off between quality and cost. With this article I'll explain that this trade-off does not apply to software - that high quality software is actually cheaper to produce.
Although most of my writing is aimed at professional software developers, for this article I'm not going to assume any knowledge of the mechanics of software development. My hope is that this is an article that can be valuable to anyone involved with thinking about software efforts, particularly those, such as business leaders, that act as customers of software development teams.
We are used to a trade-off between quality and cost
As I mentioned in the opening, we are all used to a trade-off between quality and cost. When I replace my smart phone, I can choose a more expensive model with faster processor, better screen, and more memory. Or I can give up some of those qualities to pay less money. It's not an absolute rule, sometimes we can get bargains where a high quality good is cheaper. More often we have different values to quality - some people don't really notice how one screen is nicer than another. But the assumption is true most of the time, higher quality usually costs more.
Software quality means many things
If I'm going to talk about quality for software, I need to explain what that is. Here lies the first complication - there are many things that can count as quality for software. I can consider the user-interface: does it easily lead me through the tasks I need to do, making me more efficient and removing frustrations? I can consider its reliability: does it contain defects that cause errors and frustration? Another aspect is its architecture: is the source code divided into clear modules, so that programmers can easily find and understand which bit of the code they need to work on this week?
These three examples of quality are not an exhaustive list, but they are enough to illustrate an important point. If I'm a customer, or user, of the software, I don't appreciate some of the things we'd refer to as quality. A user can tell if the user-interface is good. An executive can tell if the software is making her staff more efficient at their work. Users and customers will notice defects, particularly should they corrupt data or render the system inoperative for a while. But customers and users cannot perceive the architecture of the software.
I thus divide software quality attributes into external (such as the UI and defects) and internal (architecture). The distinction is that users and customers can see what makes a software product have high external quality, but cannot tell the difference between higher or lower internal quality.
At first glance, internal quality does not matter to customers
Since internal quality isn't something that customers or users can see - does it matter? Let's imagine Rebecca and I write an application to track and predict flight delays. Both our applications do the same essential function, both have equally elegant user interfaces, and both have hardly any defects. The only difference is that her internal source code is neatly organized, while mine is a tangled mess. There is one other difference: I sell mine for $6 and she sells hers for $10.
Since a customer never sees this source code, and it doesn't affect the operation of the app, why would anyone pay an extra $4 for Rebecca's software? Put more generally this should mean that it isn't worth paying more money for higher internal quality.
Another way I put this is that it makes sense to trade cost for external quality but it makes no sense to trade cost for internal quality. A user can judge whether they want to pay more to get a better user interface, since they can assess whether the user interface is sufficiently nicer to be worth the extra money. But a user can't see the internal modular structure of the software, let alone judge that it's better. Why pay more for something that has no effect? Since that's the case - why should any software developer put their time and effort into improving the internal quality of their work?
Internal quality makes it easier to enhance software
So why is it that software developers make an issue out of internal quality? Programmers spend most of their time modifying code. Even in a new system, almost all programming is done in the context of an existing code base. When I want to add a new feature to the software, my first task is to figure out how this feature fits into the flow of the existing application. I then need to change that flow to let my feature fit in. I often need to use data that's already in the application, so I need to understand what the data represents, how it relates to the data around it, and what data I may need to add for my new feature.
All of this is about me understanding the existing code. But it's very easy for software to be hard to understand. Logic can get tangled, the data can be hard to follow, the names used to refer to things may have made sense to Tony six months ago, but are as mysterious to me as his reasons for leaving the company. All of these are forms of what developers refer to as cruft - the difference between the current code and how it would ideally be.
A common metaphor for cruft is Technical Debt. The extra cost on adding features is like paying interest. Cleaning up the cruft is like paying down the principal. While it's a helpful metaphor, it does encourage many to believe cruft is much easier to measure and control than it is in practice.
One of the primary features of internal quality is making it easier for me to figure out how the application works so I can see how to add things. If the software is nicely divided into separate modules, I don't have to read all 500,000 lines of code, I can quickly find a few hundred lines in a couple of modules. If we've put the effort into clear naming, I can quickly understand what the various part of the code does without having to puzzle through the details. If the data sensibly follows the language and structure of the underlying business, I can easily understand how it correlates to the request I'm getting from the customer service reps. Cruft adds to the time it take for me to understand how to make a change, and also increases the chance that I'll make a mistake. If I spot my mistakes, then there's more time lost as I have to understand what the fault is and how to fix it. If I don't spot them, then we get production defects, and more time spend fixing things later.
My changes also affect the future. I may see a quick way to put in this feature, but it's a route that goes against the modular structure of the program, adding cruft. If I take that path, I'll make it quicker for me today, but slow down everyone else who has to deal with this code in future weeks and months. Once other members of the team make the same decision, an easy to modify application can quickly accumulate cruft to the point where every little change takes many weeks of effort.
Customers do care that new features come quickly
Here we see a clue of why internal quality does matter to users and customers. Better internal quality makes adding new features easier, therefore quicker and cheaper. Rebecca and I may have the same application now, but in the next few months Rebecca's high internal quality allows her to add new features every week, while I'm stuck trying chop through the cruft to get just a single new feature out. I can't compete with Rebecca's speed, and soon her software is far more featureful than mine. Then all my customers delete my app, and get Rebecca's instead, even as she's able to increase her price.
Visualizing the impact of internal quality
The fundamental role of internal quality is that it lowers the cost of future change. But there is some extra effort required to write good software, which does impose some cost in the short term.
A way of visualizing this is with the following pseudo-graph, where I plot the cumulative functionality of software versus the time (and thus cost) to produce it. For most software efforts, the curve looks something like this.
This is what happens with poor internal quality. Progress is rapid initially, but as time goes on it gets harder to add new features. Even small changes require programmers to understand large areas of code, code that's difficult to understand. When they make changes, unexpected breakages occur, leading to long test times and defects that need to be fixed.
Concentrating on high internal quality is about reducing that drop off in productivity. Indeed some products see an opposite effect, where developers can accelerate as new features can be easily built by making use of prior work. This happy situation is a rarer case, as it requires a skilled and disciplined team to make it happen. But we do occasionally see it.
The subtlety here is that there is a period where the low internal quality is more productive than the high track. During this time there is some kind of trade-off between quality and cost. The question, of course, is: how long is that period before the lines cross?
At this point we run into why this is a pseudo-graph. There is no way of measuring the functionality delivered by a software team. This inability to measure output, and thus productivity, makes it impossible to put solid numbers on the consequences of low internal quality (which is also difficult to measure). An inability to measure output is pretty common among professional work - how do we measure the productivity of lawyers or doctors?
The way I assess where lines cross is by canvassing the opinion of skilled developers that I know. And the answer surprises a lot of folks. Developers find poor quality code significantly slows them down within a few weeks. So there's not much runway where the trade-off between internal quality and cost applies. Even small software efforts benefit from attention to good software practices, certainly something I can attest from my experience.
Even the best teams create cruft
Many non-developers tend to think of cruft as something that only occurs when development teams are careless and make errors, but even the finest teams will inevitably create some cruft as they work.
I like to illustrate this point with a tale of when I was chatting with one of our best technical team leads. He'd just finished a project that was widely considered to be a great success. The client was happy with the delivered system, both in terms of its capabilities and its construction time and cost. Our people were positive about the experience of working on the project. The tech lead was broadly happy but confessed that the architecture of the system wasn't that good. I reacted with "how could that be - you're one of our best architects?" His reply is one familiar to any experienced software architect: "we made good decisions, but only now do we understand how we should have built it".
Many people, including more than a few in the software industry, liken building software to constructing cathedrals or skyscrapers - after all why do we use "architect" for senior programmers? But building software exists in a world of uncertainty unknown to the physical world. Software's customers have only a rough idea of what features they need in a product and learn more as the software is built - particularly once early versions are released to their users. The building blocks of software development - languages, libraries, and platforms - change significantly every few years. The equivalent in the physical world would be that customers usually add new floors and change the floor-plan once half the building is built and occupied, while the fundamental properties of concrete change every other year.
Dora studies on elite teams
The choice between quality and speed isn't the only choice in software development that makes intuitive sense, but is wrong. There is also a strong thread of thought that says there is a Bimodal choice between fast development, with frequent updates to a system, and reliable systems that don't break in production. That this is a false choice is proven by the careful scientific work in the State Of Dev Ops Report.
For several years they have used statistical analysis of surveys to tease out the practices of high performing software teams. Their work has shown that elite software teams update production code many times a day, pushing code changes from development to production in less than an hour. As they do this, their change failure rate is significantly lower than slower organizations so they recover from errors much more quickly. Furthermore, such elite software delivery organizations are correlated with higher organizational performance.
Given this level of change, software projects are always creating something novel. We hardly ever find ourselves working on a well-understood problem that's been solved before. Naturally we learn most about the problem as we're building the solution, so it's common for me to hear that teams only really best understand what the architecture of their software should be after they've spent a year or so building it. Even the best teams will have cruft in their software.
The difference is that the best teams both create much less cruft but also remove enough of the cruft they do create that they can continue to add features quickly. They spend time creating automated tests so that they can surface problems quickly and spend less time removing bugs. They refactor frequently so that they can remove cruft before it builds up enough to get in the way. Continuous integration minimizes cruft building up due to team members working at cross-purposes. A common metaphor is that it's like cleaning up work surfaces and equipment in the kitchen. You can't not make things dirty when you cook, but if you don't clean things quickly, muck dries up, is harder to remove, and all the dirty stuff gets in the way of cooking the next dish.
High quality software is cheaper to produce
Summing all of this up:
Neglecting internal quality leads to rapid build up of cruft
This cruft slows down feature development
Even a great team produces cruft, but by keeping internal quality high, is able to keep it under control
High internal quality keeps cruft to a minimum, allowing a team to add features with less effort, time, and cost.
Sadly, software developers usually don't do a good job of explaining this situation. Countless times I've talked to development teams who say "they (management) won't let us write good quality code because it takes too long". Developers often justify attention to quality by justifying through the need for proper professionalism. But this moralistic argument implies that this quality comes at a cost - dooming their argument. The annoying thing is that the resulting crufty code both makes developers' lives harder, and costs the customer money. When thinking about internal quality, I stress that we should only approach it as an economic argument. High internal quality reduces the cost of future features, meaning that putting the time into writing good code actually reduces cost.
This is why the question that heads this article misses the point. The "cost" of high internal quality software is negative. The usual trade-off between cost and quality, one that we are used to for most decisions in our life, does not make sense with the internal quality of software. (It does for external quality, such as a carefully crafted user-experience.) Because the relationship between cost and internal quality is an unusual and counter-intuitive relationship, it's usually hard to absorb. But understanding it is critical to developing software at maximum efficiency.
What makes a great leader? Management theorist Simon Sinek suggests, it's someone who makes their employees feel secure, who draws staffers into a circle of trust. But creating trust and safety -- especially in an uneven economy -- means taking on big responsibility.
There's a man by the name of Captain William Swenson who recently was awarded the congressional Medal of Honor for his actions on September 8, 2009.
On that day, a column of American and Afghan troops were making their way through a part of Afghanistan to help protect a group of government officials, a group of Afghan government officials, who would be meeting with some local village elders. The column came under ambush, and was surrounded on three sides, and amongst many other things, Captain Swenson was recognized for running into live fire to rescue the wounded and pull out the dead. One of the people he rescued was a sergeant, and he and a comrade were making their way to a medevac helicopter.
And what was remarkable about this day is, by sheer coincidence, one of the medevac medics happened to have a GoPro camera on his helmet and captured the whole scene on camera. It shows Captain Swenson and his comrade bringing this wounded soldier who had received a gunshot to the neck. They put him in the helicopter, and then you see Captain Swenson bend over and give him a kiss before he turns around to rescue more.
I saw this, and I thought to myself, where do people like that come from? What is that? That is some deep, deep emotion, when you would want to do that. There's a love there, and I wanted to know why is it that I don't have people that I work with like that? You know, in the military, they give medals to people who are willing to sacrifice themselves so that others may gain. In business, we give bonuses to people who are willing to sacrifice others so that we may gain. We have it backwards. Right? So I asked myself, where do people like this come from? And my initial conclusion was that they're just better people. That's why they're attracted to the military. These better people are attracted to this concept of service. But that's completely wrong. What I learned was that it's the environment, and if you get the environment right, every single one of us has the capacity to do these remarkable things, and more importantly, others have that capacity too. I've had the great honor of getting to meet some of these, who we would call heroes, who have put themselves and put their lives at risk to save others, and I asked them, "Why would you do it? Why did you do it?" And they all say the same thing: "Because they would have done it for me." It's this deep sense of trust and cooperation. So trust and cooperation are really important here. The problem with concepts of trust and cooperation is that they are feelings, they are not instructions. I can't simply say to you, "Trust me," and you will. I can't simply instruct two people to cooperate, and they will. It's not how it works. It's a feeling.
So where does that feeling come from? If you go back 50,000 years to the Paleolithic era, to the early days of Homo sapiens, what we find is that the world was filled with danger, all of these forces working very, very hard to kill us. Nothing personal. Whether it was the weather, lack of resources, maybe a saber-toothed tiger, all of these things working to reduce our lifespan. And so we evolved into social animals, where we lived together and worked together in what I call a circle of safety, inside the tribe, where we felt like we belonged. And when we felt safe amongst our own, the natural reaction was trust and cooperation. There are inherent benefits to this. It means I can fall asleep at night and trust that someone from within my tribe will watch for danger. If we don't trust each other, if I don't trust you, that means you won't watch for danger. Bad system of survival.
The modern day is exactly the same thing. The world is filled with danger, things that are trying to frustrate our lives or reduce our success, reduce our opportunity for success. It could be the ups and downs in the economy, the uncertainty of the stock market. It could be a new technology that renders your business model obsolete overnight. Or it could be your competition that is sometimes trying to kill you. It's sometimes trying to put you out of business, but at the very minimum is working hard to frustrate your growth and steal your business from you. We have no control over these forces. These are a constant, and they're not going away.
The only variable are the conditions inside the organization, and that's where leadership matters, because it's the leader that sets the tone. When a leader makes the choice to put the safety and lives of the people inside the organization first, to sacrifice their comforts and sacrifice the tangible results, so that the people remain and feel safe and feel like they belong, remarkable things happen.
I was flying on a trip, and I was witness to an incident where a passenger attempted to board before their number was called, and I watched the gate agent treat this man like he had broken the law, like a criminal. He was yelled at for attempting to board one group too soon. So I said something. I said, "Why do you have treat us like cattle? Why can't you treat us like human beings?" And this is exactly what she said to me. She said, "Sir, if I don't follow the rules, I could get in trouble or lose my job." All she was telling me is that she doesn't feel safe. All she was telling me is that she doesn't trust her leaders. The reason we like flying Southwest Airlines is not because they necessarily hire better people. It's because they don't fear their leaders.
You see, if the conditions are wrong, we are forced to expend our own time and energy to protect ourselves from each other, and that inherently weakens the organization. When we feel safe inside the organization, we will naturally combine our talents and our strengths and work tirelessly to face the dangers outside and seize the opportunities.
The closest analogy I can give to what a great leader is, is like being a parent. If you think about what being a great parent is, what do you want? What makes a great parent? We want to give our child opportunities, education, discipline them when necessary, all so that they can grow up and achieve more than we could for ourselves. Great leaders want exactly the same thing. They want to provide their people opportunity, education, discipline when necessary, build their self-confidence, give them the opportunity to try and fail, all so that they could achieve more than we could ever imagine for ourselves.
Charlie Kim, who's the CEO of a company called Next Jump in New York City, a tech company, he makes the point that if you had hard times in your family, would you ever consider laying off one of your children? We would never do it. Then why do we consider laying off people inside our organization? Charlie implemented a policy of lifetime employment. If you get a job at Next Jump, you cannot get fired for performance issues. In fact, if you have issues, they will coach you and they will give you support, just like we would with one of our children who happens to come home with a C from school. It's the complete opposite.
This is the reason so many people have such a visceral hatred, anger, at some of these banking CEOs with their disproportionate salaries and bonus structures. It's not the numbers. It's that they have violated the very definition of leadership. They have violated this deep-seated social contract. We know that they allowed their people to be sacrificed so they could protect their own interests, or worse, they sacrificed their people to protect their own interests. This is what so offends us, not the numbers. Would anybody be offended if we gave a $150 million bonus to Gandhi? How about a $250 million bonus to Mother Teresa? Do we have an issue with that? None at all. None at all. Great leaders would never sacrifice the people to save the numbers. They would sooner sacrifice the numbers to save the people.
Bob Chapman, who runs a large manufacturing company in the Midwest called Barry-Wehmiller, in 2008 was hit very hard by the recession, and they lost 30 percent of their orders overnight. Now in a large manufacturing company, this is a big deal, and they could no longer afford their labor pool. They needed to save 10 million dollars, so, like so many companies today, the board got together and discussed layoffs. And Bob refused. You see, Bob doesn't believe in head counts. Bob believes in heart counts, and it's much more difficult to simply reduce the heart count. And so they came up with a furlough program. Every employee, from secretary to CEO, was required to take four weeks of unpaid vacation. They could take it any time they wanted, and they did not have to take it consecutively. But it was how Bob announced the program that mattered so much. He said, it's better that we should all suffer a little than any of us should have to suffer a lot, and morale went up. They saved 20 million dollars, and most importantly, as would be expected, when the people feel safe and protected by the leadership in the organization, the natural reaction is to trust and cooperate. And quite spontaneously, nobody expected, people started trading with each other. Those who could afford it more would trade with those who could afford it less. People would take five weeks so that somebody else only had to take three.
Leadership is a choice. It is not a rank. I know many people at the seniormost levels of organizations who are absolutely not leaders. They are authorities, and we do what they say because they have authority over us, but we would not follow them. And I know many people who are at the bottoms of organizations who have no authority and they are absolutely leaders, and this is because they have chosen to look after the person to the left of them, and they have chosen to look after the person to the right of them. This is what a leader is.
I heard a story of some Marines who were out in theater, and as is the Marine custom, the officer ate last, and he let his men eat first, and when they were done, there was no food left for him. And when they went back out in the field, his men brought him some of their food so that he may eat, because that's what happens. We call them leaders because they go first. We call them leaders because they take the risk before anybody else does. We call them leaders because they will choose to sacrifice so that their people may be safe and protected and so their people may gain, and when we do, the natural response is that our people will sacrifice for us. They will give us their blood and sweat and tears to see that their leader's vision comes to life, and when we ask them, "Why would you do that? Why would you give your blood and sweat and tears for that person?" they all say the same thing: "Because they would have done it for me." And isn't that the organization we would all like to work in?
