Software Craftmanship — Writing code for the future
Back in 2008 Robert C Martin proposed a fifth value for the Agile Manifesto: “Craftmanship over Execution”. With this value he wanted to tackle one of the main reasons why software fails, situations when teams execute but don’t care.
With this idea the goal is to draw attention to readability, stability and technical excellence. In order to accomplish this, it is often best to have a certain official development culture, with a set of standards and principles, in the team and company.
But that is not always the case. Management often refuses to allow certain practices to become official, but even in such cases, developers should not be stopped in applying them. After all, to become a professional software developer, one needs to start from oneself. Elevating yourself to higher standards can be done even if the surroundings don’t always set the path. There are a lot of ways to help you achieve high quality code without official permission. After all, to became a better developer, you need to take pride in what you do and have something to defend.
Here are three practices, mostly practiced in the enterprise world that can help you achieve better personal productivity:
Boy Scout Rule
Always leave things better than you found them. This rule applies in every part of life and, consequently, in software development. If you are adding a new feature, fixing a bug or refactoring always think how you can improve what you come across.
But be aware, don’t do big changes. If you think something should be improved, but would take a lot of time, propose it for refactoring (just by creating a proposal for refactoring means you are still tidying up the code). Do only smaller changes to what you are originally doing, something that takes couple of minutes, like improving logging message, a better exception handling, create couple more tests for edge cases, break bigger methods in two or more smaller methods, fix the method or test name to be more meaningful, etc.
These kinds of changes don’t take much time, but will drastically improve the quality over a longer period of time.
TDD
Test-Driven-Development is a way of designing software by writing test before you write code. The goal is to think about usage of your code before you write it and use tests to think about how it should work. If you do so, you will end up designing APIs and publicly available methods in classes to be cleaner and easier to use. Using some advanced techniques of practicing TDD will help you create highly abstract modules with very high test coverages. With that we come to another product of this approach which is that you will have a lot of automated acceptance tests, edge-case tests and negative test cases that cover your code. Third effect is, such tests can be used as documentation. As I said at the beginning, the goal is to use tests to design classes and modules better.
In practice I saw several bad implementations of TDD. In all of these cases it happened because management decided to introduce it as the official practice in the company. The problem is they thought of TDD as a way to increase the number of tests. And the developers that previously didn’t work using TDD often take that goal as the absolute truth.
They end up hating it because they see it as a push to do more tests. This would result in them refusing to write poor tests, and often write tests after the code, but “selling” it as they are doing TDD.
This is why it is very important to start using TDD and practice it before making it official. The initiative to make it official must come from developers not from management.
Do Less
One of the biggest issues while working with large enterprise projects is complexity. With time, the technical debt increases, and the code base explodes in size. This makes handling that code harder with time, even when you need to introduce small changes. Even worse, if the code is not written in a way that it can be changed over time by someone who has not written it and there is no one to help them navigate it from the previous team in charge. One of the first goals you need to set is not to become that kind of a developer, who doesn’t care what will happen once they are not there to work or help with the code they wrote.
The best approach here is to always start small, and iterate small. Ignore big details, focus on the smallest details and do them one by one. Ship things early and ship often. Make sure it works and it is covered with tests. The best way to start is to apply the Single Responsibility Principle. The goal of which is to have methods and classes that do one and only one thing. This make them easy to test and easy to use.
By paying attention to detail while writing, you can make it very easy for others to read and understand. Limit yourself by making all methods you write no longer than 6 or 7 lines, and keep classes under a 100 lines. This does mean you will start slow, but you will finish fast. By using a mix of TDD and ADD, you can have acceptance integration tests that will give you the bigger picture and set you on the right path; but when you do small iterations, you write bulletproof classes and modules. Since the devil is in the details, you will stop yourself from producing bugs early on, so by the time you are done, you will drastically decrease the chances of having a lot of bugs, for the QA to have a lot of work and you will not lose a lot of time debugging and fixing edge case bugs by going through a lot of code. You lose much less time by working step by step than by fixing large bugs and edge case problems after writing a large sized code. In time you might find yourself using debugging tools very rarely or not at all!
