I help companies increase their software quality, lower technical debt and save money developing software

I write a newsletter about these topics every week-day. Below you'll find recent issues.

Learn how to improve your software's quality

You'll receive an email every week-day

Posts

  • A story about a feature gone bad

    Chad clicked the button and created his pull request. He had worked on his feature really long — it must have been three weeks. Finally, it was time to integrate his changes into the master branch so they could go live with the new version of the app. This was the first huge feature that was his responsibility. His team lead, Janet, gave him the ticket for the task and he set out to write his code. “When it finally goes live,” he thought, “the churn of our users should drastically go down!”.

    Primarily he had found many places in the app, where users committed some actions. Up until now, these actions weren’t registered anywhere, so nothing and nobody tracked them. There was no record of what the user did or didn’t do inside the app. Marketing alerted management that too many users did not renew their accounts, or outright canceled. In turn, management asked the developers to do something about it. Together the team decided to record all user actions and put them into a log of all activities for this user. This way they could make calculations which users were not active in the app and reach out to them to prevent them from abandoning the application, or so they hoped. The development of the feature enabled Chad to take a thorough look at the whole application. After all, he had to integrate his code into all kinds of places. And so he did. Today he was finally ready to publish the code and begin the merging. To integrate it into the master branch so that it could get deployed, he had to create a pull request. “Since my code is well written and worked when I tested it, it shouldn’t take too long for this merge to complete.” was his conviction. He assigned the pull request to his team lead and another backend developer that he had talked to during lunch a few days earlier. Chad used the lunch to tell her about his progress on the feature, and she seemed interested. So another set of eyes shouldn’t hurt.

  • Only two rules

    There are only two hard rules when doing code review with your coworkers:

    1. Keep it professional. Don’t. Get. Personal.
    2. Don’t take it personal.

    Remember that you are talking about letters and symbols in files. Nothing more and nothing less.
    You are doing this to improve the results, the software.

    You are not your code!

  • Indentation as a Complexity Metric

    If you want to measure the complexity of your software, there is a lot of software, tools and software-as-a-service offerings available. These options can seem daunting and have a lot of onboarding time (the time it takes you to understand how to use them and get meaningful results).

    If none of these things work for you, don’t despair. There is a simple way to get a high-level view on the complexity of your software. And it’s language-agnostic. It doesn’t care whether you write CSS, Ruby, Java or something else.

  • Show your work

    I wanted to add something to the topic from two days ago: Quality in the eyes of your users.

    There is a thing I did not mention. A practice that could help you and your team achieve a higher quality of your products:

    1. Show your work early and often.
    2. Improve after receiving feedback.
    3. Repeat from step 1.
  • Interfaces

    In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. (Source: Wikipedia.org)

    You develop a web application that has a frontend for the users and a backend for the business logic and the data persistence. (This is a simplification, bear with me for a second.)
    Your frontend accesses the data from the backend through an API that the backend provides. This is the first interface. It’s right there in its name Application Programming Interface. But let’s ignore that one for another second.
    How does your frontend consume the API? Did you wrap the calls to the API in its own class in the frontend?

  • Quality in the eyes of your users

    I bet that most people reading this won’t have UAT or QA. So what could you do to still achieve quality in the eyes of your users?

    Yours users will spend more time with your software, like it and recommend it more, when they are happy using it. If we’re honest it might even be enough to make them not dislike the software. There is so much crap software out there, that people use to get their job done, that the bar is pretty low.

  • Two views on quality

    During the last months I wrote a lot about quality and how to develop high-quality software. These letters dealt with topics like linting your code, testing and documenting it.
    I also wrote about the different perspectives and motives that might exist in your team.

    But there is one view that I omitted more or less: The external view of your customers. They expect to receive and use your software. They expect it to be without bugs and to fulfill the role they “hired it for”.

subscribe via RSS