More difficult than crayons

Crayons are easier to create than software.

When you spend your career helping people deliver software, it quickly becomes apparent that the biggest challenges you face 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.  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 which died among the vacuum tubes of the first computer.  In spite of technological advances, the way we write software is still primitive.  Developers continue test code on local machines and then push that code to remote servers to see if they work.  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 are helping with this antiquated process, but it is still a long, tedious trudge to get software written.

The key adverb here is “written.” The writing of software is a creative process.  People take the vague directions of others and translate it into web pages or client-server applications.  Unlike traditional prose, software contains code, markup, and data.  The disciplines working with each is 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 to do it.  Imagine, Earnest Hemingway, attempting to write “A Farewell to Arms,” with management standing over him demanding updates each day. Furthermore, imagine the Nobel laureate is required to write one character’s dialog in English, another in Spanish and finally hexadecimal code for each letter on the page for a different character.

If the above was not challenging enough, the people paying for the creation of software are not actively involved in its production.  Software projects often begin with a problem which 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 begin writing software with no idea how it should work.  Agile fixes this problem by requiring rapid time boxes.  Often, 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 how to pay for the software, the final challenge is the hypercritical nature of everyone who cannot write software have 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, “There are too many notes in it.”  Many people have opinions about software and provide critiques, which is either nitpicking or unhelpful.  As a developer, a color pallet I used for an application caused controversy, and we spent countless meetings reviewing color chips.  It extended the life of the project 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 type of feedback, Hemingway would have consumed more alcohol than he did.

So 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 in the project, they provide feedback and guidance, which is often removing 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.