More difficult than crayons

When you spend your career helping people deliver software, it quickly becomes apparent that your biggest challenges are not technology problems.  The biggest challenge is working with messy people.  Machines can make pencils and crayons by the thousands each hour, but before that happens, someone has to design the product for manufacturing.  The people who do this are engineers and product designers.  The software relies on Scrum Masters, Product Owners, and software developers.  The creative process is the same, but it is much easier to manufacture crayons than software.  Today, I will try to answer why it is so hard to write software.

Software has only existed since the aftermath of World War Two.  The first documented “bug” was a moth that died among the vacuum tubes of the first computer.  Despite technological advances, the way we write software is still primitive.  Developers continue to test code on local machines and then push that code to remote servers to see if it works.  Testing is manual, and the ability to automatically push code through the web or large enterprises is limited.  The software craft movement is making progress in this area along with the DevOps movement which is helping with this antiquated process. However, getting software written is still a long, tedious trudge.

The key adverb here is “written.” The writing of software is a creative process.  People take the vague directions of others and translate them into web pages or client-server applications.  Unlike traditional prose, software contains code, markup, and data.  The disciplines working with each are different and filled with plenty of nuances.  Business people compensate software professionals generously because it is such a rare skill to cultivate.  Developers are also under tremendous pressure to ship code and work long hours.  Imagine Earnest Hemingway attempting to write “A Farewell to Arms,” with management standing over him demanding daily updates. Furthermore, imagine the Nobel laureate must write one character’s dialog in English, another in Spanish, and finally, in hexadecimal code for each letter on the page for a different character.

If the above needed to be more challenging, the people paying for software creation are not actively involved in its production.  Software projects often begin with a problem that does not have an answer.  A marketing executive blurts out, “I need a client website!” or a Human Resources professional asks if it is possible to manage timecards online.  The business set aside money hired consultants to do the work and began writing software with no idea how it should work.  Agile fixes this problem by requiring rapid time boxes.  Often, a lack of participation and vision from business partners thwarts the benefits of agile.

Combined with the difficulty of writing software and the apathy of the people on how to pay for the software, the final challenge is the hypercritical nature of everyone who cannot write software for the people who can write software.  It is similar to the Austrian Emperor mocked in the movie Amadeus, whose only criticism of Mozart’s opera is that “There are too many notes in it.”  Many people have opinions about software and provide either nitpicking or unhelpful critiques.  As a developer, a color pallet I used for an application caused controversy, and we spent countless meetings reviewing color chips.  It extended the project's life by three months and made it over budget.  In a different episode, punctuation on a page sparked hundreds of revisions and emails.

The reality is like a committee of proofreaders, executives, and people not involved in the creative process demanding edits to Hemingway’s work.  The final straw might be the demand that “A Farewell to Arms,” not have one of the main characters die at the end of the book.  The entire narrative arc of the book changes because of the “suggestion,” but if Hemingway does not make the changes, he does not get paid or published.  Considering this feedback, Hemingway would have consumed more alcohol than he did.

This is why writing software is so complicated. It is a creative process. Next, the people who want and pay for the software are not actively involved. Finally, if customer partners are involved in the project, they provide feedback and guidance, which often removes value from the software rather than adding it. I have been in this career for a long time, and I know how to write and deliver software. It is much more complicated than creating crayons.

Until next time.