The semicircle (episode 9 -- What is to be done ?)

le 26/01/2018 par Christophe Thibaut

Since practical computation demands that implicit assumptions be brought out into the open, it is no coincidence that computer programmers are attracted to an approach devoted to studying how people make assumptions. -- Gerald Weinberg.

number: 4240 date: 08/29/2017 status: in progress type: bug severity: serious submitter: C. COURDEL nature: partial budget carry forward does not work description: I skip the budgeted year, perform a partial carryover, option: without exceeding, I submit the form, nothing happens! Owner : _ Resolution status: _

You've just opened ticket 4240 and you're reading through the description, mumbling. We'll have to call Claudia. You wonder if it would be worth trying to reproduce the bug before calling her, just to know a little more about it_(and then you'll feel less stupid when you have to ask her for clarification)_. You have no idea what happened.

You find yourself again as if in a dream in front of the massive bleak building on this deserted street. Five floors. All windows are shuttered with brick. Rain runs along the cracks in the mortar that was covering this beige brick wall. It's both depressing and worrying at the same time. You have to go back inside. Login, password.

You sigh so loudly that Jeremy hears you. "You okay?" "No, not at all." "Are you on ticket 4240? For all we know Claudia Courdel might not have the right dataset. That's why it works for us but not for her." "Oh my, how brilliant you are..."

Three seconds of silence lasting two minutes.

"If that's how you want to take it..." "I dunno, we could actually look before deciding..." "I'm just hypothesizing..." "No. You're giving your opinion. A hypothesis would be if you said: I would like to demonstrate that the defect occurs in Claudia's environment but not in ours. I will start by comparing the two relevant tables in both databases. If they are identical, I would look at the recently imported files, and then..." "You're mincing words."

Pause. I never touched any of the code in question. And, in any case, it's not my fault. But right now, I just need to be right. So I'm getting angry with the only person who can help me on this ticket.

Jeremy focuses on his screen. He looks tense.

You get up, moving closer to Jeremy and you say to him, "I was angry. And I was saying whatever. I'm wrong, I take back what I said, it was bad, sorry." "No problem."

Silence. You take mental note of things you've got to do today. Or at least before Wednesday.

Are you really going to start on this ticket? I thought you had to draw up an action plan to put an end to these quality problems, along with an estimate for its implementation. It's urgent! And there is also the redesign of the budget module, which everyone agreed to work on together, remember?

Through the window you can see the usual traffic congestion on the avenue at 8.30 am. "I need a coffee. Time for yours too?" "I'm working on something..." "Can I bring you something?" "No thanks."

On the way to the kitchen area, you think back to the dream that you were having when the alarm went off. You realize that if you write the dreams down just after you wake up, you remember them lots better.

It takes place in a bowling alley. It's a game between two teams and it's not going well. You're on one of the teams, the one that loses. You've done nothing but gutters since the beginning of the game. You stand in front of the track. A feeling of embarrassment. You're looking for a face sipping a stale beer. One of the players - you don't know who he is, his face is blurred - is sick of your mediocrity - to a point where he throws his bowling ball into the scoring monitor screaming 'Now we're going to see which team is the best!' And you wake up.

Of course, the kitchen area is a mess. The sink is overflowing with all the coffee cups from yesterday afternoon. You wash some of them. You dry them. At your service.

You calculate.

Let's see, 51 tickets, at the rate of... at the rate of how many hours per ticket? I don't have a clue. Perhaps between 2 and 4 hours per ticket? Not to mention the time to redeploy, not to mention the meetings in between... But no, some tickets don't even take 10 minutes.

You make yourself a coffee, then get up - leaving the space to a particularly noisy threesome that just arrived. You go back to your office. You're blindly relying on coffee to get some mental clarity. You open your notebook and start a list.

Never seen a morning this slow.

You're calculating. You ask Jeremy:

"Jeremy, how long does it take to resolve a ticket?" "It depends on the ticket."

Obviously.

You find a better question. "To resolve a ticket, how many different things does it depend on?" "Don't understand." "What are the factors that affect the time it takes to resolve a ticket?"

Farid, who is starting his PC says. "Good question. There are quite a few, but the most important thing is: is the ticket a bug or an enhancement."

Jeremy adds, "Is it a calculation problem, a cosmetic problem, or something in the data..." "Can we reproduce it easily?" "Does the person in charge of the ticket know the relevant part of the code?" "Yes, that should always be the case." "It should be, but it isn't necessarily the case." "If you own the ticket: you should know the code. Otherwise you risk making things worse." "Ideally, yes." "Ideally, there would be no tickets." "It would be easier to estimate that way." "So who is taking care of it is one factor." "Not who is taking care of it, but: does the person who is taking care of it know the code." "The time elapsed since the ticket was logged." "The quality of the code where the problem is found to be."

You write down all these factors in your notebook. You add, saying loudly, "Whether or not the code has tests in the area exhibiting the problem."

You suddenly lose yourself in muddy thinking. The cup of coffee isn't working. You continue, "How do we estimate the ticket turn around time here, Jeremy?" "You've been here long enough now, you should know that: we use the guess-o-meter." "Ah." "Right, well - actually we don't ask ourselves how long it will take." "But I've got to ask this question."

Farid asks, "Why?" "Maria is asking me how we can be sure that no new quality problems will show up in the next release. Or in subsequent ones." "And how are you going to do it?" "Right now, I have no idea. But it would be useful if we could brainstorm it together."

Jeremy, without moving his eyes from the screen. "And wham!.... Another meeting."

We're tied.

Audrey is first to enter the meeting room. Ghastly neon. Pastry crumbs all over the table. "Thank you for the empty coffee mugs and crumbs. Geez!"

You bring up the topic in a neutral tone. "OK. Maria is asking us to solve the quality problems before the next release, which takes place in exactly three months, and this is her number one priority. She needs to know what solution we are considering and what it will cost."

Jeremy asks, "What does she mean by quality problems? I have an idea, but I would like to know your point of view."

You connect to the PC in the room, and look for the bug tracker icon while explaining. "There are currently 51 tickets pending or in the process of being resolved. This is more than the total number of tickets we had on the prior prod release, and we're only 60% finished with this new release."

Farid continues, "Again, not everything is a bug. We should triage everything before diving into solutions." "Of course. In fact I wonder if it's worth resolving all of these issues." "What?" asks Audrey. "I think it'll take more than three months to fix them, even if we spend 80% of our time on them." "If you intend to deliver a buggy release and get out of the demo alive, you still have some learning to do around here..." "That's one way of looking at it. But no one should be held to an impossible goal." "So what's your view, would you be in favor of leaving some bugs in the product?" "Audrey, I imagine you noticed that some tickets appeared because of some new defect caused by a 'fix'?" "Yes. That doesn't happen a lot. What are you proposing we should do?"

The atmosphere is tense. Your internal barometer reads: "Knots in the stomach. Tense, with possibility of rants." You shouldn't have had this third coffee. It may not be a coffee issue. You answer the question. "I propose that we find preventive measures in order to improve our process, and that we present them to Maria, so that she can validate our strategy and help us to put it into action."

"Correcting the bugs isn't preventive?" "Right, it isn't. You wait for the bugs to appear, you analyze them, and then you correct them. Where is the prevention in that?" "Ok. If we did a little more testing..."

Jeremy interrupts Audrey. "No, I have to stop you there. Even for a trivial program, such as a simple calculator - if you want to have complete coverage, i.e. to execute all the possible paths in the code, at least once, by combining all the possible entries, it would take you an almost infinite amount of time." "Almost infinite, that's meaningless." "What I mean is that we can't test everything." "So you now mean let's not test anything." "Not nothing! We have 26% coverage! But if you want to go have fun testing everything, it's your choice." "We have 26%, so 74% of the code is never verified. But we can't test everything, so let's not worry about it."

You sense that this isn't the first time that Audrey and Jeremy are raising their voices with each other.

Audrey adds hastily, "As if you were saying: biking will never go as fast as the train. So let's walk." "Whatever!"

You reread your notes: Bugs - enhancements Tests - almost infinite - 26% - nothing - everything

In this imposing building, enduring under the rain, there is a large room on the fourth floor that was probably used to store equipment. An indescribable sense of disorder permeates. This room has one peculiarity. On one of the windows, the plank boards used to block access aren't well mounted. If you could crawl up there, you might be able to use a crowbar or even a long enough screwdriver to dislodge one of them. You would then notice that it's actually dark outside too. What's the point?

Farid tries to tame the debate by changing the subject. "Whether we test or not, as soon as we write software, we have bugs, that's life."

Audrey fires back, "Screw up a demo, or even get fired, that's life too. We could try to not get fired. If we can accomplish that, I'm in." "We're not going to get fired." "That's not the point. The point is: are we declaring defeat in the face of the bugs or are we looking for a better way of working?"

You finally got to connect to the bug tracker on the PC, and open the request that you had concocted last week. You ask the team to pay attention while you point out the table up on the screen.

"Here is a summary of all open and resolved bugs on the previous release to production, by ticket type."

Jeremy comments, "I didn't know that 'documentation' was a type of bug."

You think about your last conversation with Oleg. You say, "Not all incidents occur because of a defect in the code. A defect in the documentation can cause an incident." "I see."

You continue, "We are missing some crucial information in this bug tracker: the time spent to fix a bug."

Jeremy says: "Easy. It's the time elapsed between the moment when the bug is assigned to an owner and the moment when its status changes to solved." "Yes but that data isn't filled in. There's a creation date, but there's no date for when the bug is assigned or for when the ticket is resolved." "Just read the history table for the ticket modifications." "How do we do that?" "Right here, right now? It'll take a little time..." "When exactly could we do that?" "You can't access the history table in normal mode. You need access rights to those tables. It's Mazare, from prod, who showed me that." "When can we go see him?" "Almost anytime. Except Friday." "Why not Friday?" "On Friday, Mazare is super busy. He's even having lunch in front of his screen." "Busy doing what?" "Checking that no one is putting anything in prod."

Audrey gets up. Everybody rises. Audrey mumbles as she leaves. "Geez. This company... some days I..."

(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