<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

Aviator's Guide to Software Development

Development Process, Software Development, Culture

By Scott Smith

Focus on the goal not the retribution. Wow, that's a loaded statement! But people are people. We have a natural tendency not to be scolded. Or yelled at. Or have our competence called into question. Staying out of the crosshairs can be more important than delivering product. Sometimes the structure and culture of an organization is sick and broken. Philosophizing in a meeting is not my idea of productivity, but some people live for it.


As a pilot, I often find parallels between aviation and software development. For people who know me as an aviator, it's no secret that I don't like control towers. I'm not alone in this sentiment. I fly out of a controlled airport but I generally try to avoid control towers as much as possible. I usually don't contact approach control or center unless I have a good reason or the situation mandates it. To me it adds a lot of stress. In addition to all the normal tasks involved in aviation, I have to add precise navigation (I don't have a fancy GPS), communication, rules under the watchful eye of the government, triaging communication because of frequency congestion, altitude enforcement, situational awareness beyond traffic avoidance, etc.


Some pilots like the false sense of security a controller offers... and they do offer good things. To be sure, the FAA has recognized this divide between controllers and pilots as a key contributor to accidents or mistakes. Because of the combative relationship, pilots have often been reluctant to ask for help from controllers because of fear of retribution. Instead they avoid the specter of punishment instead of seeking help that might turn a bad situation for the better.


Queue up the crusade of releasing accident studies, controller testimonials of how a pilot could have asked for help, or got the help needed from a controller. Same for the pilots who have survived a harrowing situation. This recognition of the core problem is a good thing. Most controllers don't fly and most pilots are not controllers. There is a natural divide between human understanding in both verticals.


Many readers should be seeing the parallels in their own work life between these scenarios. I'll call the controllers management and pilots developers in my metaphor. I like programming. I do it for fun and for making a living. I love exploring new ideas and technologies simply for the fun of it. I love the simple challenge of flying. Both endeavors push me to be better. It's a cycle of constant improvement and growth. And in both, I can share the fun with others in the form of forking code on GitHub or taking someone up for their first flight.


As a developer, I feel the same way about process and management. The more process and management, the more stress. As a full stack developer, I generally don't need help managing my time or tasks. Once I have mockups and requirements, I know what to do. But as a team lead, I do need some communication. And if there is enough churn in direction from management, tracking can become important because sometimes their memories are short. Two week sprints and time boxing can be important to measuring progress for the whole group. In the same way I need to contact McCarran approach control to get into North Las Vegas and avoid Nellis Airforce Base, I need project tracking when the number of participants in a project reaches a certain level.


Some developers like the security of a rigorous process. It gives them something to fall back on and protect themselves when the process is violated. This is good and bad. It's good for changes that come outside of the team's control. It's bad for allowing developers to hide from their responsibilities and deliverables. A good agile process includes a daily meeting so that help or having the team heap onto a tough problem can save the day for someone who might be left to take the failure by themselves. If it's done right, fear of retribution is taken away. Add code reviews and everyone owns a part of what goes out. No one person becomes a scapegoat to absorb all the blame, good or bad.


Queue up Anti-patterns, Agile-Scrum, Kanban, or any number of other variations in software development processes. From Frederick Brooks to today, our industry has been recognizing and devising ways of mitigating barriers to software development. If you find developers living in fear of retribution and are more concerned about avoiding punishment than delivering good solutions, it might be wise for leadership to take a look in the mirror at their role in creating that situation. Developers can, at least to the greatest degree possible, avoid getting sucked into the pitfalls of self preservation at the expense doing good work. Recognize the differences in the verticals and seek to reconcile differences.


My general advice to any development group is to only put as much process in place as is absolutely needed and no more. Any more and it becomes red tape, overhead, or top heavy management. Make sure this is enough there in terms of communication and transparency to keep everyone working towards the right goals instead of avoiding each other at the expense of productive solutions.

Atlassian Tools Jira Confluence

TAGS: Development Process, Software Development, Culture

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts