Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays, page 18
314 essays in the archive
-
Why learning is important (or why you should attend Scan-Agile ’08). The story of grandpa Tony and grandpa Francis
I’ve come to realize lately that today’s ability to learn is similar to last centuries ability to read. Confused? Let me tell you a story.One of my grandfathers (let’s call him grandpa Francis) knew how to read, he was able to keep up with the latest developments in agriculture and even read the weather forecast …
-
Belief without proof is dangerous!
Believing in some far-fetched (or indeed any) explanation without having any proof is dangerous. It is dangerous in the case of the flat-earthers and it is dangerous for project leaders and team members. Whenever a theory emerges why something works (or doesn’t) in your project/company, it is your duty to either prove it right or …
-
Great description of Agile planning sessions
Lasse has written a great post on estimation using the Story Point concept and the Planning poker practice. Some time ago I also wrote a post on how to make these Planning Poker sessions timeboxed but still effective. If you are interested in estimation and planning in Agile Software Development these posts are worth a …
-
The value Black Swan (or the killer improvement in software development)
Thinking back to how we value our work, we must recognize that, in software, quantity is not value! The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) — or in Black Swan (TBS) parlance: velocity is a variable from …
-
Why Apple should watch out or lose it’s newly acquired customers
Apple had a considerable amount of credibility when they started they iPod “offensive” some years ago. So much credibility that people were willing to overlook critical customer-back stabbing such as the iTunes being DRM ridden, the iTV (ooops, apple TV) being more expensive in Europe even if there’s no content for it at all in …
-
Windows Vista as secure as planned, not much… (or Plans don’t work, working code rules!)
One of the fundamental problems with Security is that if you change something in your code (anything) you are increasing the risk of a security vulnerability being created and later found. Now, if you consider that, and know what Microsoft changed a lot of code in Windows Vista before releasing it, it’s clear that something …
-
The new skill paradigm
In the past we hired managers because they could “keep the people under control” and they could “get things done no matter what”.Although the first one is clearly in contrast with the self-organizing nature of Agile, some people still believe the second one… Well, I propose that the most important skill for managers today (in …
-
Spreading the happy flu, an experiment to study epidemics (meme-style)
In the interest of science (studying epidemics dynamics) I’m posting this “spread the happy flu” post. I got the happy flu from Henrik Mårtensson.
-
The iPhoto conundrum
Like me many people have bought their first mac lately. Like me they’ve also been very happy with the whole package (hardware + OS + software). But here’s the problem: if you have liked the iLife suite as much as I do you are probably running out of space in your MacBook Pro (MBP) even …
-
Time is our most precious resource, use it sparingly
In the follow up of GTD (of which I’m a big fan) and the “Four hour week”, or even “Zen to Done”, here‘s a piece to make you think. You and me are “knowledge workers”, that means we “process information” into value added knowledge, processes, software, designs, you name it. One thing that we are …
-
For a better format for User Stories
Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was: As a <customer role> I want <functionality> because <customer value explanation>. Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly …
-
How much should you keep the code checked out, before the team kicks you out?
“Some developers keep their code checked out for a really long time… Like a day or so”— Craig Larman, lecturing on feature teams From Jeff Atwood’s blog, a similar argument. Blogged with the Flock Browser
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.