The semicircle (episode 3 -- Communication Breakdown)

The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaption, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them. Peter Naur - Programming as Theory Building

You look at that bit of code, the one where you have to add some new functionality and hear yourself saying out loud: "I would never have written it this way... How can one create such a convoluted design?" Jeremy, who wrote this code, is ten steps away. He's currently working on some other part of the program, his headphones on. You could get up, interrupt him, ask him some questions, and give him some feedback about this design. But you tell yourself "What's the use?" This will be at best yet another disagreement, highlighting again the chasm between you and Jeremy on topics of knowledge, preferences, and experience with software design. You remember that ten days ago he came to see you, announced he had decided to entirely rewrite the front end/back end communication module.

"Oh really!?" "I don't understand anything that has been done on in this module." "And you want to rewrite it so you can understand it better?" "Exactly." "..." "It will be simpler." "You’ll do it at your own risk and peril." "It's ok with the PO. I wrote a technical story." "OK by me, then. I am not in charge of coordinating this project."

You are thinking about this conversation again. You could have been more adamant. For example, mentioning to him that you've been here for ten months, but that it took six before being able to write one enhancement without having to ask four different people for help. You wonder if there's a chance Jeremy will last another year on this project.

The room you are walking in is filled with heaps and heaps of junk. Your entire job is to attempt to describe the obstacles in your way. It is hardly a reliable description since you can only see with your hands, knees, and occasionally your head. Correct descriptions require deep thought. And calm. How can one stay calm faced with a constant barrage of unidentifiable objects? But you think that by describing them you are saving time for your teammates since you are preparing a pathway for them. In a way.

"I noticed that when the user clicks on the Admin menu to set authorizations, the service template isn't the same as when I enter the authorization on the fly during a transaction." "Do you mean the 2L transaction?" "Not the 2L, the 2LB." "You don't say. Welcome to the sh... Good luck!" "OK."

You could open your notebook to any page and label it: unexpected discovery number...

You are walking around in a dark room, which is different from the dark room that Jeremy is currently exploring and nothing like any of the rooms that your colleagues are in. The objects are different not only in shape -- they are inherently different. What's the likelihood that we could produce an integrated, robust and coherent application given these conditions? Each exploring their own assigned space (are you even the same building?), with only a few tools to survive in the dark and a bandwidth so narrow that it is laughable.

Jeremy doesn't understand this whole thing about bandwidth. He says we've never had such powerful connectivity. "I am talking about the bandwidth between us, not the fiber network. It's a metaphor." "I don't get your metaphors. Be clearer." "See ?"

Maria, the project's Product Owner/Manager/Coordinator, quite agrees with that observation but says you have to just live with it. What counts is what the client sees. You ask yourself how the client could possibly see in this system a coherent set of items designed to work together. You only see disparate objects, an accumulation of scattered, crystallized particles, some fossilized, where successive technological waves have caused layering. You wonder what the clients would say about the amount of time each ticket takes after seeing a slice of the archeological history. Here's where the budget goes; just look what it costs. Maybe they would tell us:

Why is this meadow so barren when it has such rich soil?

"I am not the one in charge of coordinating this project." Blah blah blah. What a lame answer! Of course Maria will manage all the functional and technical requirements of the project, ensuring that everything lines up internally and externally, and she'll manage to keep the schedule, and save money, and keep the team in a good mood, and grow the team. It's guaranteed.

It's ten thirty. You go by to see if Audrey and Farid will take a coffee break with you.

"It's not my day, you say." "What's going on?" asks Audrey. "Communication breakdown."

Farid smiles and says, "Oh. When it's like that, I just hunker down in my chair for the whole day and focus really hard on some very technical details." "Speaking about communication," says Audrey, "last Thursday I went to the programming Dojo." "How was it?" "Not bad. One of the participants recommended trying out Mob Programming." "Don't know it." "It's like a regular Dojo, with the shared screen and all, with one small difference." "What?" "The person at the keyboard waits for the participants to tell him what to code." Jeremy, who just joined the conversation and is emptying an old teabag into the trash says, "Yuck. I would be waiting a long time." Farid chuckles. "No joke, says Audrey, there's even a principle in there for you who loves principles." You say, "That's intriguing. Tell me more." "It's the principle Driver/Navigator. I don't remember the exact phrasing. But I wrote it down."

You return to your desks. Audrey opens her notebook which seems as full of notes as your own: lists, big exclamation marks, and WTFs.

Here it is: For an idea to go from someone’s head into the computer, it must go through someone else's hands. - Llewellyn Falco

That's what's called the Driver/Navigator model. The driver is the one at the keyboard, the navigators are those who think, decide and design. Everyone is working on the same story, in front of the screen.

Hmmmmm.

Driver/Navigator Driver/Navigator ...

You get back to your piece of code. Obviously, that would change life in the dark labyrinths. You imagine the team in action. "Not there; there's a whole class copied-pasted from the TransactionBL class. I saw that last week." "Ok, get around it by renaming the class and only keep what's needed." "Who knows what's needed?" "I know! Go to the Delivery module. I will show you." "TransactionBL? Really? It's about time we all agree on the naming conventions."

You make a mental note of all the possible pain points of working together in that way. Maria would immediately think of her budget issues and would come say it's all fine to communicate about the code and all, but let's not fantasize. Because Maria's the one who labels our retrospectives "a huge waste of time".

Speaking of the devil, here's Maria now entering the team room. She is heading straight towards you.

"How is it going?" "So so. I don't think I'll be able to finish this ticket by Friday." "That doesn’t work for me. I need to show something functional.” "I guess so…" "Do you think we should add another resource to the project?" "I wouldn't do that if I were you... Adding resources to a late project..." "... makes it even later. I know. Brooks. What's the issue with this incident? What would it take for this ticket to go a whole lot quicker?" "Hmmm. Revisiting the whole product design and starting from a more solid foundation, with a team standard?” "When you've landed back here on earth, answer my question please, says Maria smiling." "OK, I pass. I have systemic issues." "What does that mean?" "Like when you go to a global climate change conference and you drive your car. Get it?” "Not at all." "In the short term, I could resolve this issue, but it would create more problems." "Fix the issue. For the other stuff, we'll see later."

Back to the code. Swimming up to your ears in code. You ponder what you could possibly do. You can't rewrite the whole system from scratch, deciding on and applying principles that the whole team agrees on. That would take weeks and weeks of laborious, stormy, and unfruitful meetings.

Stuck. Each in his own dark maze, bumping into stuff. The teamwork that would make this product great is impossible.

You write this principle in your notebook: For an idea to go from someone’s head into the computer, it must go through someone else's hands.

You take note of two interesting impacts of working this way: You wouldn't have any idea implemented without first having communicated it. You wouldn't waste time discussing what won't be implemented.

You decide that you will go to the programming Dojo next Thursday. You go back to your screen. You plug in your earbuds and play Led Zeppelin, super loud.

(to be continued) previous episodes: If the code could speak See/Advance