Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.

When I read the content of this article I wonder how useful the metrics really were. I mean clearly they helped the team realize which changes to bring... but the practice changes were all somewhat conventional in a way. You go a long way when you focus on quality and create the space for it.

This is clearly not a great outcome. The browser monoculture probably doesn't help.

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

Maybe we could store metrics about the code in the history as well? This would indeed reduce vendor lock-in. This tool makes it easy. Unsurprisingly seems built upon git notes.

Interesting musing about the "software crisis" which was declared in the late 60s. We're coping with it by piling levels of abstractions but clearly we're still not out of it. Our craft still needs to grow.

Good reminder that those two aspects are not necessarily competing which each other. In the long run quality improves productivity. In the short term it might as well.

No, your model won't get smarter just by throwing more training data at it... on the contrary.

Definitely a good idea, we'd need several such institutes across the world. Would governments be willing to try this?

Interesting study on the impact generative AI can have on people performances in business settings. There are a few nuggets in there. In particular anything related to problem solving people do worse with generative AI tools than without. And even worse than that when they've been trained (probably due to overconfidence). The place where it seems to help is for more creativity related tasks... at the individual level, but at the collective level creativity decreases due to homogenization. Definitely things to keep in mind.

Indeed, don't mindlessly add tests. I find interesting that the doubts raised in this piece are once again concluded using an old quote of Kent Beck. What he was proposing was fine and then over time people became clearly unreasonable.

Something is definitely bonkers regarding the use of JavaScript on the web. The amount of bloat is staggering.

Faster with less effort doesn't seem to lead to quality code overall.

Understandability is indeed a very important goal. There are easy ways to improve it in a system.

This study does a good job looking at the impact of community smells over the presence of code smells. This is an excellent reminder that the organization influences greatly the produced code.

Interesting study, the amount of bugs which could have been prevented by the introduction of static typing in Javascript code bases is definitely impressive (15% is not a small amount in my opinion).

An interesting interpretation of what was behind the "move fast and break things" motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.

Shows why it's important to go for a blameless culture, also outside of postmortem. This is definitely not easy but worth it.

This is a good set of properties to strive for. Since the SOLID principles start to show their age this might be a worthwhile alternative.