How do you know if you are working in the “Good Software World”?
When I first joined Nulogy, the terms “Good Software World” and “Bad Software World” were tossed around as if there was some ubiquitous understanding in the industry as what determines if you are in a good or bad development environment.
This was a shock to me, as I’d never heard these sayings before. And I certainly wasn’t aware of what a “bad” environment was.
Over the next few months, I began to see what my colleagues were talking about. Meetings were well attended and participation was high. There were no overpowering voices or egos, and everyone’s opinion was valued equally. Iteration planning was controlled entirely by the team. And retrospectives were well facilitated and always produced ways to improve.
In time I realized that I had been working in the “Bad Software World” this whole time. It was a validating revelation; I had no idea how challenging my situation was until I joined a new company.
Then I thought that my former colleagues probably don’t know they are in a difficult environment. What if no one knew they were in that environment?
I felt motivated to create a list that can be used as at least one perspective on how the “Good Software World” could be. This is by no means a source of definitive truth, but instead are my opinions based on contrasting my experiences from different workplaces.
Continuous Delivery
Any developer who has felt the crunch of trying to get a feature in before a deployment cut off should be able to relate to this.
Continuous Delivery serves so many purposes that it could be its own article. In fact many of them do exist.
But I want to speak about why it’s important from a selfish developer perspective. First, it removes the pain of harsh deadlines to slam barely working code haphazardly into a release just so it can make the once-per-quarter deployment.
It also intrinsically removes all the hotfixes following that deployment because of that same code making it into a release.
More importantly, it forces small artifacts of code to continuously be sent to production. This means that there should never be huge code changes making it into a deployment. Instead, incremental changes go live providing more faith in the success of the deployments but also making it far easier to troubleshoot when things do go wrong.
Test Driven Development
Test Driven Development is a hard sell for a company. Won’t it slow us down? Cost more to Develop?
In the naive near-term, there may be a point to argue here. But anything mid to long term, in terms of a product, will always gain significantly from TDD.
Test Driven Development is a phenomenal tool for not just test coverage but for actually making your code better. It will identify code smells for you, as well as provide an extremely tight feedback loop while writing code.
Without these tests, how could you refactor a critical piece of code with confidence?
How many hotfixes do you do? How many bugs do you log that would be caught by a test? How much tech debt have you acquired that would otherwise be flagged by a test?
This blog isn’t about teaching TDD, but there are many others that are great. I keep coming back to this talk by Michael Feathers which highlights that there’s a lot more to TDD than just tests.
Why is TDD a signal of the “Good Software World”? It’s a good sign that there is executive buy-in to making quality a first class citizen of the engineering team.
Holocratic Teams
Being part of a small team, the smaller the better, without any management or leadership hierarchy may seem like an odd proposition. But it’s actually a powerful organizational tool to empower your team to take ownership of their affairs from inception to implementation.
Why is this so important?
- A small, holocratic team ensures everyone can collaborate as an equal
- Quick and relevant daily standups
- Ability to pair rotate with other developers without much context building
- Ability to take ownership as a team over a vertical slice of code, removing the need for upper management to consult on things like coding standards or business process
- Having a small team makes it easy to implement changes to continuously improve
You may be wondering how decisions get made if there’s no hierarchy. At Nulogy we employ process tools to empower teams to take ownership and contribute as equals:
- Core Protocols to assist us with making decisions as well as effectively working in a collaborative way.
- Delegation Poker from Management 3.0 to understand how much of a decision is owned solely by our team
These tools allow a clear recipe for working in autonomous, self-managed teams that clearly defines how decision making works.
Culture Through Learning
The developer landscape is continuously evolving. Just take a look at the innovation roller-coaster that is JavaScript.
Accepting that learning is an essential part of software development is paramount. If learning isn’t a first-class citizen of development, then your development will naturally stagnate at a certain level. This can be a rather de-motivational event and will contribute to the Dead Sea Effect.
More so, accepting learning as a priority can actually pay huge dividends to a company. Some of the most important tools in our development pipeline are a direct result of our frequent hack days which both encourages learning and embraces solving problems off the radar.
Learning doesn’t just mean new syntax or technologies, it can be soft skills like coaching or more tangible skills like more proficient refactoring techniques. These can be achieved by creating working groups to fix a company process, or creating social groups that focus on learning a specific topic. For example, a book club!
Modern Agile
You may consider yourself in an agile environment now. After all, you do development sprints, and you do daily stand-ups.
But just like software technologies, Agile has improved over time. I would like to direct your attention to Agile Evolved: Modern Agile.
Modern Agile has four guiding principles:
1. Make People Awesome
2. Experiment and Learn Rapidly
3. Deliver Value Continuously
4. Make Safety a Prerequisite
Some of the topics I mentioned before already cover some of these principles. But there is one clear omission: Make Safety a Prerequisite. Not just physical safety, also psychological safety. This is a crucial ingredient to modern agile; a lynchpin that holds everything together.
I want you to think back to the last time you were in a large meeting. Did you notice that most of the attendees were fairly silent? Maybe it was dominated by a few strong voices. Perhaps those silent participants didn’t feel safe to participate; are they afraid of being ridiculed?
Indeed, a lack psychological safety makes a hazardous workplace and absolutely cripples a team’s ability to collaborate.
The idea of collaboration is powerful and a successful team is always striving to find new ways to collaborate effectively. Whether that’s employing kanban, utilizing pair programming, or leveraging daily stand ups, there are many tools at our disposal and modern agile just helps in providing a framework to do that!
Work Life Balance is Paramount
Prior to joining Nulogy, I struggled with my definition of Work Life Balance. I was working exactly 9–5, with very little overtime. But I still came to the conclusion that my work life balance was actually very poor.
Why was my work life balance poor? I’m not working overtime; I’m working the regular mandated hours.
It took some self-reflection but then I had my “Eureka!” moment. I adjusted my personal definition of what Work Life Balance meant. I used to think it was just how much time you spent at work, or how much work you were doing at home. But, I realized it’s really about how my work life affects my personal life.
For example, I may leave work at 5PM but if I had a terrible day at work I would be in a bad mood, and that bad mood would become a theme for the rest of my night.
Contrasting this, how much would my personal life benefit if I worked later but was happy during the day?
This led me on a journey of self discovery to find what really made me happy, and eventually led me to where I am now.
The first step in solving the work-life-balance conundrum is to understand what gives you personal fulfillment at work. A valuable tool for identifying this is Moving Motivators. Identifying and then seeking out this fulfillment is crucial for achieving happiness at work, and thus your work life balance.
I’ll close by stating just because your current environment may not do all of the above doesn’t necessarily mean it’s a bad place to work. Nor do I consider this a complete list.
These are key differentiating themes that I feel are a good signal for positive work environments. My hope is that you can use this as a tool for identifying the type of world you are in. Never accept good enough, and always strive for better!
