Thursday Links is a new format for me to systematise what I learned for a week. I have only one rule: content should be “technology agnostic” to be useful for more people, not just me.

Good: architecture patterns, UX tips, soft skills, programming paradigms.
Good, but not for Thursday Links: Amazon Lambda, Python, themes for Gatsby

Agile Metrics — The Good, the Bad, and the Ugly

https://age-of-product.com/agile-metrics-good-bad-ugly/

Why do we need metrics at all? The author says:

Metrics are used to understand the current situation better as well as to gain insight on change over time. Without metrics, assessing any effort or development will be open to gut feeling and bias based interpretation.

There are 3 tips:

1. Metrics should describe a team, not individual
2. We shouldn't measure parameters only because it's easy (e.g. if Jira shows them in a report by default)
3. Sometimes it's not enough to have just raw data – the same trend may show different things. Therefore it's important to save information about the context as well

I didn't understand the 3rd tip at first, but there is an example of it:

For example, if the (average) sentiment on the technical debt metric (see below) is slowly but steadily decreasing, it may indicate that the team:
1. May have started sacrificing code quality to meet deadlines or
2. May have deliberately built some temporary solution to speed up experimentation.

After that, there are some examples of good and bad metrics, but the most useful part for me was the link to the Scrum Checklist by Henrik Kniberg. This is a PDF that you can print and then ask the team to assess all the criteria.
Eventually, the aggregated data from this checklist will be a good metric for the team.

Writing clearer error messages

https://uxdesign.cc/writing-clearer-error-messages-d57d6f388140

This short article shows several examples of good error dialogs and describes why they're good. It covers not only common sense such as avoiding using "Ok" in action buttons, but also using the correct tone (depends on how serious the error is) and putting the right amount of information into the message.

I'll stop here because it's only 4 minutes to read.

Lessons from 6 software rewrite stories

https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

Unlike the previous one, this article is rather a long-read. Medium estimates it as '30 minutes', but it's worth it.

Herb Caudill challenges a popular opinion that rewriting a working application is the biggest mistake that companies can ever make. To do this, he goes through 6 different examples:

1. Netscape
2. Basecamp
3. Visual Studio & VS Code
4. Gmail & Inbox
5. FogBugz & Trello
6. FreshBooks & BillSpring

All the examples above are non-trivial: there is no classic story about rewriting an application from scratch and deprecating a previous version. For example, Basecamp decided never deprecate previous versions, and Inbox became a way to experiment with new features for Gmail.

The main takeaway here is that rewriting has more than one execution strategy. Not rewrite at all may be a valid decision too.
And, of course, the last example about FreshBooks is my favourite, don't want to spoil the twist here :-)

Bye!