Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays, page 3
40 essays in the archive
-
The cost of un-fixed bugs or Good Code on top of Bad Code
While discussing with a colleague we started talking about the costs related to not fixing a bug immediately (yes, this does mean that you have a way to immediately figure out if you introduced a bug). The reason for fixing bugs immediately is not only the cost of content switching later on when you have …
-
The hard reality of life as developer…
If any of this is familiar, then you should really be reading this blog! 🙂 Hug a developer today. Blogged with the Flock Browser
-
Testers are developers! Stop breaking them apart
First one clarification. Testing is needed, required, critical and very much a MUST. With that out of the way let’s go to the post. Many people have mentioned the need to include testers in Scrum or agile, and planning your processes with a testing step somewhere (normally close to the end). All of these ideas …
-
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 …
-
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
-
Respect for people, the translator’s edition
In the spirit of Lean my colleague and friend Mika Pehkonen writes how they are able to respect people, get them to do what they are best at and most motived to do. I’d say that’s a win-win-win situation! we pay our translators by the hour, not by word count. This means that the translator …
-
End the never ending design discussions: Timeboxed estimation for User Stories, a pattern in Agile adoption
In this post, Jason explains one common problem with the estimation and planning sessions in Agile teams. The problem he describes however, is quite common and has lead to implementation of the Separate Design and Requirements anti-pattern in the traditional software development world.So I thought I’d write a pattern about a simple and common solution …
-
Story points explained, a good addition to the timeboxed estimation pattern
Just after writing the post about about Never ending design discussions I found one post from Lasse about story points. I think these two posts go very well together, as story point-based estimations is what I use for the Timeboxed estimation pattern.
-
The Proxy Product Owner, a pattern in Scrum adoption: version 1
Below I try to describe a pattern that I’ve faced and have seen in other teams in the context of an Agile transition.See the explanation section for more details on each of the sections in the pattern.If you have faced similar situations let us know of your own story in the comments below. Proxy Product …
-
Separation of design and requirements may have destroyed more software projects than waterfall…
The people that convinced us to never mix design with requirements may have wrecked more software projects and destroyed more value in the software industry than anyone else! Just think what happens when you separate requirements from design: You don’t validate assumptions to more than a very superficial level (the “I don’t care about the …
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.