Four essential ingredients of software development

Somewhere between marching to a screaming Marine Corps drill instructor, watching Naval Aviators smash into a steel deck, and living in constant fear of getting chewed out for an “Irish pennant,” I learned some valuable lessons about writing good code.

In the fall of 1987, I was commissioned as an Ensign in the US Navy. I received my commission as a result of 14 weeks of close, personal instruction from Gunnery Sergeant Bernhard Jones, USMC, while at Aviation Officer Candidate School (AOCS). From there, I spent the next five years as an Aviation Intelligence Officer in FA-18 squadrons, where I trained and briefed Naval Aviators on the threats they might face in the course of their duties. 

Those years defined much of who I am today, and many of the lessons I learned from the Navy carried over into my career as a software developer and development manager. Here are four of those lessons.

Attention to detail

Much of my experience at AOCS involved the simple lesson of paying attention. Push-ups are a great teacher. You quickly become a believer when you’re screaming “Attention to detail!” on the way down and “Teamwork!” on the way up. A slight blemish on the shine of a shoe or a loose thread—the result of not paying attention to one’s uniform, or the uniform of one’s classmate—resulted in the command “On your face!”, sending us to the floor for more push-ups. Attention to detail is critical in aviation. Even the tiniest, seemingly insignificant details can mean the difference between a safe mission and disaster.

While most software isn’t a life or death matter, attention to detail is critical for success. When coding, if one pays attention to all the little details—proper naming, good formatting, ensuring corner cases are covered—the result will be more maintainable code and fewer bugs. Attention to detail today means less hassle tomorrow. 

Teamwork

The other half of the push-up chant is teamwork. It is rare for a military member to do anything alone. Aircraft almost always fly in at least a group of two, and most aircraft have multiple crew members. Getting an aircraft launched off the deck of an aircraft carrier requires a highly coordinated dance of many people working together. Nearly every step involves working together with others to accomplish the goal. 

In software development, some lone developers build things, generally for themselves. However, most developers are part of a team, and working together is critical for the success of any project. Whether it is pair programming, answering questions in Slack, doing code reviews, or giving training, a software developer has to work with others to get a project into the hands of customers. 

Communication

In naval aviation, communication is critical. Talking on the radio is a skill unto itself. There are precise ways to ensure that messages are delivered and acknowledged, as radio communications are notoriously unstable. Within an aircraft, the simple notion of who has control of the plane is very clearly communicated. “I have the aircraft” is said clearly and firmly. On a flight deck, the noise is overwhelming, so all communications must be done through signalling and other means. A miscommunication can very easily and very quickly result in a deadly accident. There is no margin for error.

Software developers won’t usually cause a fatal mishap, but clear communication still makes or breaks a project. Good communication is essential to successful teamwork. It can mean writing well (in emails, chats, issues, documentation, etc.), dealing well with others (including difficult personalities), and even writing good code. 

I think code is an underappreciated means of communication. I’d go so far as to say it is the single most important way a developer communicates. Not only does code communicate to the compiler, but it also communicates to all future developers who will maintain that code. It might seem a bit odd to make sure that you are expressing yourself clearly to someone you may never meet, but that’s a big part of writing good code. 

Standard operating procedures

All naval aviators live by the NATOPS manual—Naval Air Training and Operating Procedures Standardization—which outlines the acceptable, proper, and proven way to operate a given aircraft. Aviators are expected to know the NATOPS manual for their aircraft inside and out. The manual is said to be “written in blood” because many of the procedures found within were instituted as the result of crashes.

In the software development world, we have “best practices.” Thankfully, our manuals are written in project postmortems, not actual ones. The right way to get things done is learned through the experience of, well, doing things the wrong way. A good development team has a set of rules that they follow—for formatting code, conducting code reviews, building object libraries, and so on—that are proven ways to be successful. Lessons learned become blueprints for future operations.

Every flight in Naval Aviation has a strict ritual that it follows: a briefing that discusses everything expected to happen on the flight, a walk around the aircraft to ensure that it is in good working order, the flight itself, which is conducted according to the briefing, and a thorough debriefing of everything that happened on the flight.This ritual will be pretty familiar to any development team that does planning meetings, code reviews, and retrospectives. 

I’ve never done it, but easily one of the craziest things we humans do is land a fighter jet on the pitching deck of an aircraft carrier in the dark of night. Such amazing feats are possible only through attention to detail and teamwork. Unless you are writing code for something like a pacemaker, software development isn’t a matter of life or death, but there is a lot we can learn from what it takes to bring a fighter jet safely home to a pitching flight deck.