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.
]]>I hadn’t been following this story but as I understand it, Tricentis had purchased the open source project SpecFlow back in 2020 and had been offering it as part of their lineup. They have now discontinued the project so the original authors have forked the codebase under the new name Reqnroll and will continue to support it there.
More background on this here.
So if you’ve been using SpecFlow, it’s time to upgrade that to Reqnroll.
]]>It’s common to hear during the debrief that people enjoyed it and that they learned something and that they feel the quality of the work was better but “we went so much slower”.
What makes that so interesting is that on the occasions that I’ve actually tracked how long we’ve taken to get the work done, it’s been at least as fast, if not faster, than if we had split the work up and had each person work individually on their part.
To be very clear what I’m saying, if there are four people working in ensemble, they will complete as much in a day as those same four people working individually for a day. This is really counter-intuitive for most people; we naturally assume that four people working together will only be as productive as one person working individually.
The most dramatic example of this was just recently with a team that completed as much work in two days as an ensemble than that same team did working individually in the following eight days. Effectively being four times as productive when in an ensemble. What makes this particular example even more astounding is that this was the first time they’d ever worked this way, and they didn’t think they were going very fast at all.
That example isn’t typical in my experience but what is typical is that we are at least as productive together in an ensemble than when all those same people were working individually. Yet it always feels as if we’re moving slower. Much slower.
So when people say that ensemble work, or pairing, is slower then I encourage you to actually measure the results. Don’t just rely on how it feels. That feeling is deceptive.
A couple of notes:
I’ve introduced hundreds of teams to ensemble work over the last decade and can help your teams get started.
]]>Yet if we apply that principle blindly, as beginners often do, we can end up painting ourselves in a corner by not looking ahead and considering what might be coming. If we don’t think about tomorrow then we might end up making decisions today that actually make tomorrow much harder than it needs to be.
Doing YAGNI well does require us to think, at least a little bit, about the future while only implementing today, what we need today.
For example, if we are building a shopping cart app, we might find that today we only need to put one item in the shopping cart. If we apply YAGNI blindly then we might implement our database with only one possible field for an item, rather than as a collection. That would require rework the moment we want to add the second item. If we think ahead for even a moment, we would realize that a shopping cart should contain a collection of items, rather than one.
YAGNI is an exercise in focus, not an excuse to stop thinking.
]]>We would have the normal way, where everything went through a long testing cycle and there were checks and balances to ensure we weren’t going to break anything. It often took weeks to get through this path.
Then there was the hot-fix approach where we tried to contain the change to the smallest possible thing and crossed our fingers that nothing would break. This allowed us to get to production almost immediately but it came with extremely high levels of risk. We’d just bypassed all of our checks and balances, after all.
I see far fewer companies relying on the high risk hot-fix approach today and that’s a significant win. We’ve largely done this through an increased focus on quality and through extensive automation of both testing and the build/deploy pipeline.
That results in the normal process to be sufficiently fast and reliable that there is no longer any need for hot-fixes.
If today, your company still can’t deploy a change to production both quickly and safely then it’s time to consider why that is.
]]>We can agree that mocking as a concept is useful, while strongly criticizing mocking frameworks.
In general, mocking as a technique is widely overused. There are situations where it absolutely makes sense and situations where it clearly does not. When it’s really easy to create mocks then we tend to create more of them than we should, and also use them inappropriately. This is where the criticism is justified IMO. Mocking frameworks makes it really easy to do the wrong thing so we do more of the wrong thing.
Note that when I say “mocks”, I’m using that word to describe all of mocks, stubs, fakes, spies, etc. The idea is the same across all of them.
What’s an example of doing the wrong thing?
Here’s a case where a mocking framework was used to override the getter method when we could have first just called the setter. I’ve seen this one in real code.
// Using the mocking framework foolishly
Customer customer1 = mock(Customer.class);
when(customer1.getFirstName()).thenReturn("Amy");
// When we could have just used the object as it's
// already designed to be used.
Customer customer2 = new Customer();
customer2.setFirstName("Bob");
I’ve seen codebases with dozens of lines of mocking setup for each test, simply because they could. The developers gave no thought to how to decompose the application into more testable pieces because the mocking framework made it too easy to continue supporting a poor design.
You may be thinking that we shouldn’t be blaming the tool, and there is some truth to that.
Unfortunately, these are tools that encourage sloppy thinking and lazy design and that’s a real problem. We need more thinking, not less, and tools that encourage the wrong things are a problem.
Mocking is a useful technique to have in your back pocket. It’s not a technique that we should use blindly, without thinking.
This is an example of a psychological phenonomenon called Attribute Substitution where we are faced with a computationally difficult decision, we will often substitute a more easily calculated decision in it’s place and answer that instead, without even realizing that we did this. ↩
Test Driven Development (TDD) has been around since at least the 1950’s. There’s a paper written for a NATO conference in the 1950’s that describes this technique. It doesn’t used the words “test driven development” but does describe the approach.
Pair programming has been in use since the early days of the mainframe. Admittedly, they weren’t using it for the same reasons we are today, but it was in use. Back then the cost of the computer was so much more expensive than the cost of the humans that we paired people up for cost savings.
Mob programming is fundamentally the same approach that we’ve used for decades when we fire-fight production issues. Everyone comes together and works on the same problems at the same time. The only thing that’s different is that we’re now continuing to use the technique after we’ve put out the fire.
I was personally using feature flags in the 1990’s and they weren’t a novel idea at that time. They weren’t as fancy as what we have today but we implemented the same approach.
Trunk based development was the norm before Git came along. Creating multiple branches was possible with earlier version control systems but it wasn’t commonly used. Some might argue that starting to use branches was an improvement but that’s highly debatable in general and I personally disagree.
Continuous integration and continuous delivery have been around at least since the mid-1990’s, although the latter didn’t start to become popular until about 2010.
None of this is new. All of these techniques have been around for decades and have a proven track record.
]]>When I talked to them about improving their delivery process, they assured me that they had no need for that. “We only deploy once a year so it doesn’t matter how long it takes to test or how long to deploy the code into production.”
So I asked them what would happen if on that one day that their code ran, they found a critical bug. “Would it be ok if you waited until the following year to try again, or do you need to try again immediately?”
That’s when it became obvious to them that their ability to get changes into production quickly was just as important for them as it was for a team that deployed multiple times a day.
Being able to get changes into production quickly and safely is important for every team, no matter how often you want to actually do it.
]]>He first suggested that we test with Leap Day (Feb 29) as testing with an edge case like this can uncover some subtle bugs. I’d been bitten by bugs like that before and had known to test for this particular one.
Then for the next test, he suggested that we test with 2:00am and I was puzzled by that. Why 2:00am?
“Because not every day has one”.
If you’re a typical developer, you may be scratching your head right now. If you’re a typical tester, you know immediately what I’m talking about. Not every day has one.
Good developers and good testers think differently. They approach the problem from different angles, and find different kinds of problems. We need both perspectives to really ensure quality.
That’s not to say that one person can’t learn to see the problem in both ways. We absolutely can and we should. The trick is that the two ways are different and each of us has a preference for one over the other.
If you haven’t figured out the 2:00am yet, it’s daylight savings. Once a year a day doesn’t have one at all and once a year a day has two of them.
]]>What do we really mean when we say Zero Bugs?
Zero Bugs is a policy where we have decided that if a bug is found, fixing that will be the team’s top priority. That we will not start new feature work if there are known bugs in the system.
Terminology: Some teams will say that defects and bugs are different things. I consider them to be the same. Anywhere I say “bug”, you can freely substitute “defect”.
People often jump to the conclusion that we mean “our product has no bugs” and that is likely impossible and certainly not what we’re saying. Having said that, if the team has been following a Zero Bug policy for a while, it’s likely that there are very few bugs left in the system anymore.
I’ve seen multiple teams for whom “we haven’t had a bug reported in production in years” is a reality.
A common question is “what if the business doesn’t want the team working on these bugs?”
Consider that every bug is actually unfinished work. We had implemented some feature in the past and the fact that it’s not working properly now means that we didn’t finish that work. Had we finished it, it would now be working.
So what we’re really asking is “what if the business doesn’t want us to finish that feature that they’d previously asked for?”
If they’re happy with the existing behaviour then it’s no longer a bug so close the ticket. If it is a bug then finish it.
The key point is that if they want it fixed, we fix it now, not later.
“What if we have hundreds of open bugs right now? We can’t possibly stop everything to fix them all!”
If you have hundreds of bugs open then likely your team is seriously demotivated by that fact. They have also probably stopped caring about the quality of the product. If so much is already broken and nobody cares about that, why would I care if another bug slips through. This is known as the broken window effect.
Go through the list of bugs you have and make a decision about each. Either decide you’re going to fix it or delete it. If you’re going to fix it then do it now.
The teams that I’ve worked with that implemented a Zero Bug policy, tended to be happier and more productive than teams that didn’t. This should be the standard and it baffles me that anyone pushes back on it.
See also: Definition of a bug
]]>Hashtable object was inefficient if it had to grow in size beyond the default.
As I recall the situation, the default size of a Hashtable was 101 and the hashing algorithm that was being used relied on the size being a prime number. It was faster for prime sizes than for non-prime. 101 is prime and so it provided good performance. If the Hashtable needed to be resized ever and ever larger, it very quickly became a non-prime number and performance would degrade.
The advice that the book recommended was to start with an initial size of 89 as starting from there would yield prime values for many more resizings as the collection became larger.
This notion appealed to me, so for years I littered my code with new Hashtable(89) instead of just new Hashtable(). Clearly this is better, right? Wrong.
At some point (I think Java 5), they re-implemented the Hashtable class and the new algorithm favoured a size that is a power of two.
Had all my code called new Hashtable(), I would have got a nice speed increase right out of the box. For no extra work, my code would be better. But my code didn’t do that. I’d decided to be clever and had hard coded it to 89, which is very much not a power of two.
This is a perfect example of premature optimization. Had I focused on leaving my code maintainable and easy to read, it would have improved as the libraries improved. Instead, I had decided to be clever and actually made things worse. The interesting thing is that I didn’t make it immediately worse, I’d left a time bomb that would make it worse when the code was upgraded to a newer version of Java.
Learn from my mistakes. Don’t optimize the code until you have a measurable performance problem. Until that point, write maintainable code, not clever code.
]]>