The semicircle (episode 10 -- Either ... or ...)

The Eye-Brain Law: To a certain extent, mental power can compensate for observational weakness. The Brain-Eye Law: To a certain extent, observational power can compensate for mental weakness. Jerry Weinberg

"I received your email. I get what you want to do. But, what's the goal?" Comfortably secured in a state-of-the-art ergonomic seat, and protected by a natural fortification of edible, combustible, destructible, fungible, flexible, securely-fixed, decay-prone, sensitive and transmissible elements, Mazare observes both you and Jeremy. Jeremy answers, "We would like to analyze the lead time for bug resolution using queries that the bug tracker interface doesn't offer out of the box." "Is it a S.R.?" "An S.R.?" "Special request. There's a form to fill out. This gets you access to the services in those situations where you want to look at data that doesn't belong to you." Jeremy raises his hand saying: "Stop right there, in this case, it's our data. "In the bug tracker tables? I don't think so, no." "This is our application. These are our bugs!"

Mazare hesitates. You return your attention to the inventory-taking of the visible part of his office, which his first question had interrupted. Mazare scribbles a password on a repositionable sticky note and while handing it to Jeremy, says: "Point taken. Go take a seat at back of the room."

You go sit next to Jeremy. "It was easy." "Mazare is a friend. I'm doing him a favor on monitoring."

In less time than it would take to even put a dent on the subject of monitoring, Jeremy has queried two tables, retrieved the answers in a spreadsheet format, placed the files on a shared drive, disconnected the session, ripped up the password and put the chairs back in place.

"We have what we need."

Thirty minutes and two joins later, Jeremy's spreadsheet displays the information you were looking for. id   | issue                  | date_1     | date_2     | d1-d2 0313 | Data transfer broken...| 2015/11/11 | 2016/01/04 | 54 0321 | Pb Dialogue box "cho...| 2015/11/13 | 2015/11/16 | 3 0476 | Calc err res.S1 v S2...| 2015/11/16 | 2015/11/20 | 4 0477 | S2 result err. w/o S1  | 2015/11/16 | 2015/11/20 | 4 0480 | "unknown vers" in mo...| 2015/11/18 | 2016/02/03 | 77 ... ... 1397 | incorrect msg after ...| 2017/04/06 | 2017/05/02 | 26

You ask, "If you select all the version 4.3 tickets, that's to say the version prior to the one we have in production right now..." "So all tickets from November 2015 to May 2016." "Yes. What's the average time between entering a bug and resolving it?"

Jeremy adds a formula and the spreadsheet displays: 9.390625

Jeremy adds another formula and says, "With 65 tickets in 181 days, we consistently have between 3 and 4 tickets being worked at a time. What are you getting at?"

You don't know. You've never been very comfortable interpreting numbers. You ask: "What about version 4.4?" "So from May 2016 to October 2016... "

8.753433

"What about the current version?" "You mean the version under development?" "Yes. It's been four and a half months, something like that." "123 days, with 51 tickets. Not all tickets are resolved, however." "What is the average resolution time?" "10.235475, that's between 4 and 5 tickets in process at a time."

You're thinking out loud. "On the version under development, not only will there probably be more tickets in total, but the resolution time will be longer. So...." "So...?" "So the team will end up with more tasks than time to complete these tasks. A bottleneck." "You're making an erroneous assumption: the lead time for resolution is the time elapsed, not the time worked." "What difference does it make? There are approximately 210 working days per year. Multiply all figures by a factor of 210/365. What difference does it make?" "That's not what I mean. You don't spend 10 days on each ticket. The ticket stays in the pipe, but that doesn't mean we're working on it all the time." "I repeat, what difference does that make?"

This conversation is creating something of a déjà-vu impression, an aftertaste, a mixture of uncertainty and feverish naïve questioning. The banter of suckers who don't have enough data but who have already bet too much at this table, and who nevertheless try hard to guess what is actually going on.

"Hello...?" "Sorry. Yes. What difference does it make? These ten days are the usual rhythm at which we do things. Whether the ticket waits 2 days out of 10 or 8 out of 10, it comes down to the same cause: it's because of everything we do in addition to the ticket resolution: development, meetings, etc." "For all we know, bug fixes won't take as long this time." "And why would bugs take less time to fix this time?"

Audrey and Farid, who had come for the 10 o'clock break, are standing behind you looking at the same numbers. Audrey intervenes. "If we each put our heart into it, there has to be a way!" "What exactly do you mean: put one's heart into it?" "Make an effort!" "I'm going to assume you mean by that, do more, i. e. waste less time. Where do you think we could save time?" "I don't know!" "Because that's what this bug tracker request hasn't been able to tell us, thus far."

Jeremy insists. "I insist: we are not certain that it will take us as much time in this version as in the previous one." "Oh, really? What has improved in the way we work since the prior version?" "Well, we already know a little bit more about the system and the business." "But we have a little more code, and things got a little more complicated in the data model."

Farid intervenes calmly. "What we need to know is where the delays come from." Audrey says: "Okay, but how do we find out?" No one knows. Instead of making random assertions, you remain quiet. I've made enough bets at this table.

Jeremy closes the spreadsheet, launches his IDE and knowingly concludes: "Either we take on fewer stories, or we take on fewer bugs." Audrey's heads for the coffee shop. "Wow, what great ideas you have."

Farid brings his chair closer to Jeremy and asks him, "By the way, do you have a few minutes for a code review? I fixed the 4237, but I would like to make sure it holds up." "OK. Remind me which module is it in?"

They're inspecting the code. You are watching them distractedly. You think: you just need to know how to deal with the code in this project. To know which doors to open and which doors not to open, which obstacles to get out of your way, and what not to touch, under any pretext. And that's how we would survive in this code base: by staying just on the surface, like skaters on a lake, who would have perfect knowledge of areas where the ice is too thin. Making at most some cosmetic changes here and there, but without putting anything at risk.

You refocus on the conversation at hand. Farid explains, "I have changed almost nothing, just this variable that becomes a field, and..." "Stop. There's a bug here." "Are you sure?" "You take the value of the field before calling checkCompleteAmount, so you don't use the method that splits the key in half." "Huh?" "You are aware that this field is used as a primary key, right?" "Maybe..." "For sure. And so your key value will conflict with an already existing period value." "What? I don't know what you mean." "OK. Let me give you an example: the key value is the day concatenated to the month." "OK." "And we have, say, the 1st of November which merges with the 11th of January, because '1' glued to '11', produces the same value as '11' glued to '1.'" "Holy cow!" "Yes, holy cow. With this code, you are adding budgets from different periods."

You interrupt. "How much time did we just save?" Jeremy and Farid look at you confounded. You continue. "We just identified a bug, didn't we?" "Yes, answered Jeremy, so what?" "Assume that the review you just did didn't take place, how much time would have elapsed before this bug appeared?" "Appear where?" "That's my question."

Farid's tries to answer. "We don't deploy to the acceptance environment until Friday. By the time Charlene runs the tests again..." Jeremy intervenes, "What tests? I doubt if the current test suite contains any test case that would produce this bug." "Then it could only be detected by some customer. In November, for example."

You're counting on your fingers. "After the ticket is first entered: the time to reproduce the bug would be, say, 4 hours." "At least." "Understanding what's going on, changing the code: 1 hour." "Running the tests..." "Let's add an hour. Removing the old code and delivery of the new code: 1 hour." "You forget that you also potentially need to repair the customer's data. The last time that happened, it took us half a day." "We're already at 10 hours. We just saved 10 hours."

Farid approves. "Fair enough. We should be doing code reviews more often." Jeremy intervenes. "Why do reviews more often? Reviews are a time sink." "If a review like the one we've just done can save us something like 10 hours, I'll be glad to invest a little time." "But it isn't true that each review will reveal the same kind of bug!" "No, but with what we're going to find on average, we could be winning." "I don't see how!" You jump right in: "Can't you see how an hour of double proofreading just saved us 10 hours of work? If you can detect a defect instead of letting it slip into the production release and having to correct it later..." "The reason I saw this bug is that we had a similar incident two years ago. It's a coincidence. Doesn't mean all code reviews are going to be as successful."

You rub your eyes like as if to chase away a building migraine headache. You're back at the game table. In the middle of the clutter. Players are allowed to make any comments they deem relevant, they can draw any conclusions they want. There is never enough information or else there is too much variation. And the code is rotting. It is becoming less and less clear. But the players keep betting, making guesses, and betting again. They get into debt, and it is always the (complexity) bank that wins in the end.

You go back to your seat, affirming, more for yourself than for the rest of the team, "It might be worth it."

(to be continued) Previous episodes : 1 -- If the code could speak 2 -- See/Advance 3 -- Communication Breakdown 4 -- Driver/Navigator 5 -- Brown Bag Lunch 6 -- Takeaway Tips 7 -- Crisis/Opportunity 8 -- The Fifth Floor 9 -- What is to be done