The semicircle (episode 11 -- Boxes and Arrows)
You're running late, and not just a little late. You throw your bag under the table and boot up your PC. “Hi! Sorry I’m so late!
You say hello to Jeremy, Audrey, and Farid. Audrey says: “Maria came by. She was looking for you.” “Did she say what for?” Hmmm - ‘I’m waiting for an action plan. I don't see anything coming. I'm worried’ “OK”
Not OK. This action plan that Maria is waiting for has been spinning in your head for over a week now. You’ve collected some random ideas picked up from here and there - as if throwing them haphazardly into a soup. They’ll soften but won’t produce anything edible.
The PC lights up warning you of the impending updates. Sheesh, go ahead, do it. You get up and head towards the kitchen. You pass by Audrey's office saying, “It's not my day.” “It seems like its not your week. You in trouble?” “Routine stuff.”
The kitchen area is oddly deserted, quite inexplicable at this time of day. Well, explicable after all: the coffee display shows in small red characters: "WAIT MAINTENANCE O_o". Maybe you can make some tea. It might wake you up just as well as coffee. You start boiling some water. You catch up with news on your social network. Scroll. Scroll. Scroll.
You get back to your workstation holding the paper cup which is both too hot and too small. The PC has just completed its upgrade, and now it is restarting. You feel like crying. Why don't we tell a good joke instead? “Jeremy, do you know how we know that there is software in a can opener?” “The can opener downloads an update? You shared that one with us last week.”
Maria walks into the office abruptly. “Hello again. Anybody got any instant coffee?”
You anticipate her next request “I’ll see you in 10 minutes, Maria.” “That won’t work. Come see me at 2:00.”
You open the bug tracker. number: 4243 date: 08/31/2017 status: en cours type: bug severity: critical submitter: C. COURDEL summary: budgeted partial report has incorrect result: I submit the budgeted year, check partial report, check no bypass option, submit it, wrong amount, I expect 34320 I get 53896. See attached document. Assigned to: _ Resolution: _ number: 4244 date: 08/31/2017 status: in progress type: bug severity : critical submitter: C. COURDEL summary : we’re almost there with the budgeted partial report description: I submit the budgeted year, check partial report, check no bypass option, submit it, wrong amount, I expect 34320 I get 34000. Same dataset as 4243. Assigned to: _ Resolution: _
“Couldn’t see the forest because of the trees.” “Huh?” says Jeremy. “Bug 4240.” “Could you give me a little more context?” “Bug 4240 was masking bugs 4243 and 4244.” “I don't follow you.” “4240 is a Null Pointer Exception. We fixed it, put it into acceptance : that allowed Claudia to find 4243 and 4244. In fact, I think that what’s happening in 4243 is having an impact on the outcome that is described in 4244.” “The first bug must have corrupted the database. That's why I hate databases. Databases are a huge collection of global variables.” “Tough luck. This is where our customers keep their valuable data.” “You don’t say.”
You open the IDE and dive into the code again, coming across bug 4243, the one that probably masks bug 4244. Remember, this is not your day.
It's always the same mess, but it's not like you can find your way way back. You would need detailed notes. Like some sketches or photographs at a crime scene, taking care not to touch anything.
“Where are you?”
You hear your teammate’s voice; he's here in the building, for sure. There, at the back of the room (maybe) there is a door, which leads to another room. He's over there. You're screaming: “Over here. I'm stuck. I’m stuck. I can’t move any further.”
Sitting on dusty ground. Stuck. You don't know how you got here anymore. Nor what you were looking for. Oh wait, yes… of course: the light.
“No better off”
The sound of your voices is faint, diminished by the numerous objects that (probably) clutter the space. Two voices in the dark. Two control officers visiting the housing of a tenant with a hoarding syndrome. All this accumulated disorder. You think: If the only mistakes we have the courage to correct are syntax errors, this will be the result. Welcome to pervasive disorder. Just put that down there. There's still a bit of space left.
“How long do you think it’ll take to organize all this?”
Three seconds of muffled silence.
“The question is more likely: How quickly can we get the hell out of here?”
Silence. Creaking. Inanimate disorder. Paralyzed inspectors, status: disabled. Blip. Window at the bottom right: Maria: I prefer 2:30, after my lunch.
A ray of light penetrated the room for one or two seconds, piercing the thick stream of dust suspended there. What do we do with the Action Plan? Two thirty leaves you very little time to revisit and rework this plan. On the other hand, it leaves you all the rest of the morning plus the lunch break to find some excuse to ask Maria for a little more time.
Okay.
ToF: Oleg, you want to help me? Between noon and 2. I'll come over and bring some sandwiches! Oleg: Sure. I will. Don't bother with the sandwiches, we have food here. 12h30.
At about 1 p.m., you find Oleg sitting and working at one of the tables in the multipurpose space that also serves as a cafeteria. Oleg and you study the famous action plan. It fits on an index card:
Correction of current tickets: 80 days Code review on fixes: 10 days Code improvement (technical debt): 30 days Develop version 4.5: 120 days
While sipping your very first coffee of the day, you explain: “We cut the effort to develop new stories by half, i. e. the scope of version 4.5, and we use the extra time to fix all bugs, and to clean up the code as much as possible. We keep the current budget: four people for three months.”
“How are you going to convince your management that this is the right thing to do?”
“That's where I am stalling, Oleg.”
“What happens if you keep up with your current momentum, following your usual process?”
“The first priority is to fix all the defects, and the rest of the time would be spent on stories. But doing that puts us at risk of having an increasing number of defects, since nothing is being done to reduce the contributing “defect factors.”
“What are you calling ‘defect factors’? That isn’t in your plan.”
“It is the level of complexity and technical debt in the code.”
Oleg is looking at you in complete silence. You wonder whether he's waiting for more explanation from you, thinking about what you just said, or something else outside his control has rattled him. You choose the first hypothesis and add: “Do you agree with me that the dirtier the code, the more likely it is that we’ll insert new defects?” “Maybe.” “Software rots, as they say…” “Software is indestructible. As long as medium is still usable, the software remains absolutely intact, as it was produced by its authors.” “So how do you explain that software becomes more and more expensive to maintain?” “Its ‘value in use’ decreases. To maintain or increase it, you have to modify the software. If modifying the software is easy, then maintenance costs remain low. “Agreed.” “How many stories are planned in your new version?” “39” “How many stories, in the previous version?” “52” “And in the previous version?” “60. That's what we were just saying: every new quarter, we produce fewer stories; as the cost of maintenance increases. “What contributes to the maintenance cost?”
You're looking at Oleg. This conversation seems to be going in circles. You offer: “Shall we get a second cup of coffee?” “Of course!”
Oleg's beating around the bush because he can't really help you. Oleg's giving you a course on software development economics. Oleg acts as devil's advocate to test your plan and help you improve it. Option 3.
While ordering a double espresso macchiato, you list the reasons: “the complexity of the domain, the technical complexity of the solution, the turnover, and of course the conditions under which the program is modified” “For example?”
“For example, if I change three lines of code at random, making sure that it compiles, and if I deliver that, I'm pretty sure it’ll create a bug, and therefore make maintenance costs go up in the end.” “So the maintenance process itself is a cost factor.” “You got it.” “What has changed?” “What?” “You produce fewer and fewer stories each quarter, it seems. What varies among the four cost factors?” “I guess the complexity of the domain has increased a little bit. Technical complexity has also increased due to the technical debt.” “There is no such thing as technical debt.”
You hold bite your tongue. Oleg's a pain in the ass, actually. Oleg likes to provoke. Oleg is thinking for himself.
Oleg continues: “Everyone talks about technical debt, but debt is when you owe something to someone else, usually a bank. Developers owe nobody anything. On the contrary, they are paid to do what they do.”
“It's a metaphor. They are borrowing time from themselves. As in saving time now that they'll have to pay back later.” “Not if they go to another project, or if they get fired.” “They are decreasing the maintainability of the code. It's like they're depreciating the value of a company's assets, so to speak.” “In the company where we are right now, if someone found out that you were damaging some equipment, they would stop you right away. So, your supervisor lets you wreak havoc with the maintainability of the code?” “I would say she even encourages me.” “So maintainability of the code isn’t considered an asset.” “Not for her, not for the management, anyway.” “So not for you.” “Are you suggesting that we should let the maintainability of the code decline?” “Not suggesting a thing. Just pretty sure you won't be able to convince your management that they have assets to maintain that they didn't know about until now, and that it's because of a deterioration in these assets that they’re going to be late, or that the quality will deteriorate.”
Back to square one. You are all sitting at the big table again. The room's almost empty. Oleg smiles. He's asks: “What do you observe about defects?” “For one, in each new release, there are more defects than in the previous one.” “So you produce stories, and defects.” “Sort of.”
Oleg gets up, goes to rummage around one of the shelves at the back of the room and comes back with an A3 sheet and markers. “So you spend time coding. This produces: 1) functionality 2) defects, which cause 3) incidents. The more you develop, the more defects there are.”
“When you have incidents, you look for the defects and correct them. So you spend time correcting, which reduces the number of defects.” 
“The time spent coding and the time spent correcting cannot increase simultaneously: you have to choose. That's a good thing, because when you make fixes, you reduce the number of defects directly and indirectly because you code less.”
“Not necessarily: there are cases where the correction of a defect creates an additional defect.” “Maybe, but we should try to keep it simple…” “But not simplistic…” “This is the danger with models, but let's continue. If you don't rectify defects as quickly as you produce them, the time spent coding stories will decrease, to the benefit of the time spent correcting defects. How can this situation be remedied?” “You can test the code, which in your schema means reducing the number of defects before they generate incidents.” “Alright. Note that testing takes time, and therefore reduces the number of stories you can produce. Again, you have to choose between the different activities.
“What else?” “We could just as well prevent defects, as you say, by reviewing the code systematically. Or by setting up mob programming.” “OK.” 
“So you have these metrics: number of stories done, number of defects, number of incidents.” “Yes.” “And you must divide your time between: 1) Coding new functionality 2) Correcting defects found 3) Testing for defects 4) Conducting reviews to prevent defects 5) Training to improve your tests 6) Training to improve your code reviews Good luck!”
You run to catch up with the bus, the A3 sheet folded in your pocket. But that's not a plan, that's a model. And with lots of scribbling for that matter! You’ll just have to go find out what Maria thinks.
(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 10 -- Either ... Or ...