How This Book Works
Leaders & Software Engineers demonstrates the way the author communicates to the technical team. There is a theme or SITUATION that drives the need to communicate. THE MESSAGE to be delivered is what the author wants to convey. The story itself would be the part sent to software engineers. Finally, what does the author WANT ENGINEERS TO DO?
Goal: Guiding Geniuses to Make Code More Simple
SITUATION: IT was preparing for several significant projects with daunting requirements. With complex features to build, engineers could be distracted from the principal of simplicity.
THE MESSAGE: When designing these new solutions, look for the simplest way to build them.
Despite knowing the value of simplicity, I can still be one of the worst offenders.
I raised a routine from some demonic realm of complexity not that long ago. It is so complex and convoluted that other production support engineers have shunned the module from improvements and maintenance. All creations have some virtue, and this routine, dubbed PART, certainly does. It is capable of synchronizing an 80 record-type communication in 2,000-plus remote databases from a mainframe using analog modem feeds, and doing so on any machine purchased since 1998. It is fast and accurate. However, it is a dreadnought that weighs in at 7,000 lines of code, interprets 80 record types, and converts 4,000 data fields based on 500,000 lines of table-based configuration and rules. And it is a single-function call with recursive functions built with the main routine. It is the jackalope and platypus love child of functional code. Repentance for me would have involved a pilgrimage to the world of code refactoring to create (estimated) 100 smaller functions—each with a well-defined and simple mission.
After the PART episode of my career, I decided to look for ways to test my code for simplicity. I found a recommendation in an unusual place: fiction. Writers have a tendency to build a story and characters into a confusing mess. How do they fix this? About 35 years
ago, I was working on a novel and was interested in learning better writing techniques. I read about techniques from top writers, and one jumped out at me.
“Be able to describe your story in one sentence.” Think of it as that tagline the advertisers create for a movie. An example? A writer suggested: “Moby-Dick: An obsessed ship’s captain chases a white whale, but doesn’t catch it.”
I took this advice directly to the software team and read the example. Bill, the engineer-philosopher and movie-buff extraordinaire, chuckled and said, “I have a better one: Moby-Dick: An obsessed ship’s captain chases a white whale, but the whale gets him.” He then added, “Played by Gregory Peck.” Chalk one up for our local philosopher.
If we are able to summarize a novel in a sentence, authors then should be able to do the same to a chapter. Each paragraph must then have a similar theme of simplicity. I tried this premise out on some of my software creations that caused problems, and I found that the ones easiest to understand did have modules, routines, data flow, and structure that could be labeled in simple terms. Pick out one of your complicated modules and routines and see if you are able to make simple descriptions at the high-level to the detailed-level functions. You might be surprised that a Swiss Army knife routine defies simplicity unless you have put each tool in its own compartment.
WHAT WE WANT ENGINEERS TO DO: When an engineer reviews their code, they should consider whether routines can be described simply. If not, can that code be simplified?
Goal: Describe to New Managers Some of the Uncommon Sense in Engineer Thinking
SITUATION: Managers in IT had asked that software engineers be more businesslike in their answers to requests, particularly when non-IT individuals were around.
THE MESSAGE: Share some poor examples of communication to illustrate the need to think before speaking.
Occasionally, I get a comment from a reader of my weekly engineering newsletter about something funny I have written. Although some of the stories are a little funnier than I might have intended, I am happy that there is some entertainment value in these articles. However, my imagination cannot compare with some of the quotations in the nightly operations team’s shift log. Some of us old-timer developers had starring roles in the past.
Here is how it works. The overnight shift is responsible for noting events that are out of the ordinary, such as software crashes or batch problems. When I was a computer operator in my pre-engineer years, I got to contribute to a night log and tried hard to record things verbatim. The log is shared with a group of leaders who can understand issues and take action as needed.
So, here is the funny part: As an operator, I would just write the content of phone conversations from developers as if I was Walter Cronkite. In the same way, when I moved to a developer role, my phone quotes made it to the log, too. A famous one involved a long-running batch job about which I was quoted in the log as saying, “I fixed the policy and restarted the job. I am going home because it will work this time,” but I did not wait for the job to complete (as was appropriate). Murphy’s Law kicks in at this point when the job crashed on the next policy. I had my serving of crow and drove back downtown. The log recorded my return for posterity.
Still better ones that I remember reading or writing in the log many years back:
• “I just painted my tractor and I can’t come in.” Perhaps we should have recommended that the engineer just drive a car, and not the tractor, into work?
• “I did not hear the phone ring because my dog barks when the phone rings.” The comment from one of the wisest of our leader team at the time was, “When your dog barks, pick up the phone.”
• “My husband is not home, but if it is an X4000 error, you can restart the batch in the next step.” This advice came from the wife of a developer who heard him say this a million times. This event was followed by a request to all our spouses to identify themselves as such and defer to the actual employee. I was quick to point out that the wife did get the answer right.
•“I will take a look in the morning.” While it is accurate that problems can be solved in the morning, we have to think about how many people will be waiting for the fix in the morning. Unhappy sponsors are something that I would prefer to avoid.
So if you are part of an off-shift during an incident or outage, be like Walter Cronkite. Since our words become part of the log for the evening, imagine that your quotes will be reviewed by a large and important audience. Be clear and concise.
WHAT WE WANT ENGINEERS TO DO: Engineers, think about your communication to others in IT so that you can be quoted accurately.