Skip to the essays

Improving the world with software

Better software. Better questions.

Essays on software development, teams and the craft of building things that last.

Essays on Code

40 essays on code

  1. When “Don’t Repeat Yourself” Makes Code Worse – Learning Elixir And Re-learning Recursion

    Thanks to a conversation with Erik Schön, I was learning Elixir while waiting for my plane back from DevLin 2025. I decided to go through the Roman numeral kata to slowly get into Elixir. When the algorithm was coming together I hit this interesting moment where I saw a lot of repetition, and asked Claude …

    4 min readcode

  2. A detailed comment on the practice of estimation in Software Development – a #NoEstimates post

    OK, so a friend (who shall remain anonymous) sent me a message with some very good points bout estimation. This blog post explores those statements. It will be long, and detailed. Grab a cup of coffee, sit down and let’s do this! The first thing I’d like to comment on is the statement My start …

    3 min readcode

  3. Estimates anchor (limit!) benefits while not limiting costs! – a #NoEstimates blog post about value delivery

    Estimation and estimates are a dreadful way to run a business. The basic idea is this: Estimates anchor benefits while not limiting your costs at all. Let’s look at this statement in parts. The second part (“estimates don’t limit costs”), is self-evident. Anyone looking at the track record of software projects will see the evidence. …

    3 min readcode

  4. Hire generalists to help your specialists shine!

    Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in …

    4 min readcode

  5. Kanban vs Scrum, the ultimate fight? Don’t think so, here’s why:…

    Wow, what a week! A BIG post (Link removed at the request of the author) on Kanban by Scrum evangelist [unammed at the requset of author] litterally put the blogosphere (and twittersphere on fire!). It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: “These …

    2 min readcode

  6. Patterns of Agility, talk at Scan-Agile 2011 and Agile Riga Day 2011

    Some time ago I wrote a post here about Patterns we can identify in projects and how they relate to the life-cycle model in use for the project. Some patterns are definitely signs of an Agile project (release working software at the end of every *very* short iteration for example). Other patterns are clear signs …

    1 min readcode

  7. Another job opportunity for 31337 h4x0rs that love testing!

    F-Secure is hiring! And they have some interesting positions as well. Check out this one: People who have experience in “SW Engineer in Test” type of a role. This is a fairly new role and not well established in Finland. The discipline is young and top notch professionals rare. An excellent niche to put yourself …

    1 min readcode

  8. To all my friends and colleagues at Nokia, my contribution

    Without a doubt many of you have read the news about Nokia taking Windows Phone 7 as their main Smartphone platform. That decision by Nokia has a tremendous impact in my local software community: Finland. Nokia mobile phones (as it was known before) has always been a major employer of software development professionals in Finland …

    2 min readcode

  9. SWAT Team, a Pattern for Overloaded, Multi-project Organizations

    We all have seen it in our projects. Some teams are overloaded and can’t deliver what we need while others are not so busy and could even tackle more work if there was a need for that. This type of partial overloading is easily understood if we picture the work flow as a network of …

    8 min readcode

  10. Patterns of Agility. How to recognize an Agile project when you see one…

    Instead of fighting about “who’s agile” or “who’s more agile than whom”, it would be useful to create a set of patterns, that once recognized would help us define if we are or have been able to successfully implement an Agile life-cycle for our project and portfolio. These patterns or symptoms are useful for us …

    8 min readcode

  11. What can we learn from illusions that helps us manage projects better?

    Just had the opportunity to watch a BBC documentary about illusions. The show went on to detail how we as humans get deceived by our own senses. There were 3 things that opened my eyes in that documentary: The things that caused me to think were: when we mix senses one of them tends to …

    2 min readcode

  12. And the mobile OS winner is…. Linux!

    And suddenly the smart/super phone market is getting crowded with proper OS-platforms based on Linux! This is a new one from AAVA Mobile (demo by Intel), a new comer to the mass market stage, but already providing a very cool device (HW-wise) with a powerful OS (Moblin – Linux based and supported by Intel). If …

    1 min readcode

  13. Intel everywhere? Programmers will like this…

    This year’s CES is presenting us, software/programmer types, with a very rosy picture of the future. A good example of what I mean is the push that Intel is making to the mobile phone segment with it’s Moorestown platform. Imagine a world where you can easily port all of your work to a new platform …

    1 min readcode

  14. About when I stopped worrying and embraced Engineering!

    Product Managers often forget that they can make or break a project. If your team is using Scrum that is even more true, because Product Managers are (or should be) involved regularly in the planning of the work with the team. Either as Product Manager or in the role of Product Owner. It is therefore …

    2 min readcode

  15. PMI vs. Agile, what is different, and why should we care

    The PMI people don’t seem to stop trying to “guess” what Agile is. Guessing is the right term, because anyone with more than a few hours experience in Agile software development can see their cluelessness from afar! Take this article by Lynda Bourne DMP, PMP (no, I’m not making those TLA’s up, she uses them). …

    2 min readcode

  16. The CMMI folks are out to get you! Seriously, they are starting with Scrum, what’s next?

    The folks talking about CMMI and Scrum are dangerous! Not the least of which because they miss some of the most basic points about software development! You would think they would know about software, but you would be wrong! Check this out: In an article about CMMI and Scrum the site ExecutiveBrief (go there at …

    1 min readcode

  17. Does Toyota really use waterfall for software development?

    I saw this post and could not resist leaving a comment. Here’s what I wrote as a comment to that post: How can they [Toyota] apply waterfall and be predictive, fast and high-quality? Those are all qualities that waterfall lacks. Predictability is lost because of lack of visibility into quality until it is too late …

    1 min readcode

  18. The Software quality hash tag #swquality

    If you do Twitter you probably know exactly what I’m referring to, if you don’t here’s an article you should read. Together with @most_alive and @Mendelt we just coined a hash tag to aggregate discussions about the cost of quality in software development. The hash tag is #swquality just add that to every tweet that …

    1 min readcode

  19. Perfection in software is cheaper! not more expensive…

    The fallacy of perfection = expensive has many forms. Two of which I just run into in the blogosphere. What is this fallacy? Simple, you say to yourself: “perfection in software development is way to expensive, therefore I should not even try to achieve it!”, but that’s a false problem, because perfection is only expensive …

    6 min readcode

  20. What is a bottleneck? (TOC)

    When faced with a problem in a process, the first step you should take is to identify the process map and bottleneck. This is nothing new, TOC people have been advocating this for a very long time as part of their “5 focusing steps“. But if it is why don’t we do it? Well, because …

    1 min readcode

  21. The “it’s not my bug” anti-pattern

    Talking to a friend we were discussing the organization of feature teams in a local company. They were previously organized in component teams, which led to a lot of inefficiencies and disconnected work. This happened because one team would only work on one component, and when one feature required work in many components, that feature …

    2 min readcode

  22. The Skill issue, the industry shame

    I was reading Jason’s blog when I came across this post. I could not agree more. Way too many times I bump into problems that can be traced directly to the idea that you can hire just anyone, with any skill level and they will perform to the expected level of professionalism. This is pure …

    1 min readcode

  23. Apple on unfair claims in advertising

    Part of being a cool company is that you respect your customers. This is not a show of respect by Apple. Seriously, this is just used car salesman tactics. Apple, shape up!

    1 min readcode

  24. Continuous integration requires a good SCM

    Lately I’ve been discussing SCM (Source Control Management) systems and how that impacts the continuous integration efforts of the teams and the projects where they work. I could not have expressed this better than Dean Wampler, check his blog post out.

    1 min readcode

  25. 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 …

    1 min readcode

  26. 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

    1 min readcode

  27. 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 …

    2 min readcode

  28. 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 …

    1 min readcode

  29. 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 …

    1 min readcode

  30. 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 …

    1 min readcode

  31. 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

    1 min readcode

  32. 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 …

    1 min readcode

  33. 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 …

    5 min readcode

  34. 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.

    1 min readcode

  35. 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 …

    5 min readcode

  36. 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 …

    3 min readcode

  37. Testing to script is waste, creative testing is extremely valuable

    Testing is a hard job. Imagine this, you have to make sure an application of more than 2 million lines of code is ready to ship. It all depends on you, and your team of 2 testers. How do you do it? Well, one way to do it is to make sure you cover all …

    2 min readcode

  38. Adaptive Path discovers Apple’s Mojo, but Toyota got there first

    In a post called “Apple’s Design Process Through a Keyhole”, the blog over at Adaptive Path mentions one technique used at Apple when designing product. The basic idea is that in Apple, designers come up with 10 possible designs for a new feature (and I bet more than 10 for a new product). Then diligently …

    1 min readcode

  39. On the subject of problem solving, and problem root causes

    Problem solving is key to the discipline of software development. What we do when we code/test/release a software product is essentially problem solving. We learn about a problem we analyze the root causes and then we come up with a solution. This post by Brett Schuchert reminds us that very often the apparent causes of …

    1 min readcode

  40. Nokia is missing the bus, why the N96 is not good enough

    Disruptive technologies don’t always come with revolutionary new technology or feature-packed packages. And this is no different with the iPhone/Nokia debate going on today after Nokia failed to impress with the announcement of the N96 multimedia phone. The fact is that Nokia is missing the bigger point and the proverbial bus. One year after the …

    2 min readcode

Keep the conversation going

The essays work best in company. Join the community to keep the questions coming.

The #NoEstimates book and its companion volumes

Chapter 1 · Free PDF

What if better planning started with a different question?

The first chapter of #NoEstimates argues that the “deliver on time” challenge is answered by a different question. Read it, and see whether it changes how you plan the next piece of work.

Free PDF of chapter 1. No purchase, no library access. How we handle your details