article
-
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.
- Encapsulate What Changes
- Orthogonality
- Inversion of Control
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 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.
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 😉
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 😉
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.
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:
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?
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?
List of programming principles
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:
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!