Estimates in Software Development
What are estimates (as in: delivery time estimates in software engineering) good for? Those making them mean them as, well, estimates indeed, while those hearing them all too easily fall for mistaking them as guarantees, which dissonance will lead to interesting misunderstandings and consequences.
Let’s be clear: I understand them as expertly informed guesses that come with a confidence score. Implicitly, it’s clear that the confidence score is higher the closer the estimated date is. Still, it’d be good to always communicate the confidence along with the date.
It’s important to keep them updated, too. Nothing’s worse than a dearly held belief or assumption that all of a sudden is shaken up by a late change. Transparency rules: regardless of whether the confidence changes, or the estimated date - it needs to be communicated.
Tags: work
Eat This, Dunning-Kruger Fans
I learned that the Dunning-Kruger effect apparently suffers from itself. Or proves itself true. Or false. Or whatever. And that also means I, insofar as it is concerned, have myself suffered from it, in spite of its inexistence. This is all very confusing but funny.
Tags: misc
Vacation Pragmatics
(This post is written from the perspective of the German labour work legislation, but applies in spirit elsewhere.)
What’s the value of vacation?
When employers request their employees to take as many as possible of their remaining vacation days in the current year instead of carrying them over into the coming year may give raise to that question. This is because some people have a habit of scheduling vacations in small bursts (say, sprinkle their vacation day budget over a multitude of single days), or of carrying over a vast amount of days into “next year”, and risking to lose some.
The value of vacation is to give employees time to rest. Properly rest. Take their minds off of work. As much as someone may enjoy their job (as do I), it’s simply healthy to not be concerned with it for an extended amount of time every now and then. Or to at least shift the focus of a major part of waking hours from work to something else (as do I - I’ll freely admit: I’m almost never 100 % offline).
This is why we have vacation days, and this is why the German federal vacation law (yes, there is such a thing) is very strict about them: employers need a good reason to deny a vacation request, vacation is to be granted contiguously, and it must be taken in the year it accrues in.
What’s a good reason for denying a vacation request? Urgent operational needs, for example. When the person requesting vacation is really necessary to get something done that is important to get done during the requested time. Say, a software release is scheduled, and the release manager doesn’t have anyone trained as a deputy. (There’s a job for the manager to do here as well, for sure.)
Contiguous vacation? Oh yes. It’s not considered proper resting if it’s scattered over multiple single days. It better be several week-long absences. No one is going to convince me otherwise - not taking proper time off will have an impact, even if it’s maybe delayed. Resting is an important component of burnout prevention.
Take it in the year it accrues in? Yup. Vacation days may only be carried over if the company really could not grant vacation to someone, or if the employee simply could not take vacation. There are few good reasons for both of these cases. The latter one is, especially, not justifiable by the plain desire to save some days.
Vacation is important. It really is. Let’s take it seriously.
Tags: work
Ambitious Achievers
Being really good at a job does not mean it’s easy to scale to a bigger responsibility. Many excellent engineers who were “promoted” to management can confirm this. So can countless others who, given a new, bigger responsibility, start to fail very visibly and painfully.
The Peter Principle captures this, and is neatly summarised like so: everybody rises to the level of their own incompetence. Dawn Springett, in a piece on LinkedIn, covers the idea too, framing it as being about what she calls Ambitious Achievers. In her piece, she also expands on how the very skills that brought the Ambitious Achiever to this new place may easily turn into obstacles in the new context. Springett’s suggestions focus on the organisation: ensure that promotions are done for better reasons than technical skill alone, and that people skills are properly developed.
I agree with all of that, and would like to add a remark for the perspective of the Ambitious Achiever.
Those excellent skills are part of the reason that brought you to this new and much wider scope. You have developed them in a context that perhaps did not change much in nature: you’ve scaled them up. Now it’s time to build new skills. But that’s not it, the skills that brought you here don’t end here: you can scale them out. What do they look like “a level higher”? What will change if you impart some of them on people you work with?
The bigger your scope becomes, the more you need to build on relationships. Make sure you invest in those; make sure you work hard to understand the people in those relationships, and what their interests and constraints are.
Most importantly: the people who offered you this responsibility did so because they believe you can do it. So have courage.
Tags: work
Scythe
A friend of our son’s was over and brought a board game that the three of us tried: Scythe. The game is set in an alternate-1920s scenario where several empires are competing for territory and resources. It has a steampunk aspect in that large robotic devices (“mechs”) can be constructed and deployed.
Here’s how the board looks at the end of a game.
It’s instantly apparent that Scythe has a high degree of complexity. That’s to be expected: it’s a strategy game. Players have to balance different kinds of resources - money, materials, work, base and extended fighting power, and reputation - to achieve several goals. Ultimately, the player who first fulfils six goals ends the game, but without necessarily also winning it: the ensuing final evaluation takes multiple factors into account that contribute to each player’s score.
At first, each player controls a small amount of territory and has no mechs at their disposal. Four of those can be built - once the necessary resources are available. These can be obtained by establishing new settlements in territory that yields resources when the player does a production activity. Initially, players are also unable to cross water bodies (rivers and lakes). For that to be possible, a player needs to build a certain type of mech that enables wading through rivers or submerging in and crossing lakes. Players can also build tunnels, which enable them to move about the board more swiftly.
When one player’s mechs and/or leaders encounter another’s, a fight will ensue (of course). The fighting mechanics have an interesting twist in that the visible fighting power is amplified by (invisible) add-on fighting power. This makes for interesting surprises. The likelihood of such encounters increases very swiftly with the number of participating players.
One nice twist is that players cannot perform the same moves in two subsequent rounds, necessitating some careful planning ahead. This brings me to the conclusion: Scythe is a nicely strategic game with a high fun factor. The strategic aspect is way less hefty than in, say, Terra Mystica, which makes Scythe much more accessible than the former. The competitive aspect is strong in Scythe, but does not dominate: players don’t spend all the time fighting; the emphasis is more on balancing resources and one’s approach.
Warmly recommended.
Tags: games
Castles of Tuscany
At one game night with my board game buddies, we played a round of The Castles of Tuscany. Sorry, no pictures this time.
The game’s concept is simple: you’re running a principality, and have to build castles and cities, roads and fields, mine for marble, and so forth. By doing so, you accumulate wealth, which means you can win against the other players. So far so good - and note that there is no warfare in this game, no attacking of other players. In fact, the only cause for conflict can be the competition over resources. (I have to say I appreciate that.)
Players can unlock several kinds of bonuses (up to four) by building cities, e.g., the capacity to have more workers, or keep more resources in stock. Each of these have a considerable impact on a player’s strategic abilities, so the player should plan ahead which bonuses they want to unlock. There are also bonus points for many different things, such as being the first player to have built three castles, or making all the fields arable.
The game mechanics are an interesting mix of deck building (bonus capabilities) and worker placement (applying abilities and resources). What makes the game very fluent is that it’s practically impossible to be played into a corner. There is always something one can do. Also, because the individual moves are short, consisting of just one action, the pace is swift.
I’ve mentioned the lack of inter-player conflict. Indeed, players compete for resources only, and a little bit for achievement bonus points, which deplete. Other than that, there’s no real conflict: no fighting, no stealing. This lack of interactions between players can lead to a certain dullness. As a lover of cooperative games, I don’t mind it that much.
Overall, it’s a very nice game with a good flow, and can be learned quickly. Warm recommendation.
Tags: games
Microservices as a Non-Solution
Felix Seemann here shares some interesting thoughts about microservices and why they’re used. In brief, bad architecture and design aren’t addressed by throwing microservices at them.
Ever heard of ravioli code? Microservices decouple code bases, which means that issues are much, much less apparent at compile time. Unless the architecture is very well understood, decoupling per se doesn’t improve things.
Seemann recommends hexagonal architecture as a paradigm to be considered when working in microservice settings.
Tags: work
Policies
Company policies exist to provide guardrails for the company’s operations. They set boundaries and clarify what’s OK and what’s not OK. This is meant to protect the company from things like data loss, fines, lawsuits, bad business decisions, wasting money, cultural toxicity, and so forth.
Since a company exists only through the people working there, the policies impact what people can and can’t do. Some of these restrictions might not make sense from an individual perspective, but they most likely do in the company context. Some restrictions might make things complicated, be uncomfortable or annoying.
However, finding oneself in disagreement with a company policy, taking it personally is not an option. It’s not about “you”, after all. Asking the right questions to understand what it’s about will be better. There usually is a very good reason.
In case there isn’t - or isn’t any more -, the question is a good way of unearthing that, and having the policy revised. Asking to understand is, in such cases, still much better than plain complaining and protesting.
Tags: work