Make the hard decision. Either we’re going to fix it and we do it now, or we aren’t and we cancel it.
Letting that bug sit in a backlog somewhere in the hopes that someday we’ll have the time and interest to fix it is just delusional. We’ll never have time for low priority distractions, and keeping things around “just in case” is exactly that.
Most companies have hundreds, and I’ve seen systems with thousands, of bugs just like this. They’re noise that distracts us. We need more focus and clarity, not more distractions.
Fix the bugs, or accept that we won’t, and close them.
Indecision is waste.
]]>My argument is that code coverage is a great negative metric, in that at low values, it tells you useful things and at high values it tells you nothing. So mandating high numbers is not giving us the benefit we think it is, and in fact is often causing people to game the numbers.
Fresh off that, I just made a change to one of my own source files that had 100% code coverage, and no tests broke.
No, this was not an attempt to prove anything. I was fully expecting one or more tests to break when I did this.
The fact that nothing broke is quite honestly shocking as I thought this code was quite well covered. It does prove my point though.
Code coverage is great feedback to developers; it’s an indicator of where they should put their attention. It should never be a target.
Update: And to the surprise of nobody who believes in good tests, as I add more tests around this particular code to cover the edge cases that were missing, I’ve just found a bug.
]]>Your first contact with details on sprints is likely to be in the issue history. In here, there is information about what sprints this issue is in.
What’s that you say? “How is it possible for an issue to be in multiple sprints?” If it doesn’t finish in one sprint and that sprint ends, its still considered in that one forever. Then you can add it to another sprint and now it’s in two. Repeat as often as you like for a never-ending set of sprints for a single issue.
I’ve seen issues that have been in over a dozen sprints because they never get finished and just keep carrying over from one sprint to the next. Yes, that’s completely dysfunctional and should never happen. Yet, it happens all the time.
The entry in the history might look like this.
{
"field": "Sprint",
"fieldtype": "custom",
"fieldId": "customfield_10020",
"from": "76, 79",
"fromString": "Sprint 12, Sprint 13",
"to": "76, 80",
"toString": "Sprint 12, Sprint 14"
}
The first thing you might notice is that there is a fieldId, which most history items don’t have. This is a reference to the custom field (in the same document) that contains more information about the sprints that are referenced. That custom field may or may not exist. If it does exist, it will list information about one or more sprints and the sprint that you care about may or not be in that list.
Got it so far?
If it does all exist, it will look something like this, and you’ll see that it contains some useful information about the sprint such as start date, end date (which isn’t what you think it is), and completed date.
You might think that endDate is when the sprint actually completed but no, that’s completedDate. endDate is the date that you anticipated closing the sprint at the time you started it. Why are there two? I assume it made sense at one point.
"customfield_10020": [
{
"id": 10,
"name": "Scrum Sprint 10",
"state": "closed",
"boardId": 2,
"goal": "",
"startDate": "2025-03-12T01:36:46.600Z",
"endDate": "2025-03-23T17:32:42.000Z",
"completeDate": "2025-07-13T16:58:25.335Z"
},
{
"id": 43,
"name": "Scrum Sprint 11",
"state": "closed",
"boardId": 2,
"goal": "",
"startDate": "2025-07-13T17:37:23.922Z",
"endDate": "2025-07-25T09:33:21.000Z",
"completeDate": "2026-01-22T16:02:01.486Z"
},
The next thing you might notice is that unlike every other history type, the from and to values allow for multiple values.
{
"field": "Sprint",
"fieldtype": "custom",
"fieldId": "customfield_10020",
"from": "76, 79",
"fromString": "Sprint 12, Sprint 13",
"to": "76, 80",
"toString": "Sprint 12, Sprint 14"
}
You might think that this history entry is telling you which sprints this item has been added to or removed from and in a roundabout way, it does.
You can see in this sample that this issue was in sprints 76 and 77 and is now in sprints 76 and 80. It’s always talking about the current state so we can infer from this that…
76 and still is, so nothing changed79 and now it isn’t, so it’s been removed.80 and now it is, so it’s been added.When you’re parsing those, it’s pretty easy to parse the from and to fields because they’re just numbers separated by commas.
The fromString and toString fields are harder though because it’s all concatenated text, and since commas are allowed in sprint names, you can end up with commas in the middle of a name.
“Surely they would escape the commas in the text so it can be easily parsed”, you say! They do not.
If you want unambiguous names, you need to parse the id and use that to index into the data in the custom field above. Of course, we’ve already learned that the sprint you want may or may not be there.
If it isn’t there then we have a separate API to get sprints, which is great. Except that it may not be there either. We’ll get there in a moment.
There’s a lovely gotcha where an issue can be removed from a sprint before it was ever added. This happens when the issue gets created within the sprint. Jira considers it to be in that sprint but there is no record of it being added in the history. Then if it’s removed from that sprint, you’ll see the removal all by itself.
This API will return all (mostly) of the sprints for the current board.
/rest/agile/1.0/board/{boardId}/sprint
{
"maxResults": 50,
"startAt": 0,
"total": 1,
"isLast": true,
"values": [
{
"id": 1,
"self": "https://improvingflow.atlassian.net/rest/agile/1.0/sprint/1",
"state": "closed",
"name": "Scrum Sprint 1",
"startDate": "2022-03-26T16:04:09.679Z",
"endDate": "2022-04-09T16:04:00.000Z",
"completeDate": "2022-04-10T22:17:29.972Z",
"createdDate": "2022-03-26T16:03:49.814Z",
"originBoardId": 2,
"goal": ""
}
]
}
I’m sure you’ve picked up by now that even this API doesn’t return all the sprints, although it often returns more here than we have in the custom field.
In my testing so far, it seems that it does return any sprint that actually has an issue in it. Any sprint that’s empty will not be returned, which is annoying.
So in conclusion, like all the other Jira API’s, there is useful data in here but its inconsistent, incomplete, and poorly thought out.
Other articles about the Jira API:
See also the JiraMetrics tool, which is the reason I’ve had to learn the idiosyncrasies of the Jira API. If you just want access to the data then let JiraMetrics do it for you.
]]>“You’ll turn left just past Flieler’s”, where for the last twenty years it’s been called Sunoco, or “turn just past where the Johnson’s used to live”.
If you live in the community, it still works because everyone knows how it used to be. The problem is when you’re new to the community or if you’re just passing through. Then these descriptions are just meaningless or worse time-wasting.
I’ve been reminded of this over the last few weeks as I attempt to learn Google Ads and all the documentation is very precise in telling me where menu options used to be, and how things used to work, and is absolutely useless at telling me what I need to do today.
It’s all too easy when writing documentation to treat it as one and done work. I wrote it and won’t have to change it. Yet, incorrect documentation is much worse than no documentation. If I’m driving down the street looking for a sign that says Flieler, I’m going to drive right past the Sunoco sign and not even know it.
So when we write documentation for our products, we have to also consider the cost of maintaining that documentation. It will get out of date and if we don’t keep it in sync, we are wasting our clients time and money.
I did finally figure out how to get my ads campaign running, just as I finally did figure out how to get around that small town. It just took far longer than it should have.
If we’re going to call ourselves customer focused, we need to consider how much of our customers time we’re wasting.
]]>Everyone is hyper-focused on completing the single task in front of them and all distractions are ignored or removed.
Then when the emergency is over, we all drift away, back to our regular desks to work in isolation again. Typically scattering our focus across many different things, and now significantly less effective than we had been. The pressure is off so we revert to our familiar routine.
The above tells us that we all know how to work in a highly collaborative environment. We do know how to work together and we do it instinctively when the stakes are high, and it’s really important to get the work done quickly and correctly.
We already know how to work in a really effective way, even though we rarely do.
So why don’t we work that way all the time?
First, I would be remiss if I didn’t acknowledge that some teams do work this way every day, and they get amazing results. They’re just not the majority. See teams that do ensemble work or pairing.
So why don’t we?
It’s not rewarded: We’re not rewarded for focusing on a single thing until it’s finished. We’re rewarded instead for starting things. We’re rewarded for juggling many things at the same time. We’re rewarded for being busy, rather than effective. Worse, we’re often rewarded for putting out fires but not for preventing them.
It’s comfortable: Working by ourselves has no social pressure. We’re not concerned about others judging how we work or what we do. As long as we look busy, we’re left alone. It’s a simple routine and routines make us feel calmer and safer.
It’s the standard: Nobody will ask us to justify why we choose to work by ourselves; that’s the default. They might ask us to justify why we would work any other way, even when the default approach is less effective.
We already know how to work better. Perhaps it’s time to start doing that.
]]>Yet, the practices themselves weren’t intended to be end-states. They were merely the best practices that we knew about at the time, and today we know about a number that are even better. Continuous delivery and ensemble/mob programming weren’t even a thing at that time and yet they’re both completely in line with what XP advocates.
The really important thing about XP is really in understanding where the “extreme” in the name comes from. The basic idea is that if we believe that a practice or approach is good then instead of doing it a little bit, let’s turn it up to extreme levels and do it all the time.
When we introduce some of these practices today, we often get push-back on the specific practices, while missing the intention behind it. If you don’t like the specific practice that we’re doing, then find a different way to turn the good up to extreme levels.
XP is “extreme” because it doesn’t settle for “good enough”. That seems like a positive to me.
]]>Too many teams try to pick the “perfect” piece of work for the ensemble, and when they do, they inevitably pick something that nobody really cares about.
We’re not doing katas or fake examples. We’re not picking up that item that you’ve wanted to do for the last year but never got around to.
We’re picking something important enough that we would have done it this week anyway.
That could be implementing a new feature request, or fixing a bug, or performance tuning. The actual type of work doesn’t matter. What does matter is that it’s something that we care about finishing.
]]>At the first, they said “The old system was written in Java and Java is unusable so we rewrote it in C# and now it’s great.”
At the second, they said “The old system was written in C# and C# is unusable so we rewrote it in Java and now it’s great.”
These statements can’t both be true at the same time. In fact, both Java and C# are reasonable languages and either one would have done the job. It wasn’t the language/platform that was at fault, no matter how much these companies told themselves that.
Does this mean that the platform is never the problem? No, there are legitimate cases, usually when we’ve built on top of proprietary vendor systems, when ongoing licensing and/or support costs from that vendor make it untenable to continue funding that code base. These cases are exceptionally rare however - I’ve seen two in my entire career.
What’s significantly more common is that we ignored quality in the product for so long that eventually we gave up and decided to rewrite it from scratch. We often call this technical bankruptcy - that point where it’s so painful to work with the existing system that we give up.
You might be thinking that we would never consciously choose to ignore quality and usually we don’t. It’s all those unconscious points where we prioritize something else over quality, that gets us in trouble.
I’ve written about quality before, and today I want to stay more focused on the notion of a big rewrite.
I’ve seen cases where people are starting to talk about rewriting a system before the first system is even in production. They’ve made such a mess of the first product that they realize already that it’s not usable over the long haul and needs to be replaced.
Then what happens is that we rewrite the product on a new platform, and at the beginning, the new code is really easy to work with and easy to extend. However, by the time this new system is ready for production, it’s often in just as bad shape as the first system.
How could this possibly be? How could the new system be as bad as the one we’re replacing?
The simple answer is because all we changed was the code itself. We didn’t change our practices around quality. We didn’t change the way we write code. We didn’t do anything different on this second attempt than we had done on the first attempt. We might have a different design approach and a different language but all the things that led to poor quality code are still in place.
Since we never tried to improve the original code in place, we never developed the practices that lead to high quality code. We just did the same thing all over again, and got the same result.
Like the quote that is often attributed to Einstein: “The definition of insanity is doing the same thing over and over again and expecting different results”
If we want better results, we need to build the skills that will lead to those better results. Throwing away a large code base and replacing it, does not teach the skills for building high quality code.
To develop those skills that will lead to better quality, we need to actively improve the code we have. The next time someone proposes throwing some code away and rewriting it, we need to say no. Improve it gradually instead.
We also need to be constantly practicing the skills of improving code. We should be refactoring constantly to improve that code, not just touching it when there is a new feature to add.
The Scouting Rule says that we should always leave the campsite cleaner than when we arrived. Applied to software, that means always leaving the code a little bit better. Did you see some duplication? Remove it. Did you see poor variable naming? Fix it.
If we do this regularly then we’ll never get to the point of a rewrite. I’ve seen ten year old code bases that were a pleasure to work with, and six month old code bases that were a disaster. Consider which one you want.
]]>If you see duplication in the code, then remove that before you leave the method. If you see poor variable names then fix those before you leave.
What we don’t talk about as much is how a culture of branching and Pull Requests (PR’s) actively discourages making small changes for that purpose. If I want to rename a method to make it clearer and know that making that little change is going to require real effort to go through a review process and manual merges, then I’m more likely to decide to just live with the original name, even if it is is poor.
Whereas if I can make that little refactoring and directly check it into mainline then it’s a very low effort change that contributes to the quality of the product. It’s become easy to do the right thing.
How many things do we have like this, that actively discourage us from doing the right thing?
]]>First of all, let’s consider what is really the goal. We often find ourselves talking about testing rather than quality and that leads us down the wrong path. Testing is not the goal and never should be.
Why would we focus on the wrong thing? It has to do with a psychological phenomenon called attribute substitution, where in an attempt to reduce the mental effort required, we replace a complex decision with a simpler decision and aren’t even aware that we’ve done so.
Quality is a difficult thing to get our heads around so we simplify the problem to testing and focus on that. Yet, most of what we call testing happens too late in the process to actually improve the quality. See this article on quality vs testing for more.
The best we can hope for with typical testing is that we’ll identify when we need to go back and rework the product. If we want the testing to actually improve the quality then it needs to happen during creation of the product, not after the fact. This is the essence of techniques like test driven development where the testing happens before the code is even written.
What we normally call testing is an inspection step, not a quality one, and as Deming says: “Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product.”
If we want to improve quality then we need to focus on quality. The moment we start talking about testing, we’ve taken our eyes off the ball.
If you ask the typical team what a bug is, you won’t be able to get a clear answer. We talk about bugs all the time and yet we all seem to have different ideas of what they are.
I have a clear three point definition for a bug. I don’t insist that anyone uses my definition, but I find that many teams do, because they don’t have their own.
It’s a defect if:
All three are important. If someone insists that it’s broken because it doesn’t do something that we never talked about, it’s not a bug. If we didn’t understand what it was supposed to do, then it’s not a bug when it doesn’t do that thing.
Why it’s important to have a clear definition of that bug, is that every bug is a place where we said we’d finished the work and we didn’t.
Having it so clearly defined will change the whole conversation around prioritizing the fixing of bugs. A bug is something that we’d already prioritized, and already decided to work on but stopped before we were finished. If we’d finished it, there would be no bug.
So now if someone asks if we want to talk about prioritize bugs, it’s really a matter of “do we want to finish this thing that we’d already decided was important enough to have started first, or do we want to do this new feature that was clearly less important because we’re only looking at it now?”
Yes, I realize that priorities change and the newer thing might really be more important, but most of the time that isn’t true.
When you realize that those bugs really are more important than new features, you’ve just taken the first step towards a zero defect policy
You may now be thinking “What if we don’t want to fix it?” Then close the bug. Why are you leaving it in the ticketing system if it isn’t important enough to finish? Yes, it really is that simple.
Have you ever sat in a bug prioritization meeting? You’ll never get that time back and that meeting was 100% waste. Either fix the bugs or decide that you won’t, and cancel them. Trying to prioritize one against the others is a waste of everyone’s time.
That last point in the bug definition of “the team said they were done” has one more interesting implication. We don’t ever open a bug if the story is still showing as open, which means that we can never have two tickets open for the same thing at the same time.
At many companies, Pull Requests (PR’s) are treated as if they were a quality step, and yet in the most common cases, they aren’t. PR’s are an inspection step that happens after some portion of the code is finished.
Can a PR be used to get feedback in the moment, to help with quality as the code is being built? Absolutely yes. Unfortunately, they’re almost never used in that way — instead they’re used for inspection and gate-keeping.
The common case for PR’s is that we create one and send off an asynchronous request for feedback. Then we move on to some other work because we know it will be at least hours, if not days, before we get any feedback. If we were actually using the PR for the purposes of improving quality, we’d want immediate synchronous feedback.
There are certainly people who use PR’s this way. Where they create the PR as a way to see all the changes in one place and then immediately review them with someone else so that they can get feedback that will then inform quality.
The asynchronous model, on the other hand, is a handoff. We’ve said that we’re finished and want someone else to approve it. This is now an inspection step.
]]>