What would happen if every member of an orchestra played remote and was responsible for figuring out his or her own timing for when to join and which song was to be played?

A game famous for fighting "chaos" reminded me recently of the cacophony and dissonance in many projects, even before the "work from home" era.

Imagine what would happen if every member of an orchestra is simply handed the sheet music, told to record his portion in isolation (perhaps speaking to one other orchestra mate), and then told upload his piece to be integrated by automation framework.

You would end up with such dissonance and cacophony that you would have to delete the uploaded data, or else you would need to purchase and train a music AI to change the timing and sync up the tracks. A lot of these "fixes" would lead your program Burning Money not to mention the timeline.

We can also see this demonstrated in the team building exercise "telephone game" where after about 5 people relay the message "orange refrigerator," the phrase becomes "Vanilla Ice." This game is even more wild when the iterations alternate between a word and a picture, but that might be another story that is not workplace appropriate.

A lot of the time, as a consultant, this is the game I observe in most modern development groups. There is this crazy theory that if you hire "self-motivated" people who all have 5-10 years of experience that somehow without guidance and collaboration they will create a masterpiece. Equally crazy is the hiring theory that if you hire a team of all junior people and tell them "figure it out on your own" (with the implied threat they may be fired) that industry revolutionizing software will come out.

I can defend a number of positions I do not agree with, those two, however, are indefensible.

In our orchestra example, going remote would spell disaster for the performance even if you kept all of the same people. Why? In the music example, every note has to be played at the same timing. Fractions of a second different, and the song turns into a disorienting confusion as you hear the drums a beat faster and the clarinets a beat slower. It starts to sound more and more like something from a horror flick the less synchronized the orchestra becomes.

You may be saying to yourself that software does not require this level of timing, and you would be partially right.

You might also be thinking software like GIT helps you manage the "merging" of these differently timed pieces...until you watch what happens when 6 different developers each with different stories modify the same unit of code for wildly different intended results. Before you blame the GIT people, this is an architectural issue long before it becomes a "merge" issue.

While using the "work from home" helps us to illustrate this disunity and cacophony, in truth, good leadership can make this painless in a remote group and bad leadership can make this fail even when everyone is in the same building.

I am an architect and a consultant. I am finding each of these terms means less in 2020 than they did in 2000. An architect is someone whose job it is to understand how to piece together the needs of a customer into a 1) unified solution 2) within the constraints of the budget and team talent and delivery timeline. When the architect cannot create a universe in which these factors converge into reality, he will draw up a new plan retaining as much of the customer's "needs" as can be delivered based on the constraints and then coordinate for approval. (I am always amazed when an implementation partner changes the deliverables without both notifying the customer and getting approval.)

In the example of 6 different developers writing to the same file, the architect must be someone who knows how the system works so that when code needs to be written he is minimizing the number of places where failure can occur while maintaining the highest level of productivity for the team. (Again, many implementation parts I have replaced had 'architects' who had no knowledge for how the code was written or functioned.)

While you may think this example to be a stretch, I have seen a client whose architect broke the project for 3 months because he had 3 people touching the same code for 3 very different needs.

"Agile" development does not change this. I see this excuse often for why a project has no plan. While we do not want to revert to waterfall or even scrumfall, chaos in the pipeline is a result of missing leadership within architecture. A good architect will tell you unpopular things and will push back on things that will lead to problems; someone merely pretending to be an architect will agree to changes and then dump the problem on the development team to "figure it out."

When a team of junior developer are told to "figure it out" when dealing with conflicting and competing coding goals, you very rapidly wind up with spaghetti code held together through best intentions and duct tape.

Productivity and Architecture go hand in hand. When your customer comes to the show tonight expecting to hear the orchestra playing Mozart, will they be pleased being accosted with strobes lights and a jam session between Trent Reznor and Rob Zombie?