Please Do Not Feed The Code Monkeys
Do you write software? Do you feed the Code Monkeys? Not sure who the Code Monkeys are? I can explain.
The Code Monkeys are the root of our natural predispositions and learned habits which bias us towards degenerate software engineering. They are chaotic demons who reside in each person. They whisper lies, omit the truth, and tempt people to programming sins. Through their influence the Code Monkeys spoil a software project's fate. Sometimes they toy with the project's future, satisfied with a high bug count. Just as often they doom the project.
Don't believe me? How else could one explain such high rates of software project failure? I've seen published estimates of failure rates starting at 15% and as high as 80%. I subscribe to the Standish Group’s 2020 CHAOS report which estimates that around 66% of software projects fail. Someone is responsible for a large portion of those failures. I blame the Code Monkeys.
Of course the Code Monkeys aren't literal demons. The Code Monkeys are people's base instincts and traits, ill-suited for software engineering and team environments. Let's run through a few scenarios and see if any are familiar.
Have you ever copy+pasted some code you didn't understand? Or maybe a team member was writing code they didn't understand, and you didn't help them? Has a team member ever mentioned an unfamiliar project during the daily stand-up, and you didn't ask for a quick explanation? Have you ever started working on a problem without listing out a couple possible solutions because you already knew one? That was the Code Monkeys, they stifle curiosity.
Have you ever started working on a new application page without fully understanding who was going to use it? Or maybe you knew who was going to use the page, but you never met them? Or maybe you created a page and never watched anyone use it? Do you ever feel like your customers are using the software incorrectly? That was also the Code Monkeys, they fear collaboration.
Have you ever written a feature that know one asked for because you are certain it will be used? Do you feel like you don't have a general idea of the tasks you are going to work on and the order in which you will work on them? Do you feel like you don't have time to refactor your code and address the team's technical debt? Have you ever written a function or program that did something unexpected, and you couldn't explain what was happening? Do you frequently have to release an emergency fix to production? Also the damn Code Monkeys! They decimate discipline.
All software engineers have fed the Code Monkeys. If you have worked with me then I have seen you feed the Code Monkeys and you have seen me do the same. There are also Boss Monkeys, Gant Chart Monkeys, et cetera. Don't even get me started on The Boss Monkeys.
Thankfully I feel I have been feeding the Code Monkeys less frequently over time. I feel I can say the same for the people I work with. I have found no shortage of advice on how to restrain the Code Monkeys. With regard to curiosity, collaboration and discipline I would like to refer you to a few resources with my own introductions and perspectives.
Curiosity
To begin taming your inner Code Monkeys you must first open your mind. John Cleese calls it the open mode and claims the open mode is essential to creativity... Wait a second, aren't we supposed to be discussing curiosity?
I'm certain beyond doubt that curiosity and creativity are two sides of the same coin and share the same processes. John Cleese's talk Creativity in Management is the best resource I have found to foster curiosity, except that you will have to mentally replace the word "creative" with "curious" while listening to his talk. To summarize his talk if you apply his talk to curiosity:
- Curiosity is not a talent.
- Curiosity does not come from the closed mode, which is when you are focused.
- Curious people are able to play. Curious people can ask "What if?" and "How?".
- To be curious you must enter the open mode by giving yourself "space, time, time, confidence and humor".
- Use the open mode to ask the right questions, use the closed mode to work once you have an answer. Repeat.
Contrary to Cleese's talk I don't relax for 30 minutes each time I need to be curious or creative. Only for the most complicated problems do I have to relax for a while. But I do need some or all of the components of "space, time, time, confidence and humor" to start the process. I suspect the same applies to others.
Collaboration
The second step to caging the Code Monkeys is to open your heart. I'm not talking about some hippie cosmic love - nothing against hippies. You need to build your empathy so that you can understand and help others.
To that point collaboration is about building empathy. Collaboration is about working together towards a common goal. Collaboration might aid in creativity but creativity is a secondary concern. Creativity can birth solutions but empathy is essential to define the problems. Defining the problems starts by understanding the context, id est the customers and what they are trying to accomplish. Software written without context is called ivory tower software development and leads to software which doesn't solve the customer's problems.
Sharing The Customer's Pain is a great article on keeping in touch with your customers by "manning the support desk". Dogfooding is an anecdotal case study in using your own software. Shadowing is an approach which mixes the previous two. All approaches build empathy for the customer. Sharing the customer's pain is social and reactive. Dogfooding is asocial and proactive. Shadowing is social and proactive.
Group design is a difficult skill for which I can't recommend a specific article. I feel people confuse group design as the only form of collaboration. As long as you are working together towards a common goal you are collaborating, and group design is not always required. My time at MediaAlpha has taught me building empathy allows me to anticipate our common goal so that I can implement a proof-of-concept. Reviewing your POC with your customers is a reactive, social, concrete way to build empathy!
When you decide to design and plan in a group the most important variable to control is your own behavior. I'll again refer you to John Cleese's talk Creativity in Management for how to behave in group planning - he briefly discusses it towards the end. Beyond that, perhaps unstructured meetings are best to build empathy as well as creativity.
Discipline
Managing your Code Monkeys is an endless task requiring discipline. We've talked about working with your team towards a common goal using creative solutions, but can you weather the entire odyssey with the Code Monkeys on your back? You are about to travel a long a difficult road. A road fraught with peril. I cannot tell you how long this road shall be, but fear not the obstacles in your path. With the correct set of disciplines fate will vouchsafe your rewards.
The challenges and restrictions you set for yourself are your disciplines. I am inspired by Chuck Jones' application of discipline in animation. I first learned about Chuck Jones from the entertaining summary Chuck Jones - The Evolution of an Artist. Chuck Jones had strict rules about how his characters would behave and how they were animated. For example, characters needed clear desires consistent across episodes, such as Wile E. Coyote who was always hungry. Even more fascinating was the challenge to convey emotion using minimalistic facial expressions. Somehow the muted expressions have more emotion, not less! I grew up enjoying Chucks cartoons, now I appreciate his framework for discipline. The animation disciplines don't apply to software, but Chuck's framing of discipline as challenges and restrictions apply wholly.
Which restrictions and challenges should software engineers set for themselves? I subscribe to the Extreme Programming though I don't practice it professionally. The Extreme Programming framework is successful because the holistic feedback mechanisms challenge and restrict the development team, including customers. Software will be correct because the tests were written before the code units and run during integration. Code is never waiting for review because it was reviewed while being pair programmed. Release plans never drift from reality because plans are updated between iterations. The list of rules go on and each one has a clear objective.
Regardless of the disciplines you choose you must feel challenged. If you do not feel challenged then the Code Monkeys will sneak in during the lull. And the same can be said for when the challenge is too great. I don't recommend the entirety of Extreme Programming to you because it might not apply to your team and it is too challenging for most software engineers. The rule "All production code is pair programmed" is especially challenging for software engineers, even outside a pandemic! I can say I owe almost all of my successful code to pair programming and the people I paired with. I haven't pair-programmed professionally in 10 years, but I learned so much that pair programming has set the foundation of my career and my success. I am forever grateful to Carmine Mangione for introducing me to Extreme Programming. Extreme Programming should be the first place you look for inspiration when searching for your software development disciplines.
Summary
The Code Monkeys are out to get us. I promise the Code Monkeys will spoil the fate of your software unless you diligently contain them. Fear not, for decades people have been taming the Code Monkeys and detailing their success. Through curiosity, collaboration and discipline can we nullify their influence. Best of luck and happy coding.