From the feedback I got for my questions and letters regarding the quality of software projects, I can tell you one metric software developers look for.
Commenting code and documenting it has been a topic in these letters already. I linked to resources on how to write docs etc.
For the future, this might not be necessary anymore. Because you can have a machine write the comments for you. There is a research project done by Chinese researchers Xing Hu, Ge Li, Xin Xia, David Lo and Zhi Jin named "Deep Code Comment Generation".
Yesterday I went to an exciting event. The topic was "Can Artificial Intelligence synthesize software?". The company Seerene organized the event. I haven't heard about them before, but they are just what I like. They analyze code and projects for optimization potential and defects. I started the conversation with them, let's see what comes out of it.
Imagine you are doing a software project. It is mostly going like planned. Things happen. You anticipated them and prepared for them. But there are days when unexpected things happen:
- Stack Overflow is down, and your developers suddenly aren't as productive as usually 😜
- Slack is down, and communication is halted. Everyone freaks out, and no work gets done.
- Your hoster has problems with their energy and their emergency energy, and servers stop and reboot. You have to take care of this.
- all kinds of things…
Continue reading Risk list
To achieve high quality in your team's code, you should use tools like a static analyzer. These analyzers give you lots of metrics. One is the cyclomatic complexity. A very reduced definition is, that the more complex your methods are, the higher the cyclomatic complexity. A high complexity results from many different paths the program can take while running your code.
Many conditionals (
else) or branches in your code lead to higher complexity.
If you paint a fence, you need to make sure to prepare the wood. Take coarse-grained sandpaper and sand the old paint. You have to take it off the wood completely. Once you are done with it, you should use a primer and put it onto the wood. Let it dry for a few hours. After the primer has dried, you take your color and apply it thinly.
Let it dry for another 6 hours. The next step is to apply the color again and let it dry again. Afterward, you can decide whether you need protective paint/lacquer, to guard against weather conditions. That depends on your location.
Do you know the term technical debt? Wikipedia describes it as "a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer." (https://en.wikipedia.org/wiki/Technical\_debt)
This is certainly a correct definition, but there's more to it. We'll get to that shortly.
If you read these letters for a few issues, you might have already noticed that I like quality in software engineering. I try to optimize for quality and enhancing the quality of a project leads to more successful projects and more satisfied clients.
If you care for the quality it can lead to situations where you have to stand your ground to achieve the goal of increasing the quality (or your processes or your products). Because doing high-quality work also increases the costs of a project. And it's rare that managers don't care for the cost of a project.
Imagine you have a team member that always criticises your work. You make commit after commit and put your best effort forth, you try to find the best names for variables and methods. You check your code using tools like RuboCop and Linters. Yet in every pull request, he asks you whether you considered refactoring objects. Things like extracting some logic out of a class, introducing view models and repository objects and sometimes even crazy stuff like domain driven design ideas. Why can't he leave you alone?
I tell you why: Because the fundamentals matter. They make the difference between software projects where things go smoothly and projects that just fail.
The other week I went on vacation with my family. We flew to Switzerland and had a really great time. I took the big camera to make gorgeous shots of my wife, my baby daughter and the Alps. The iPhone camera is great but pales in comparison to a professional camera. As I am no great photographer you can see this in every shot. But still, the pictures I made with the DSLR are just better. When using a big camera I always try to take more time for the composition of the shot. I use the lens, different focus spots and depth of field way more than when shooting with my phone.