If the code is created by an open source community, or something else that is done outside of the ordinary work, things are different. For a team working with the code in a professional setting, asynchronous code reviews should be something to avoid.
A traditional code review has two major purposes. The first is to make sure that the code behave as intended. There are alternative ways to achieve this. You can work in pairs or an ensemble. A test first approach, with a good knowledge in test coverage design, might also help with this.
The second purpose is to maintain code quality over time. This is impossible for a team that lack refactoring skills, regardless of how well code is reviewed. Perhaps it works for a product in an environment that never changes, but then code quality will also be less important. So the team will need to know how to change production code in a safe and effective way. With that knowledge, you can review code that is important, instead of code that is new.
The important code is the areas in the production code where a lot of changes happen. You can then, as a team, look at the code and find ways to change it, so that it is easier to work with. That will improve the software design skills of the entire team.
To become a high achieving software team you will need the same skills that make asynchronous code reviews unnecessary. So try to ease them out if you can. If you don’t feel safe to let code go into production without a review step, make sure to only focus on functionality (or what regulations demand). Have a linter in place that checks things like formatting as a pre-commit hook. If the code quality is so low that it hurts to put the code in production, that developer should not work alone. It is harder to teach software skills through a written review than in person.
Save the review energy for the high stake parts of the system, and go through it as a team. Then you make sure that the knowledge from the entire team is used, and shared, and that everyone is onboard with the results.
When the code never has to wait for someone else to get into production, then you can create value really fast.
]]>If we want people to learn new things, collaborate with an open heart, and challenge the limits of their capacity, we do that by creating a safe and nurturing place for them.
The way out of the comfort zone is to have a comfort zone to start with. Make people feel so safe that they get bored and start creating, so cherished that they dare make a fool of themselves, and so relaxed that all energy go into the task at hand.
]]>FullStack is about what kind of software you are comfortable writing. Where the stack starts and ends depend on who you are asking. It includes at least two layers of software.
DevOps is about what parts of the software lifecycle you are comfortable with. The requirement is that you see it through at least until it brings value to the end user.
You can be a mobile app developer and do DevOps, as long as your responsibility includes the distribution of the app, and that is all that is required for it to reach the user.
You can be fullstack and not do DevOps, if you let go of the code as soon as your feature is implemented.
If you, and your team, are responsible for development and operations, that is DevOps.
]]>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
We also know from the DORA DevOps report that we want loosely coupled code. The SOLID principles can help us write code that has high cohesion and low coupling. I think we can translate those to work for organizations as well, and see how we can help the code be flexible through how we work.
There should never be more than one reason for a class to change.
This is really about stakeholders. (See this blogpost for more on how it works in code.)
Aim for as few stakeholders as possible for a team
The stakeholder can be internal or external.
(I expand on what to do to achieve this in another post.)
Software entities … should be open for extension, but closed for modification.
We want change to happen where it makes sense and only when needed. For organizations we get there by team design.
Create small, long term, self sufficient teams that collaborate.
Teams get better with time.
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
How something is solved can change, and you should not have to care about it. The design of the base class helps us find the purpose of the object from the user perspective.
Internal services are internal products
Create internal services as if they would be sold to external customers. We want each part of the system to have a clear purpose and each team to have independent pacing of their work. It also makes it possible to swap it for “off the shelf”-solutions if the service is no longer a part of the competitive edge. (And let the team take on a new project.)
Clients should not be forced to depend upon interfaces that they do not use.
We don’t want code to be weighed down by conforming to rules that does not apply to it. The same is true for teams.
Let each team own their process.
There can not be one flavour of agile in a big company. Instead, each team should be provided with the time and expertise to learn how to improve their own work. Be clear with desired outcomes and core values, let the team do the rest.
Depend upon abstractions, not concretions.
This is about integrity.
No micro management.
Give the team one stakeholder and the capabilities they need to fill one purpose for that stakeholder, then trust them.
]]>There is code like this, frameworks that infiltrate the domain code until they are inseparable. Change one part and it affects all of it. You are never safe to move. Bad habits of the team that designed the framework will seep into the code base. (Regardless if the framework is external or developed alongside the domain logic.) Getting free takes time. Approval tests and safe refactoring are the flamethrowers that can save us.
To avoid this anti-pattern, keep your frameworks at arms length. Isolate code that is framework specific from your domain logic. Use interfaces! Hexagonal design (ports and adapters) can be used for this.
A bonus is that the code will be testable. Frameworks are good at side effects. Let them deal with that. The domain code is then easy to put in unit tests.
If the framework is not working for you, or is updated, make sure the interface is preserved and the change is mostly done. It won’t even make your nose bleed.
]]>Code that has a limited responsibility, with only one stakeholder. Objects and functions that can be part of composition, without being altered. Interactions designed to work even if the implementation details of one actor changes. They will all likely result in code that has not been touched or altered for a very long time. The code is still in use, but as “done” as code ever gets.
It is a blessing when code is allowed to grow stale. We should design our code so that it can slowly sediment, harden by itself, in the peace good design and proper testing creates. The codebase as a whole will still evolve, and that is going fast. Changes to support the business are quickly done in small units with good interfaces. Sometimes a bigger part is swapped out. In other cases, an old trustworthy part is promoted into a library. There is movement where it is needed, but the ripple effects don’t reach far.
When I hear about code freeze or software hardening as part of a delivery pipeline, I think about the aging and maturing of code. With small units of decoupled and well tested code, it will naturally harden. Some files will be created, used for days or decades, and then deleted, without ever being changed. Others will have an eventful youth, but soon settle into being run, but not altered. For me, that is the goal, letting the legacy of code create a solid foundation for new work.
What do you have to change to let your code age in peace?
]]>The first time I heard of Westrum organisational culture I misheard it as “Restroom Culture”. I thought it was a way to tell company culture by looking at shared facilities. It turned into a neat mnemonic, so now I bring you the explanation of the three organisational cultures of Westrums, using restrooms. Hopefully, though a bit silly, it will help you remember the real name, as well as the concept. What kind of culture do you work in?
No one dares to use up the last square of toilet paper. That person will be punished and might even be fired. The storage is locked, some few select have a key. If you are friendly with someone who has access to extra toilet paper you might get a fresh roll. But first you have to find out who those people are, and how to suade them. No one dares to mention that it might be wasteful to limit access to toilet paper. The last one who brought up the subject was first publicly blamed for all restroom related problems and then let go. Some people bring their own rolls, but in secret, so that it won’t be taken for critique.
Toilet paper is refilled Tuesdays and Thursdays. If it runs out any other day there is a form to fill out that heed approval from your bosses boss. Any suggestion to change this will be ignored. Employees are not trusted with important things like toilet paper.
Toilet paper is stored where everyone has access to it. If it runs low anyone who notices takes action. There is also a supply of sanitary products available in all restrooms, as a result of an employee initiative.
]]>You think because you understand ‘one’ you must also understand ‘two’, because one and one make two. But you must also understand ‘and’.
DevOps is Dev and Ops. For something to be DevOps the team must do development. The same team has to run operations. In this an invisible ‘&’ gets created between Dev and Ops. This ‘&’ has value that can not be seperated from it joining Dev and Ops.
Getting unique value from putting responsibility for Dev and Ops in the same team can be hard to grasp. It is creating a new system with improved self organisation and evolution capabilities. This evolution and self organisation might manifest as a demand for new software, development practises or an interest in cloud services. But these are only side effects of the newly created ‘&’. Don’t mistake a continues integration server for DevOps.
Some want the ‘&’ that this change brings to life to be bottled and sold on its own.
We see software marketed as DevOps. Or a service as DevOps. “Let us do your DevOps for you.”
Introducing external dependencies, and thereby removing agency for the team, damages the very ‘&’ it is confused with.
You can’t sell love, company culture, life, ‘rainforestness’ or any other ‘&’ from systems we have around us.
DevOps can only be created by letting one team have responsibility for dev, ops and everything else that is needed for software to bring value.
]]>The point of DevOps is that the responsibility for development, operations and maintenance of an application, should be on the same team. Everyone does DevOps, and no one does DevOps. It is a way of working that eliminates the hand-offs by saying that writing and running the code is part of the same job.
To enable DevOps there are a lot of tools for things like continuous delivery. The tools themselves are sometimes confused with DevOps as a concept. But you can use all of them without getting the benefits of DevOps. Likewise, no cloud service, containerisation tool or build system is needed to do DevOps. Everything that is needed is in the statement “Everyone is both a developer and does operations.” (The separation is not to be compared with Luther’s saint vs. sinner as more than a conceptual similarity.)
It is dangerous to believe DevOps to be either a role, a team or a toolset. One of the effects might be to overlook the changes needed in the Dev part of DevOps. In the DORA DevOps report automated tests, trunk based development and loosely coupled architecture is listed next to deployment automation and cloud (page 31 is my favourite). Writing tests, using version control systems and design code is clearly a dev thing. Those skills are as important as setting up a build pipeline or containers that run in the cloud. If you just take a team of developers, and add someone who knows the toolchain for DevOps, you might oversee the need for training in other technical skills, such as TDD.
Another trap is that if you still have one person in the team responsible for getting the code into production, and taking care of the new shiny tools, not much have changed. You have only created a mini ops team within the dev team. The end goal is about shared responsibility and a holistic view on the lifecycle of a feature, and that needs to include everyone.
So the next time someone talks about DevOps as a person, a role, a team or a tool chain, remember your favourite self contradiction. I will think about Saint Luther doing a diet plan for intuitive eating.
ps
If you find any examples I have not listed, please share them in the comments or on Twitter @edytterbrink. If anyone comes up with a nice hashtag I will edit and add it here.
]]>Around 1847 Ignaz Semmelweis discovered that washing the hands before delivering babies had the death rate of mothers go from 18% to 1.3%. Semmelweis died in an asylum in 1865. It is said that the cause was a nervous breakdown as a result of his discovery being met with such hostility in the medical community. Doctors got offended by the idea that they could cause infection. It was first in the 1870s that doctors began systematically washing before surgery. That is a lot of death.
The DORA DevOps report from 2019 connects success factors and practises to lower risk of burnout. We have scientific based research showing how to save lives among the workers in our industry. The only thing we need to do is to adapt the ways of work, and learn the skills, that will also make us more profitable. Still only one in five of the companies responding took full advantage of things that are available today. Many companies do not even know about this research.
So if you have ever listened to a story like the one about Semmelweis and thought about how stupid people used to be who hung on to theories about body fluids in balance and a geocentric world view, I have one thing to say to you: Read the DevOps report and wash your hands.
ps.
]]>One parallel between tidy software and a tidy home is about identity. What life do we imagine is possible for us?
The KonMari method for tidying your home talks about the importance of imagining where you want to end up. When you are done with the KonMari method your home “go click”. Then you have changed as a person and will never relapse into messiness again. (You will still need to clean, but it will be much easier.)
So first you get to dream up the life you want to live, get the tools to achieve it and grow into a person who can maintain it. Each step of the KonMari journey is a part of that transformation.
There are software developers thinking that Test Driven Development is a unicorn, that everyone dream of but no-one has really seen. Software deteriorate, even rot, over time, it is said. People see it as inevitable, at least for them. The role models for quality code in real projects are few. That makes it harder to know what we could experience if things were better. Still the DORA DevOps report shows us that there is a real differentiation in the industry. The gap is not only between the highest and the lowest performing teams. Some move quicker than all of the rest and get better results. But do we believe we could be like them?
We need to start dreaming about excellence. Our identity has to shift to encompass the belief that software can be written differently than it is today. It might hurt to think of all the pain we suffered before, when we learn a skill that makes our life easier. It might be scary to imagine all the business decisions we need to make when the technology is no longer holding us back. I was once afraid of a clean kitchen counter, since it left me without something obvious to blame for … anything actually. But we can not let fear hold us back!
Just doing more of the same we have always done won’t work either. Getting rid of one item of clothing every day for December won’t change our buying habits more than any other such challenge. The clutter comes from how we relate to ourselves, each other and our belongings. The same goes for our code. And just as Marie Kondo also teaches folding, organising and storing, there are concrete skills to learn that make writing tidy code easier. But it has to come with a shift in perspective on improvement. It is not about remembering to write unit tests, it is about learning how to test drive code so that the architecture improve. We do not simply have to remember to document the code, instead it is about how we see carrying domain information as a part of the codes purpose. There is a difference between cleaning more often and creating structural change to make cleaning easier. It still does not require a rewrite of the entire codebase, or you moving to a new home, but we need to do something else than what has failed before.
To know what we are aiming for we need to dare to imagine a world where writing code is fun and pain free. We need to believe that we can be part of such a world. Then it will be easier to learn and grow so that we can reach that goal. In contrast to KonMari, best done alone, changing how we write software is a team, community and industry effort. We need a bigger dream, of a brighter future, and believe that we can get there. Please join me!
ps. My home still has some way to go before it “go click” but I will re-read Spark Joy by Marie Kondo to get back on track.
]]>That is a bold statement and it comes from recognising three different levels of limitations to our productivity.
In 1956 the cost of 30 hours of console time was the same as for a full year of a software engineer. That has shaped our entire industry since then. In Production of large computer programs Benington describes one of the first software projects big enough to need a team. At this time the limitations in hardware defined how we wrote our software.
Some methods presented are very modern at their core. Benington describes both predefined tests for small units of code, parameter tests — today unit tests, and tests for the entire system, assembly tests — today system tests. To automate them and run them for every change of the code was financially impossible. Instead every test is clearly documented, not only to enable retesting but also to improve test design. The parameter tests were defined for every combination of inputs and outputs before starting to code.
In other words, a programmer must prove that he satisfied his specifications, not that his program will perform as coded.
(Actually, test specifications for one subprogram can be prepared in parallel with the coding.)– Benington in Production of large computer programs
You could stretch it so far as calling it Test Driven Development in spirit. Benington also describes the seed of our modern Integrated Development Environments (IDEs). The paper states about their development tools that its present size 40,000 machine instructions is indicative of the importance attached to its role. It really hit me how limiting it was to not have access to processing power when developing software in 1956. They knew what they needed, but the hard limitation in the technical tools made them take compensatory actions instead, like having designated teams for testing and operations.
In his Theory of Constraints Goldratt explains that we can not gain advantage from a technical advancement before we get rid of the compensatory actions we took to manage without it. I illustrate it with a story about a Sunday steak and a pot. The steak got its end cut off before it was put in the pot, since the recipe originated from an ancestor with a pot so small that no steak would fit without trimming it first. This waste was discovered first as one of the children asked the grandmother the magic word “why?” and the origin was uncovered. The limitations originating in our old compensatory actions can be tricky. How do we know what things that used to enable us, actually hinder us today? We need to find and discard them before we can benefit from new and better ways of working.
When we rid ourselves of old ways of working, no longer needed with new tools, how do we gain proficiency in the new technology? Not everything has such an intuitive interface as a slightly larger pot. I use IDEs that the developers in 1956 could only dream of, but they are only useful if you learn what they can do. Modern version control systems create an opportunity for collaboration that turns silos into networks and enable us to explore and experiment in a way not possible before, if we know how to. Test driving software for evolutionary design is a skill needed, now that developers can be trusted with using a computer. So is continuous delivery a capability required as software changes faster for longer, now that updates are no longer delivered with a person traveling to install it for you.
Developers need to utilise the technical advances we have made since 1956. For a long time we have stuck with the practises Benington and others developed to survive in an era where computing was extremely expensive. Instead of holding on to processes they adapted out of necessity, I want us to look at the dream that shines through the lines in that paper. There I see test driven development, continuous delivery, static code checking, code in high level languages that is easy to read and then optimised by compilers, powerful IDEs and a lot more that we have today. This generation has the tools to get all the smart people working together on hard problems, while letting the computers do the boring repetitive stuff. But the DORA’s devops report shows that far from everyone make use of the technical advancements. I believe that all the listed limitations have a hand in that. The world needs better software, and I somehow feel that I owe it to those who walked before me to use the tools I have, but they only dreamed of.
To recap, look around you and see if you spot the same limitations as I do:
Next time your are frustrated over your working environment consider where we are and how we got here. There is a lot of prestige related to proficiency in the software industry. We can’t keep the old limitations just to avoid admitting our need to learn new skills. Instead, take an action to change it for the better. Remove something compensatory that is not longer needed, or learn a new skill to leverage the tools available. No individual developer is to blame that it ended up like this. We need support each other to get out of it.
A version of this text was previously published on LinkedIn.
]]>