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
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.
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.
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.
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 😉
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
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.
Continue reading Confidence, or: How to assess your coworkers
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?
This is a nice list of principles you could (or should?) follow in your programming.
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.
Continue reading List of programming principles
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.
The subject says it already: Delete all your tests!
Continue reading Delete all your tests!
This list grew quite a bit during the last days. Thank you all for subscribing. If there are questions or you would like to share a point of view with me, please always feel free to reach out. I literally jump with joy when I get an email from you. We all have too many emails in our inboxes that are unimportant. Your emails are important to me, and I welcome them. Try it out 😉
Last week I wrote about testing. The weeks and days before that, I wrote about continuous integration without branches, configuration management, best practices for modeling business processes in code, code styles, linting and much more.
Continue reading What is he talking about?