The Big Picture

Better software results when developers know the end goal

By Peter Varhol

Have you ever sat at your desk at work, wondering why you were doing a particular task? It’s not an uncommon feeling among developers. To understand why, we need to go back in time over a century ago.

In 1901, the first modern assembly line using interchangeable parts was created by Ransom E. Olds to build the first mass-produced automobile. A decade later, Henry Ford evolved it into a fully moving assembly line, stopping in front of each station for the precise amount of time required for the worker to complete a discrete task.

Assembly line at Olds Motor Work

This innovation fostered a major new branch of industrial engineering known as time and motion studies. Engineers measure the optimum combination of motions required to complete a discrete task, along with how long those motions should take.

It was the first attempt at automating a complex process with people rather than machines. And it worked, for a while. Workers were happy to be well-paid and with a defined role in a larger process.

Then it stopped working. Those time and motion engineers kept optimizing, to the point where assembly line workers became increasingly stressed and disengaged at the reality of doing exactly the same limited motions hundreds of times a day, and in a required timeslot often measured in seconds.

Fast-Forward to Today
We can find its present-day equivalent in many modern corporate offices, where dozens or even hundreds of developers work on tiny parts of a much larger application. The “final assembly” is done through the integration and build process, producing a single result from the efforts of many developers.

But unlike assembly line workers, developers make hundreds of decisions in the course of a day. It might be a new variable, or whether to use an ELSE-IF versus a BREAK statement. Those seemingly innocuous day-to-day decisions can have a significant effect on the appearance and function of an application.

How does a developer make these decisions? They are often the unconscious byproduct of writing code. Sometimes decisions are based on standards, such as whether to use Hungarian notation or Camel case, or other standards used for code readability or function length. Sometimes developers make a decision out of habit. And often, lacking any other feedback, developers simply flip a coin in their heads.

It should not be a surprise most decisions are made randomly without context. The problem is that many developers are simply handed a spec, or part of a spec, and told to code it, without knowing the purpose or the goal. Worse, they may not see a spec at all, but rather just told to write a particular function, without even knowing the application. The end results can affect schedule, quality, or performance.

So developers need more than the spec for their little piece of the project. The spec tells them what to code, but not why. Does knowing the ‘why’ help individual developers make better decisions?

There are significant advantages to knowing the purpose of our work. At the top level, it provides a framework for making routine decisions that we make in the course of a day. But it also gives us a larger sense of purpose. We now have shared goals and can work more effectively as a team. Lastly, it enables us to make no-brainer suggestions and enhancements based on the larger context of the goals.

Not Just Developers
Nineteen years ago, The Boeing Company moved its corporate headquarters from Seattle to Chicago. About five hundred people in all, senior management and corporate support staff, out of a company of 150,000 people. Few of those five hundred people designed, built, or tested aircraft. Over time, fewer had even seen the production lines in Seattle, Charleston, Wichita, or Long Beach. It’s easy to think of the 737 MAX as the culmination of this decision.

While distributed work environments aren’t the kiss of death, there are disadvantages that successful companies must work to overcome. Without a certain amount of familiarity, communications gaps develop, and messages are misunderstood. Successful distributed teams overcommunicate. And they overemphasize listening. It’s hard to listen when management has removed itself from the actual work being done.

When you’re fifteen hundred miles away from management, without involvement by management except for ongoing mandates to cut costs, it’s easy to believe that any decision that you make will be good enough for people who can’t be bothered to show interest in your work. That leaves you with an empty feeling when it comes to being fully invested in your code and the application as a whole.

Developers need coordination among each other, so that their code fits together properly, and that features work together in a coherent workflow. Likewise, management can’t just look at development teams as a black box, with specs going in and software coming out. Doing so means they are satisfied with mediocrity.

If developers aren’t given the big picture, then the hundreds of decisions they make have no context. They may support the goals of the application while at the same time contradict the goals of other groups or the company. At best they will guess, and sometimes guess wrong. At worst they will come to believe that any decision is good enough.

So I will say it right here. Developers will produce better software if management shares both the objectives of the application and the overall goals of the company. Think about that statement for a moment. This isn’t about developers being paid more or given better tools. It’s about knowing why they are doing what they are doing. It helps them make better decisions every time.

This work is licensed under a Creative Commons Attribution 4.0 International License.

Dan Ariely, What makes us feel good about our work? | TED Talks

Dan Ariely is a behavioral economics professor and one of my favorite authors, who shares in this talk a few fascinating insights on work and motivation.

We are currently recording new Heretechs podcast episodes this month! You can check out past episodes by finding them on Apple Podcasts, Google Podcast, or wherever you listen to your favorite podcasts and please give us a like and subscribe 😁

We want to welcome Peter Varhol as a contributing author to DEV.BIZ.OPS! If you wish to join us as a writer, message us here to discuss.

We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s