Programming Should Be More Like Authorship than Engineering

Most programmers I know come at the discipline from an engineering background and this leads to all sorts of pre-conceptions about what we do and the guarantees we offer.

Clients often believe that paying for software development is like building a bridge.  You have some meetings to decide what kind of bridge you want to build, send it to get architected and the design approved by engineers and then hand the blueprints off to a construction company to build it.  Once built you expect the construction workers to go away and the new bridge will not need to be serviced for 50 years.  This is the mental model that many people have about how software development works too.

This is partially our fault and partially a quirk of history. Computers and programming languages came out of engineering and mathematics and the early developers brought with them their background of being engineers.  Now we are deeper than ever into this mode of thinking.  Software patents are treated like inventions.  Teams of programmers try to apply engineering styled development plans to writing software, sometimes with gant charts an other times with scrum.  None of these approaches have proved ideal and as a result expectations often do not match reality.

Instead I believe that software should be thought of as being closer to writing.  If you commissioned someone to write a book about the Golden Gate Bridge you might expect them to not be experts and require some time to gather research, distil that into notes and further organise their source material before they could really even suggest a structure for the book. If the book was going to be written by multiple authors then sections of the book would be assigned to each person in a way that required little sharing of the same content.  As each section of the book is drafted you might get an early read and have plenty of edit requests to make. Entire sections may need to be re-written if you don’t like the way something is presented.  At the end the full manuscript is again reviewed and edited. Reviewers and Editors expect to find typos and awkward sentences that should be fixed.

Publishers of the book also usually have a very different pay structure than software clients.  Publishers often provide the writer with an advance to cover expenses while the book is being written and then give a royalty on sales of the book.  This seems like a fair arrangement. Up front payment allows for full-time focus without having to take a part-time job or use credit to live and the promise of royalties provides extra incentive to write the best and most successful selling book you can muster.

Software development consultants rarely put any skin in the game. Time and materials based projects encourage a consultant to go over time for more money, and fixed budgets encourage them to cut corners to save time. The lure of ongoing maintenance contracts encourages developing something that requires updates and monitoring to keep running.  Notice that there is no direct incentive for the project to be a success, and the developer needs to cover their living expenses until a delivery date is hit. The developer who wrote the software rarely gets any public credit.

I think it would be refreshing if the publisher style model was applied to software developers. An upfront advance to cover expenses, and royalties from the profits of a successful product would help put the right economic incentives in place.  Books often have an about the author blurb tucked somewhere in the first few pages; websites and applications should do this as well since it’s another incentive to build something you are proud enough to put your name on.

The business model for book publishing seems like a good fit for software to me. What do you think?