6 Steps for Traveling the Other Path
While Uncle Bob warns about The Dark Path with a lot of criticism for relying too much on strongly typed compilers I think there are many more concerns to consider. Beyond using a programming language which makes us feel safe and protected from exceptions caused null values, there are a lot of other paths you can take which are not so dark.
- Automated Testing
- Linting
- Coding Standards
- Code Reviews
- Continual Learning
- Architectural Organization
Automated Testing
As Uncle Bob points out, automated testing is important. It is often presented as the balance to dynamic languages which are not as well protected with the compiler for strongly typed languages. JavaScript, Ruby and Python all benefit greatly from tests which confirm the code works correctly and also catches problems early and as often as they are introduced. I think we can all agree that unit tests, functional tests, UI tests and integration tests which all can be automated can light that dark path.
Linting
Static analysis which generates warnings and errors when the code is compiled covers the hard requirements and some strong suggestions. But compilers work for computers. Linters work for people. With SwiftLint it is possible to identify many ways your code can improve and also set a bar for how a project will be maintained. You can start out with a minimum number of linting rules from the start and gradually enable more over time. It can really help make a code base look and feel much better and allowing the linter tell you what could be improved before you commit your changes can cut down on feedback in code reviews. It also sets coding standards which is the next point.
Coding Standards
Most coding standards are pretty light which is good. It is best to keep it short and sweet. If the standards cannot be easily remembered they won’t be followed so closely. These standards should also be considered guidelines instead of a hard set of requirements which may actually change over time in response to changes in the team and the technologies which are being used. New ideas and techniques emerge all the time which could be embraced by a current coding standard.
Code Reviews
One way to set a coding standard over time is with code reviews. As your team discovers coding patterns to encourage or discourage it is a good time to start having one on one conversations about these discoveries. As the feedback for code reviews becomes a bit repetitive those tips can be written down to share with the team in a less transient way. The goal of a code review should be to learn together and to share tips which allow for improving the quality of the code. A code review should not be a list of demands for changes because that will quickly turn the process into a unwelcome step in the development cycle which generates resentment among the team. Nobody wants that. Instead treat it as an opportunity to share tips and to better understand how others approach software development. It is a great opportunity for reviewers to learn as well as get a heads up on changes which may affect their work once the code is pushed.
Continual Learning
During regular code reviews there will be a lot of discoveries about the code as it changes as well as discoveries about strengths, weaknesses as well as interests and passions for everyone on the team. Beyond adding more content to the coding standard it is helpful to write internal blog posts or even public blog posts related to what the team is building. Writing down and sharing what you are learning is a great way to reinforce those lessons. And from time to time it would be great to present some of those lessons to the entire team, perhaps have lunch ordered in for an occasional lunch and learn session. When interests and passions are discovered it is a good cue to encourage blog posts and presentations to fan their efforts to learn and to also benefit the team.
Architectural Organization
Finally, a lot of progress can be made by simply breaking down all of the work into parts so that different members of the team can own different modules which come together for the whole. First, it is a whole lot easier to design and plan a module which is well-defined with limited purpose which can be built and tested to show that it is working as intended. Second, as new members join the team it is a lot easier to get them up to speed on a single module at a time and let them take ownership of it in a shorter timeframe so they can master it and start contributing useful updates sooner. And third, it gives the team an opportunity to work on different modules over time to get more exposure to the rest of the project and learn about something new to them in the process.
Uncle Bob asked who’s job it was to manage risk and I would say it is up to every person on the team. And that responsibility includes the choices which are made for languages, tools and architectural planning. Our plans create structure for our work and our tools give us support to do our jobs. But they are only a part our work days.
These 6 steps cover multiple ways that a team can contribute not only to the quality of the code base but also contribute to each other’s careers. Remember while we do work with code we are also working with other people. Showing appreciation for a co-worker who has taken time to help you goes a long way. As your experience grows with your team the quality of your work will improve proportionally. I am sure you will find that a collaborative team is the best way to prevent those nasty exceptions Uncle Bob clearly despises and knowing others will be there to catch your infrequent mistakes will be a much better work life.
