External forces

I am occupied with learning these days. Learning on my own about visualizations of data among other topics. But also learning about learning. For that I read what other people think about learning. There are many things I have to learn about this whole topic. One thought I saw repeatedly, was about external forces, or limiting factors.

Let me elaborate what I mean by that: There are people that can motivate themselves more easily than others can. They reach their goals or at least try very hard. Others give up more easily when they face some resistance. As always, there are people in the middle between these extremes. You know best which group you belong to. 💪

What has this do with software quality? I am getting there… 😉

I am wondering how external forces could help improve quality. If you need to reach your goal and you don’t belong to the group of highly self-motivated people there are options like hiring a coach. Athletes do that all the time. I pay for a “virtual” coach that guides my running efforts.

How could you hire a “virtual” coach for your coding efforts, for reaching your targets on your software quality metrics? You could hire me or other “real” coaches, of course. But that doesn’t scale too well and might be too expensive.

Again, for some people it is easy enough to use static analysis or linting — a kind of coach in it’s own right — and follow their guidelines. Yet, still there are people that ignore the warnings or guidelines imposed upon them by the tools. Reasons may be a hard deadline or too much workload. How could we offer external forces, limiting factors that help them, guide them, towards doing the right thing?

One solution I can think of is to have a robot not accept your code when it is below standard or ignores guidelines. A robot could be anything that measures and grades your code and reports back to your team. Some tools already offer this, for example GitLab. If you want to merge code that decreases the overal quality metrics, you are not allowed to do so. So that would be one.

Another idea: If you try to commit or merge such code, you need to consult with another developer about the code. Once you worked on it together, the other dev has to enter her secret key, to remove the lock on the merge. This forces you to pair on code more often.

When it comes to teaching there is this saying of the “glass has to be empty (enough).” You cannot pour water into it, when it’s already filled. Said ideas 👆probably won’t work for a team that isn’t aiming for learning and improving.

I will continue to think.

Quick wins, part 2: Method names revisited

Yesterday, we had the first part of this series on quick wins and simple steps to improve your code quality. It was about naming — specifically variables and method names.

Two things were not 100% right in these examples.

The first error

You might have noticed that my loop examples were written in Ruby code. Yet the method name doSomething was written in camelCase. This is unusual for Ruby code where developers tend to use snake_case for method names.

I did not lint that email. Hence no robot told me about my error. I believe it is a good example of the benefit of automatic linting. This error would have been found. If you read the code and were put off by this naming scheme, you even experienced why conventions and rules are necessary: Because coding by the rules helps developers to focus on the semantics of the code, not the syntax.

The second problem

Do you remember that I wrote about JavaScript loops and gave the classic for loop example? I complained about the i variable and that it should be called iterator. Perhaps you did not like this idea and my example? Let me take a step back for a second.

When naming variables and method names, you have to make sure they “speak.” The names should indicate their meaning and make it easier for another developer to understand the semantics of your code. Yet, when you are fully aware of the problem domain you code deals with, it can happen that you try to be too specific. If you are, you tend to use long, verbose names for variables and methods. An example could be this:

A common value for the allowed length of method names is 30 chars. The above example could be broken into two methods.

The next possible quick win might be to think about the existence of these methods inside the Article class. Verifying and fixing meta tags surely does not need to be done inside this class. If you want to follow the Single Responsibility Principle, you should make sure that the Article class does not have a reason to change, if you decide to change something about verifying and fixing meta tags. Rather the Article class might change when you decide that an article should have a mandatory sub-headline.

Back to the iterator. This name could pass the test for too specific. Only, when i refers to a variable that is declared and initialized outside of the scope of the loop, does it make sense to choose a different name. Or doesn’t it? As always it depends. The classic for loop is taught in almost every book on JavaScript, and it is easily identifiable as to what it is. But there might be reasons to deviate from that, as I indicated above.


To summarize:

  1. Choose good names. 😎
  2. Spot places where knowledge about something does not belong.

Tomorrow we’ll look at another example for 2 and a practical idea of what to do about it.

Computer says “no”

[…] we do have formal rules that we should obey when writing code. A team has rules, and new team members need to learn them before trying to write any code.

That’s what I wrote yesterday. It’s my email so I can write whatever I think is correct. You’ll let me know through your answers if I am wrong.

My friend Tino answered on Friday and asked whether a university degree or certificates might function as a driver’s license. And that is true to a certain degree. I am getting a new certificate these days as well. I hope to complete the exam on Wednesday (ISTQB Advanced Level — Technical Test Analyst).

The obvious difference to a driver’s license? I am not legally required to obtain one before I can start writing code. Tino also said that he’d find it interesting to be (self)tested in current web-standards and best practices. I do believe these tests are valuable. If I come around to create one, I’ll let you know.

Back to the beginning of the email. Why do rules matter to a team? Developers have their style for writing code. Even if there are rules and certain regulations you have to follow, developers still find ways to write code in their unique style. And that’s a good thing. It would be boring otherwise.

Still, this style has to obey the rules. Here’s why:

  • The code won’t be too complex. Because your static analysis tools tell you if your cyclomatic complexity metric is too high.
  • Classes and modules will have low coupling and high cohesion. This leads to code that’s more easily testable and has higher reusability than other code.
  • If you have an error if explaining comments are missing, you could make sure that your developers take some extra time to make sure code can be easier to understand. Other rules, like variable and method/class/module naming conventions, have the same goal.

In short: Rules help your team to write code that is maintainable and has low technical debt. This reduces the total costs of ownership. If you only look at the cost of writing the code and delivering the software, the costs might be higher if you follow stricter rules. Over the complete lifecycle of a software (product), the total costs would be lower because of better maintainability and a lower number of defects.

This is already getting long. See you tomorrow with even more thoughts on this topic.

Driving on the left side of the road

We don’t have rules of the road for software development. You don’t have to stop at every red light or keep your speed below a specific limit.

Well, yes. We do have rules. If you write your whole program in only one file, someone will tell you that this is bad. At least I hope that’s the case!

If you only use variable names like x or y, your coworkers will flag this during code review. Perhaps you already have static analysis tools that tell you before your coworkers do?

While we do not have a driver’s license, we do have formal rules that we should obey when writing code. A team has rules, and new team members need to learn them before trying to write any code. Otherwise, it could feel like driving on the wrong side of the road: Driving on the right side of the road feels natural to you if you’ve never done it any differently. But it can have dramatic consequences if everyone else expects you to drive on the left side.

Coding license

Every country I know has an obligatory driving license before you are allowed to drive a car by yourself.

No country I know has an obligatory coding license before you are allowed to code by yourself.

The longer the time that passed between the driving license and the current day, the more reckless and careless drivers have become. What I mean is that new drivers are careful. For the rules, for their passengers, for other cars and people. The longer they drive, the more they bend the rules, pass yellow or red lights, or speed just a tiny bit. Everonye does it, why shouldn’t they do it as well. No one is looking anyway…

I won’t argue for a coding license. It would be fruitless anyway, and it would be too hard to establish a standard. But there so many simple (not easy) wins you could have with the proper knowledge and attitude. So many legacy systems less and so many more successful projects.

When was the last time you compared your skills in coding with other people and had the possibility to spot places you could improve? How do you score your ability anyway? How do you decide what to learn or focus on?

Do you decide these things before you start to code on a project, or do you only find out in hindsight, when issues arise or new features begin to get harder to realize? Do keep a list of problems you identified and make sure you avoid them in the future?

I’ll take the next week to look into this more.

Software rewrites – Does it make sense?

I came across a very interesting article written by Herb Caudill, on different perspectives on rewriting software. He highlights 6 different stories of how a rewrite went. You can read about Basecamp, Netscape Navigator, Gmail, and others.

It is a long article, over 30 minutes according to Medium.com. And I am also sorry for linking to Medium. I don’t like them, and I resent sending them traffic. But this story might be worth it.

Here you go: Lessons from 6 software rewrite stories

NB: I do have experience with software rewrites myself. I took part in two endeavors. One thing was a client application. The legacy app was written in Rails 2 (I believe, it might have been Rails 3) and heavily patched. This made maintenance and feature development quite expensive. We rewrote the software but kept quite close to the original in functionality. The rewrite enabled us to use modern gems and solutions we had created in-house for other clients. This used synergies. It was an ambitious project. In the end, I think it didn’t make too much sense, financially. But I couldn’t be sure about that one.

Another project where I helped on a rewrite concerned frameworks for iOS applications. We had customers that wanted to publish iPad magazines on the App Store. To make it easier for themselves, previous developers had written a custom publishing framework. This framework was reused on every project. It was extendable, reusable and efficient. But it was also difficult to handle and very limiting with regards to the layout and design of the magazines. Which was a problem for the clients. So they set out to rewrite this. I joined the company while the project was still in progress. I left 2 years later. The project was still ongoing. The rewritten framework was used in every client project, alongside the older framework. For some features, you had to use the old one, because they weren’t yet supported on the new framework. For other use-cases, you had to use the new framework. Especially for certain pages in the magazine, with new layouts. Yeah, it sucked.

Motivation, or: How to get your coworkers to write better code

How can I get my coworkers to write better code?

We closed with this question, yesterday. If you want to be able to motivate your coworkers to write better code, you have to know where they stand right now. I already wrote a few articles onthis topic. Follow these links, and you’ll get a good idea on what to measure, how and why. You’re welcome.

Continue reading Motivation, or: How to get your coworkers to write better code