Feb 20, 2019 ∞

Answering a comment about 'Delete all your tests'

Matthias Berth is a German expert on software delivery and software quality. He politely disagreed with me on the idea that you should delete all your tests.

I decided to call this day “Video Wednesday” and record an answer as a video. I just posted it on LinkedIn, and thought you might like to watch it there.

It even has subtitles 😉

Feb 20, 2019 ∞

Answering a comment about 'Delete all your tests'

Matthias Berth is a German expert on software delivery and software quality. He politely disagreed with me on the idea that you should delete all your tests.

I decided to call this day “Video Wednesday” and record an answer as a video. I just posted it on LinkedIn, and thought you might like to watch it there.

It even has subtitles 😉

Feb 19, 2019 ∞

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 on this topic. Follow these links, and you’ll get a good idea on what to measure, how and why. You’re welcome.

After reading and measuring and talking with your coworkers, you are still left with the idea of motivating them.

I am good with code and perhaps with words (you decide). Motivation is a “people-topic”. This is psychology. I do know a good book, a classic that you could read: Peopleware: Productive Projects and Teams The contents in the book will help you understand how to build a great team, how to motivate people and understand their goals. You could adapt this knowledge and make them write better code. Other ideas:

Invite me to give a workshop on software design and architecture, testing or how to write better code
Try to use gamification. This could mean that you publicize the code quality metrics and make it a game to increase the score. The weekly winner gets a price (a half-day off of work?). Better: Make it a team effort. Let them all be winners because it was probably not one person that created all the code in the first place, right?
Send them to workshops, conferences or use learning sessions to help them understand how a better/different way to write code would help them with their job.

I sincerely believe that engineers, programmers, developers, coders, and hackers (which one are you?) take pride in their work. They always try to do the best they can. I haven’t yet met a single person who deliberately wrote shitty code. Perhaps it was a byproduct of too little knowledge or experience. But never was it their intent. If you help them level up, they will get better. And your code and products will too.

Feb 18, 2019 ∞

Confidence, or: How to assess your coworkers

Today I’d like to answer a question.

As a (project or product) manager, how am I able to assess whether my coworkers write good code?

It’s is a good question. It’s easy to see why a development team lead might want to know whether her direct reports write good code. And she probably has pretty easy means to find out. A project or product manager might care just as much—or he might only be curious. Either way, how could he judge the code quality?

Related to Friday’s email, if you wanted to know something about the software quality, you could ask your clients or users. Or you might already know because people are usually quick to share their opinions especially if something is wrong.

The quality of the code your coworkers write can be assessed with quality metrics.

You can take relatively simple metrics like

lines of code (per class, per file)
number of commits per author per day

Or you could use a software as a service offering like CodeScene or CodeClimate or SonarQube. These offer advanced metrics that take a little more “Code-Fu” to gather.

The most straightforward, most effective metric is another one: Ask them! They are developers and work with the code all day. They will have an opinion on it. Perhaps they have a hard time to explain something they don’t like, depending on their seniority. But you will get some measure of quality. The more people you talk with, the more opinions you can get. And if their views are orthogonal to each other, you can offer to use static analysis to settle the debate.

The question I received had a second part as well:

… and how can I get them to improve their code?

I will offer an opinion on that one tomorrow.

Feb 15, 2019 ∞

2018 State of Code Review Study

81% of respondents who were satisfied with their code review process were also satisfied with the overall quality of their software. Respondents who were not satisfied with their code review process were half as likely to be satisfied in their overall software quality, with only 40% respectively.

This is from a research study done by SmartBear.

This image tells us that the majority things code review is the way to go to increase code quality. This might be true, or it might not. The quality of a review depends 100% on the knowledge, ability to communicate and the time a reviewer takes to dive into the code. Static analysis is way down in second to the last place. Unit testing is right behind code reviews.

I could argue either way. My problem with this study is the term code quality. Code quality to me means that you talk about things like coupling/cohesion, readability, and maintainability, adherence to standards, low bug count. Quality metrics your code exhibits. Code review is not the best tool to increase this metric. Robots and static analysis are. You need impartial tools that hold you to a strict standard. People don’t do this. They are lazy. If you talk about software quality, on the other hand, that’s where you need people. Thinking about and discussing software architecture and design, debating about usability. Fine-tuning the visual design of a product. This is where reviews are the go-to tool for the job.

I guess this distinction was unclear to most participants. That’s a shame.

You can read the study here. I don’t link to their signup form for the study. They ask details like your phone number before you can download it. That’s bad practice, hence the direct link. I’d be happy to hear your thoughts on this. Do you make a distinction between code and software?

Feb 15, 2019 ∞

2018 State of Code Review Study

81% of respondents who were satisfied with their code review process were also satisfied with the overall quality of their software. Respondents who were not satisfied with their code review process were half as likely to be satisfied in their overall software quality, with only 40% respectively.

This is from a research study done by SmartBear.

This image tells us that the majority things code review is the way to go to increase code quality. This might be true, or it might not. The quality of a review depends 100% on the knowledge, ability to communicate and the time a reviewer takes to dive into the code. Static analysis is way down in second to the last place. Unit testing is right behind code reviews.

I could argue either way. My problem with this study is the term code quality. Code quality to me means that you talk about things like coupling/cohesion, readability, and maintainability, adherence to standards, low bug count. Quality metrics your code exhibits. Code review is not the best tool to increase this metric. Robots and static analysis are. You need impartial tools that hold you to a strict standard. People don’t do this. They are lazy. If you talk about software quality, on the other hand, that’s where you need people. Thinking about and discussing software architecture and design, debating about usability. Fine-tuning the visual design of a product. This is where reviews are the go-to tool for the job.

I guess this distinction was unclear to most participants. That’s a shame.

You can read the study here. I don’t link to their signup form for the study. They ask details like your phone number before you can download it. That’s bad practice, hence the direct link. I’d be happy to hear your thoughts on this. Do you make a distinction between code and software?

Feb 14, 2019 ∞

List of programming principles

This is a nice list of principles you could (or should?) follow in your programming.

https://github.com/5minpause/programming-principles

Disclaimer: I forked the repository from the original source. I want to preserve it for you since I don’t know what will happen to the original.

While things like YAGNI and KISS are rather well known, there are other ideas that are put quite well.

Examples:

Encapsulate What Changes
Orthogonality
Inversion of Control

To be clear: This list is nothing new. I do like the way they put it together, the idea that it’s growing and the further resources they link to.

Have a look!

Feb 13, 2019 ∞

Delete all your tests!

Sorry for not writing yesterday. My schedule did not allow it. I refrained from posting anything since it wouldn’t have been of sufficient quality for you.

On Monday I tried something new. I recorded the content of the newsletter as a video and posted it to YouTube and LinkedIn. While it didn’t exactly blow up, I am happy and excited about these changes. I want to try to stick with this. Today I switched things up. I first recorded the video, of which I’ve embedded a link to below, and then wrote the newsletter.

https://youtu.be/7FRYUE_waWk

The subject says it already: Delete all your tests!

Testing strategies - Test management

You don’t need test management. You develop web applications. Your job is not rocket science. It’s demanding, and you are doing a fantastic part shipping features and making customers happy. Who needs test management to do that, right?

Let’s try three different points of view on this:

The software developer’s Pov

You code and you write tests, even perhaps before writing application code? Different project managers come to you with their projects and ask you to be part of the team. You have a reputation with them that you are able to ship. You have your hands in several projects and can choose which ones you would like to work on. Your manager sets up an appointment for the yearly review. You want to ask for a raise. On what ground should you get your raise? Because other employees value you and your work? Because of your reputation?

Testing strategies - Back to start

On Friday I gave you a very quick intro on how you could increase your test coverage and confidence for an application that has no tests. You can consider this the quick and dirty approach that works, when you have little time and just want to start somewhere.

Perhaps you should start at an earlier point. A proper way to start the journey to testing software is the state the question

Why do we test software?