What do software developers really do?

When talking to my students about the difficulty of monitoring effort, and therefore how information asymmetries shape the operation of markets (or policies), an example I often use is hiring a software consultant or coder. Someone who is not a software developer, and perhaps even someone who is, will not be able to tell whether the employee or consultant is working hard, or what the quality of their output is – certainly not until it is finished and maybe not even then.

So I was intrigued by a new book that arrived here, Working With Coders: A guide to software development for the perplexed non-techie, by Patrick Gleeson. The author has worked as a software developer and is designed for people who are hiring or contracting people like him. I’ve never had to do this so can’t contribute any personal experience. Still, this seems like a really useful book for anyone in such a position. It explains some of the basics, demystifies jargon, explains how to set up the development process to ensure quality standards, describes the warning signals that a project is going wrong and finally offers some thoughts about what to do when it has gone wrong. There are some example bits of code but no prior knowledge on the part of the reader is assumed.

I would say that if you have any responsibility for software projects without any technical knowledge, and know even less than you would ever be prepared to admit, this book would be well worth your while. Given that one of the main reasons big software projects go wrong is that the executives or managers in charge have so little understanding, the cover price is a very reasonable investment in chipping away at the information asymmetry – alongside, of course, the classic (1975) The Mythical Man Month: Essays in software engineering by Frederick Brooks (“Adding manpower to a late software project makes it later.”)

 

Share