A co-worker recently helped me understand why requirements usually don’t work in practice. Non-technical customers will inevitably come up with very fuzzy requirements and usually only have a vague idea of what they really want. Customers with technical knowledge, on the other hand, have more often than not already thought out a solution and will not even bother to describe the problem they are aiming to solve. So what can be done about it?

Will a new feature add value or decrease it? A common danger to many software engineering efforts is feature creep. This is when we keep adding new and shiny features to our product, potentially rendering it less and less useful as we clutter the interface and makes harder and harder to find the few features that actually made our product valuable. A related problem is scope creep. This is when the stakeholders keep coming up with new requirements, delaying the project’s launch date more and more.

In Swedish, “efficiency” and “effectiveness” are both translated into the same word. With Swedish being my mother tongue, this leads me to sometimes mixing these terms up. This article describes the difference between the two concepts, and why both are important to understand. The influential author Peter Drucker defined the difference between being efficient and being effective in the following way in his management book The Effective Executive: The Definitive Guide to Getting the Right Things Done:

The Whole Value Pattern is a pattern first described by Ward Cunningham in 1994. It simply implies that a value should always be stored together with its corresponding unit, which together forms a “whole value”. A lone numerical value is usually not meaningful on its own, without a corresponding unit, and is therefore a violation of this pattern. The main benefit of following the Whole Value Pattern is that implicit developer knowledge can be made explicit in the codebase instead.

Being a consultant, I’m quite used to switching projects and thus have had a bit of practice in handing off a project to other developers. This has led me to a range of conclusions that I think can benefit every serious software engineer, consultant or not. I would like to summarize these findings into the “last week mindset”, or; if this was your last week on your current assignment, how would you spend that week?

Rewriting a large piece of software from scratch is usually not a good idea, regardless of how messy or problematic the original/legacy code is. The reason is that you never know how long the rewrite is gonna take, what unexpected problems you might run into or even if your new solution is gonna be any better than the old. You might end up spending several months on refactoring without any possibility of releasing anything into production until the rewrite is complete.

Welcome to my blog on software engineering! In my daily work as a software engineer, I read and think a lot on various topics and also write a lot of notes as I do so. My main goal with this website is to gather some of my notes in a single place and in a slightly more readable format. By making everything public it feels like I force myself into cultivating my thoughts and ideas into a more concrete form.