Funability, Part 5: A Layered Approach to Quality
Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:
Part 1 – What and Why
Part 2 – Leverage Your Leadership Roles
Part 3 – Maximizing Productivity
Part 4 – Processes Can Be Fun
We’ve now come to the last post in our series on funability. We hope that along the way you have been inspired to identify opportunities that will enhance the way your teams work (and grow) together.
So far, we have covered the what’s and why’s of funability, how to leverage your leadership roles, ways to maximize the productivity of your engineers, and how processes can achieve funability. In this final post, we will discuss how various layers of testing can produce quality software and – in turn – provide funability for the team.
Code Reviews
We believe code reviews are the single best way to improve the quality of your code base and to ensure the integrity of the design is maintained. Hands down. But while the idea of code reviews isn’t new to us, we will admit the adoption of them was probably slower than we should have allowed.
When we were using TFS back in the good old days (and not having all the branching and merging we do today), code reviews were painful. It was time-consuming and difficult to get the “big picture” of the system. And this would lead to the occasional bug or design inconsistency to slip through, especially when we were under the gun to get a release out the door.
Now with our adoption of GitHub and pull requests, code reviews (assuming they contain a reasonably small number of files and changes) are both manageable and effective. It’s easy to review every pull request, and that helps us to find even the smallest issues (or seeds of potential issues). They also ensure that we’re remaining consistent with our software architecture and design rules.
Aside from the quality aspects, code reviews also provide a mechanism through which mentoring and coaching can occur. There’s very little that can replace the face-to-face conversations where senior engineers talk through code with younger developers and share insights from their experiences.
Continuous Integration with Automated Integration and Unit Tests
One area in which we are continuing to grow and evolve is the way we test our code. We have seen tremendous success in the running of unit tests against every pull request before you merge. While it may sound like a lot of work along the way, it really does make a difference.
It’s easy to say your code works when it just runs on your machine (aka, WOMM – Works On My Machine). Showing that it runs just as well on the build server is something else entirely. Testing at different milestones along the way instills confidence in your code and your systems as a whole.
Putting off testing until several merges have been completed can set a proverbial snowball of problems rolling down the hill, and it’s a snowball that nobody knows exists until it’s too late. By taking the time to test every pull request, you can stop the snowball and prevent your system from becoming the one that nobody wants to work on (and we’ve all worked on those before).
Integration tests focus on issues related to integration of individual classes, modules, and services. This can uncover issues around coupling, invalid assumptions, etc. Not doing integration tests means you will almost always have a “stabilization phase” at the end of your development where you are working out bugs related to integration of the software after you are supposedly “feature complete”. This really sucks.
If nothing else, having a heavily tested code base will help you to sleep better at night because you aren’t dreading a support call.
In Closing
We hope that you have found this series to be useful or at least inspirational. But we should stress that there is no silver bullet to creating funability within your organization. To truly change your software development culture, you need to go beyond the cool spaces and agile/scrum processes. You need to change the way software is designed and created. Only an integrated view of these processes will get you moving towards funability.
And we should say that we have not fully achieved funability. While we have increased it greatly over the past 7 years, there’s still more to be done (and we imagine there will always be room for improvement). So when you begin to look for ways to bring funability into your culture, don’t expect to turn your ship around in short order. Any kind of culture change takes time.
But if you have a plan and are constantly reviewing your practices and processes, you will achieve new levels of funability. And your engineers (and your code base) will be better for it.
This post was originally published on the Don’t Panic Labs blog.
