The Five Ideals of a Great Software Engineering Environment

The First Ideal: Locality and Simplicity

• Locality: Things need to be centralized. People need to know where to find them. They need to all be in one place.
  • Locality in code keeps things loosely coupled
  • Locality in organizations means teams don’t have to coordinate with other teams or other organizations as much. Those people don’t understand their code as well as they do
• Simplicity: Make sure everything is easy to understand
  • Simplicity helps achieve locality
• Simplicity and Locality help teams independently and quickly develop, test, and deploy their changes
• Keeping things loosely coupled allows teams to work independently and quickly
• Technical Debt makes leads to complexity (which is the opposite of locality and simplicity)

The Second Ideal: Focus, Flow, and Joy

• “It’s all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy.”
• You need a build process that enables fast and frequent feedback

The Third Ideal: Improvement of Daily Work

• “…we must elevate improvement of daily work over daily work itself.”
• ““You may have to change old rules that no longer apply, change how you organize your people and architect your systems,” he continues. “For the leader, it no longer means directing and controlling, but guiding, enabling, and removing obstacles.”

The Fourth Ideal: Psychological Safety

• “…make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety.”
• Ask “What caused the problem?” not “Who caused the problem?
• Problems should be looked at as learning opportunities
• “The leader must constantly model and coach and positively reinforce these desired behaviors every day. Psychological safety slips away so easily, like when the leader micromanages, can’t say ‘I don’t know,’ or acts like a know-it-all, pompous jackass. And it’s not just leaders, it’s also how one’s peers behave.””

The Fifth Ideal: Customer Focus

• “The Fifth Ideal is about a ruthless Customer Focus, where you are truly striving for what is best for them, instead of the more parochial goals that they don’t care about, whether it’s your internal plans of record or how your functional silos are measured… Instead we ask whether our daily actions truly improve the lives of our customer, create value for them, and whether they’d pay for it. And if they don’t, maybe we shouldn’t be doing it at all.”

The 3 Horizons of a Business

You need to devote resources to working on each of these Horizons.

Horizon 1: This horizon is where you are trying to maintain what your company is currently know for. It’s what earns your revenue. Everything is well know and predictable. It has loyal customers.

Horizon 2: This horizon is where you are trying to establish the future of your company (introducing new capabilities to customers, exploring new markets, trying different business models, etc.). You’re developing growth areas.

Horizon 3: This horizon is where you learn and experiment at the bleeding edge. Learn, experiment, and try new things as fast as possible. Make prototypes and figure out what is worth spending your time on. Abandon things quickly that aren’t promising. If something is worth spending time on then it becomes part of Horizon 2 efforts.

Core vs Context

• Core: What your organization is good at and what your customers pay you for
• Context: Every else (HR, payroll, email, cafeterias, bathroom services, etc.)
• Companies often underinvest in their Core because they are being controlled by Context
• Context is important and often “mission-critical” but make sure you manage it and remember that your Core is the most important

Technical Debt

• Technical debt is things you need to clean up or improve. It happens because developers trade off being fast for doing things very thoroughly. Sometimes being fast and “slapping a band aid on it” is necessary
• Pay down technical debt as a part of daily work
• Almost every tech giant has been almost killed by technical debt and they’ve had to do feature freezes to dig themselves out of it
• If a developer has to choose between a new feature and security, they should choose security
• If a developer has to choose between a new feature and developer productivity, they should choose developer productivity

You Need A Build Process for Fast and Frequent Feedback

• Developers need feedback – “Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else’s.”
• “Everyone around here thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.”
• “…developers need a system where they can get fast and continual feedback on the quality of their work. If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes that every other developer made, so the link between cause and effect disappears without a trace.”
• “…getting builds going again is one of the most urgent and important engineering practices we need right now. Once we get continuous builds going, we enable automated testing. We get automated testing, we can make changes quicker, with more confidence, and without having to depend on hundreds of hours of manual testing. And that, I believe, is the critical first step for how we can deliver better value, safer, faster, and happier.”
• “Being able to test and push code to production is more productive, makes for happier customers, creates accountability of code quality to the people who write it, and also makes the work more joyful and rewarding.”

Maxine Character Analysis

Maxine is an all-star developer so it’s worth looking at what her thoughts and perspectives are on software development.

• “She loves her work and all the challenges; she loves interacting with the countless and complex business processes that span the entire company—it requires an understanding of the business, incredible problem-solving skills, patience, and the political sophistication to work with sometimes Byzantine and occasionally incomprehensible processes that every large organization seems to have.”
• She wants to be useful and provide value – She asks “What can I contribute?”
• She reads the source code; She reads all the documentation that she can find
• “She’s a developer who loves functional programming because she knows that pure functions and composability are better tools to think with. She eschews imperative programming in favor of declarative modes of thinking. She despises and has a healthy fear of state mutation and non-referential transparency. She favors the lambda calculus over Turing machines because of their mathematical purity. She loves LISPs because she loves her code as data and vice versa. But hers is not merely a theoretical vocation—she loves nothing more than getting her hands dirty, creating business value where none thought it could be extracted, applying the strangler pattern to dismantle decades-old code monoliths and replacing them safely, confidently, and brilliantly. She is still the only person who knows every keyboard shortcut from vi to the latest, greatest editors. But she is never ashamed to tell anyone that she still needs to look up nearly every command line option for Git—because Git can be scary and hard!”
• She keeps an organized list of To-Do Items
• She shoulder surfs other people to learn how things work; She does pair programming
• She keeps a daily work diary to track what she’s worked on and lessons learned
• She keeps a list of things she doesn’t understand so that she can learn about them when she has time
• “A great day is when she’s solving an important business problem. Time flies by because she’s so focused and loving the work. She’s in a state of flow, to the point where it doesn’t feel like work at all. A bad day is spent banging her head against a monitor, scouring the internet for things she doesn’t even want to learn but needs to in order to solve the problem at hand.”
• She reads the glob of build output as her programs are executing (for hours if necessary)

Miscellaneous Notes

• “Punishing failure and “shooting the messenger” only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.”
• “Creating software should be a collaborative and conversational endeavor—individuals need to interact with each other to create new knowledge and value for the customer.”
• Many good engineers are always drawn away from IT so they can work on feature work that actually impacts customers instead of “boring infrastructure”
  • “Infrastructure is messy work, almost the opposite of the pure functional programming she loves—in infrastructure, almost everything you do has a side-effect that mutates the state of something in the environment, making it difficult to isolate and test changes, as well as diagnose problems when things go wrong.”
• Making developers productive is very important
  • “Maxine loves coding and she’s awesome at it. But she knows that there’s something even more important than code: the systems that enable developers to be productive, so that they can write high-quality code quickly and safely, freeing themselves from all the things that prevent them from solving important business problems.”
  • Developers should be able to focus on building features and not getting builds to work
• Developers should use a common set of tools
• Being busy is not the same thing as being productive and useful
• “…coding is a proficiency that every profession is likely to need in the next decade. It won’t be just for developers anymore.”
  • “…this is the Age of Software. Almost all business investment now involves software. And that means we must elevate developer productivity…”
• Watermelon Project: A project that’s marked as good (green on the outside) but on the inside it’s actually a mess (red)
• “Every developer uses a common build environment. Every developer is supported by a continuous build and integration system. Everyone can run their code in production-like environments. Automated test suites are built to replace manual testing, liberating QA people to do higher value work. Architecture is decoupled to liberate feature teams, so developers can deliver value independently. All the data that teams need is put in easily consumed APIs.”
• Frequent Code Merges
  • “Maxine loves it when everyone merges their changes frequently to the ‘master branch,’ such as once per day. That way, the size of the changes being merged are never allowed to get too large. Small batch sizes, like in manufacturing, create a smooth flow of work, with no jarring disruptions or catastrophes.”
• Developers should be able to push their own changes to production. A doctor doesn’t ask someone else to examine the patient
• Developers should be responsible for testing their own code
• There needs to be automated testing
  • The tests should run after every code check-in
• Docker containers are a good way to give developers their own coding environments for testing locally
• Product managers should work closely with engineers. This also helps the engineers learn the business domain