The semicircle (episode 7 -- Crisis / Opportunity)

Managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other. I call such situations messes. Problems are extracted from messes by analysis. Managers do not solve problems, they manage messes. Russell Ackoff

A chat window opens at the bottom right. Maria: come to see me when you can for 15 minutes today pls.

You save your work, answering: I'm coming. You grab something to write with.

Maria invites you to take a seat at the small round table filling the small space she was allocated, closes the door and sits down across from you.

"While you were meeting yesterday, three new tickets appeared. Did you see them?" "Yes. It's from the last delivery, the one from Friday." "4236: 'When submitting the form, I get an error message in red, mandatory field. All my fields are filled in. Can not validate the form.'" "We've looked at that. I can explain but it may take time." "4237: 'The Contracts pane doesn't open automatically after validating the Address pane in update mode.'" "There I'm clueless. Probably the flow is confusing." "4238: 'The sales report contains blanks in place of the total amounts, this problem has been reported and corrected in the previous version, but it appears again in this version.'"

You are dumbfounded.

Maria continues. "These tickets are putting the project behind. What shall I say at the next Steering Committee Meeting?" "You could tell them that we have a structural problem with this part of the application code and that we will have to invest a little time in its design before we can return to normal..." "That's not what they want to hear."

Breathing. You are tempted to answer, but you feel that the discussion is already complicated enough. No need to add missing interlocutors or imaginary answers.

Maria continues, looking you straight in the eyes. "I hired you to solve problems, not to create new ones. I thought your approach to problem solving would get us out of trouble, not push us in even deeper."

Breathing. This is an interesting conversation to debug. With patience and meticulousness. Remember. Patience and meticulousness.

"My approach is to avoid creating new defects as much as possible when I update the code, but that does not mean that I master all the code." "I get that."

Breathing. What would make this conversation more effective would be me not feeling so threatened. What would work would be me feeling confident in the possibility of extracting this bug, reproducing it, diagnosing it, and correcting it once and for all.

If only she knew how much this has nothing to do with who is touching the code or which principle of problem solving is being used. This code base is a random labyrinth, plunged into darkness. Some parts are flooded. Each rescue attempt causes further landslides. There is nothing to do, only to pick up debris here and there, and move them a little further away.

You say, "It's not so much a question of who changes the code, or which approach to adopt. It's more a question of having maneuverability." "What do you mean by that?" "Take global warming, for example." "Not sure that is a good example." "OK. These three new tickets: I hear you would like to get rid of these problems. If only we could make these problems disappear." "That's what I'm asking you to do." "These tickets are not problems to solve, they are symptoms." "So what?" "What you're asking me is to suppress the symptoms more effectively. But doing that will not change the root cause." "What is the root cause?" "Would you mind if I make another analogy?" "No." "Good. Think of a guy who has major health problems. He is overweight. His heart is failing. He's had a heart attack. His doctor is performing the checkup. He explains to his patient that during the last twenty years, he hasn't had a very healthy lifestyle: food too rich, far too little exercise, and most importantly, a pack of cigarettes a day!" "OK..." "The doctor prescribes: 'Stop smoking. Start being a bit more active. Not too much, don't fool yourself. A healthy diet. Alcohol out of the question.' And the person answers: 'Yes doctor, but not right now. I just need you to put me back in shape because tonight is the corporate anniversary and we're getting ready for a hell of a party.'" "That's ridiculous." "What I mean is that the problems within this application won't be solved with a few bug fixes. The time to remedy this problem is proportional to the time it took for the problem to appear, namely several years." "Well, that remains to be proven!"

You don't know exactly whether Maria is feeling more angry, impatient or anxious. But you can't find the courage to ask her.

You continue. "We're talking about two hundred and fifty thousand lines of code." "It must be possible to produce code that doesn't contain defects! Can't you at least explain to your teammates what needs to be done?" "The world would be very different if all that was needed was to explain how to fix a problem." "Spare me the philosophy. I'm talking about bugs in production, seen by beta testing customers! There must be something we can do for heaven's sake!"

Breathing. It's as if you had just invited your manager to make a foray into the obscure mazes of the code. Like the others, she bumps forcefully into the invisible obstacles, but she interprets this experience very differently. She was imagining a simple functional space, a well thought out architecture. She reasons in terms of plans, projects, results. She didn't expect to find so many floors in ruins, no light, no elevator, no stairs, nothing to hang on to.

You continue. "It can be helpful to explore 4236, if you have a little time." "I have exactly eight minutes."

You open your notebook and you sketch a form. "We reproduced the bug, and we did a complete post mortem. When the user enters data in the form, one of the options, when checked, brings up two new fields. If they are present on the screen, these fields are mandatory. The user begins to enter one of the two fields and then changes the option again. Both fields disappear. The user submits the form, which triggers the validation logic on the fields. The controller sees that one of the two fields is entered and deduces that the other field should also be entered. 'Mandatory field' appears at the top of the page. If the field in question was visible, it would also appear in red. The user is forced to enter a field he doesn't see."

"That's idiotic! How did we get into such a situation?"

"In the previous version, we didn't have an option to check. Instead we had three fields, say A, B and C for short. B and C appeared depending on whether A was filled in or not. For the controller, the rule was: When the field A is filled in, the fields B and C must also be filled in. Field A has been replaced by a check box. The controller was then modified: the rule became: when the field B is filled in, the field C must be filled in as well. But suddenly the check option is no longer used in the controller, which explains that the controller can incorrectly prevent a legitimate entry. " "I see. It's a mistake of logic." "Exactly." "What kept you from discovering this logical mistake?" "We retested the entire form, in both cases: option checked, unchecked. But not in the case where the option has been checked, one field out of two filled, then the option is unchecked. We can't test everything ..." "I understand that we can't test everything. You don't understand my question: What prevented you from discovering this logical error before the tests?"

You are left speechless. Could Maria actually think that you read the code of every single update before every release?

"We don't exactly have the time to review all the code, Maria. This isn't the corporate strategy." "You won't get away with blaming that on the company strategy!"

Maria seems furious now. It's as if you had just told her: this ruined barrack, in which you're blind and stumble every two steps, this isn't just a question of execution. It was perhaps part of the plan: "We're going to build it here, and then we'll put a second floor above it. As for the central pillars we'll deal with it later, for the moment there's no budget. Hurry up!"

Breathing. There is no point in being cynical or getting defensive.

"I take it back. I'm not talking about strategy, I'm talking about the process." "What's wrong with our process?" "In our process there is no place - not even a single place, none - for prevention." "Prevention?" "You ask me if I could have noticed this error before the tests. My answer is: No." "I see." "To continue with a medical analogy, it's like being in a hospital, wondering why so many people get sick, and trying to treat them one patient after the other, while being completely ignorant of the rules. Basic medicine such as the presence of microbes around us and the practice of washing hands." "Well, I'm counting on you to change that." "With whose budget?" "I don't have a budget. I have to ask for one. I need an estimate with results forecast. Over three months."

Once again you are left speechless. You are still in the middle of the debris without light. Your manager is already on the next level. What are you waiting for?

"You got it. I want to explore this mob programming technique..." "No more exploration. You find me a solution!" "I'm not sure I have a solution at this point..." "You find me a solution that I can sell to the Steering Group." "I'll see what I can do."

(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