Q&A on the Book Working with Coders

The book Working with Coders is a practical guide to managing teams of software developers aimed at a non-technical audience. In the book, Patrick Gleeson explores how the software development process works and what managers can do to support it effectively and build solid working relationships with coders.

Chapter 2 from the book is available as a PDF download: Why Writing Software Is Nothing Like Building a House.

InfoQ interviewed Gleeson about the main challenges of managing software development and how agile suggest to deal with them, what managers can do to prevent or reduce technical debt, the programmer preoccupations that managers should be aware of, and what managers can do to establish a solid working relationship with coders.

InfoQ: What made you decide to write Working with Coders?

Patrick Gleeson: At a certain point in the last few years I realised that there were certain conversations I was having again and again. Typically I’d be speaking to someone who wasn’t a coder - either an entrepreneur who had come to me for advice or a colleague - and we’d be discussing how to go about getting a piece of software built by a team of coders, and all the ways in which it could go wrong. I realised that there are some things I’ve learnt during my time working in tech that aren’t at all obvious or intuitive to people who’ve not spent time writing software. But those things are nevertheless crucial to know if you work in any capacity with people who write software. I thought that if I could write those things down I might be able to prevent some people from making the sorts of mistakes I made when I was learning those things first-hand the hard way.

InfoQ: For whom is this book intended?

Gleeson: The primary audience is people who don’t write code themselves but whose professional success depends on coders producing some software for them. In practice that largely means IT project managers, people who work in startups, BAs, SME CEOs and anyone who ever finds themselves the client of any sort of software development agency. But it’s also written with software developers in mind, particularly team leads who manage other coders and spend a lot of time interacting with non-technical colleagues.

InfoQ: What can tech leads get out of reading this book?

Gleeson: Two main things. The first is that the book aims to be a very practical guide to managing a team of software developers. I spend a lot of time thinking about what the unique factors are that motivate coders, the tendencies that come with the job that should be encouraged and those that are liabilities without appropriate safeguards. There are also chapters on how to recruit developers and how to keep them happy.

The second thing is that this is a book about communication across the technical/non-technical divide. It’s all about making facets of the software development process accessible to people who don’t know how to code, whether that’s finding ways of explaining concepts like technical debt, or persuading key stakeholders that a particular way of working will get them the results they need even if it seems counter-intuitive from the outside.

InfoQ: What are the main challenges of managing software development?

Gleeson: The biggest challenge has to be that software development doesn’t behave like other business processes or other engineering disciplines, in subtle but really important ways. This means if you take your cues from those other processes and disciplines when managing your project, you’re almost bound to fail. In particular, defining requirements accurately is very hard when writing software, and predicting the amount of effort required to produce a given feature is even harder. The two combined mean that approaches to project planning and management borrowed from other disciplines are often fairly worthless when applied to software.

InfoQ: How does agile suggest to deal with these challenges?

Gleeson: Essentially, what various agile disciplines like Scrum, XP and so on do is acknowledge the inevitable difficulties of the software development process that are caused by the unknowns in specification and estimation. By preventing one from trying to look too far ahead, by focusing on gathering data and learning from it, they reduce one’s exposure to the risk of making the wrong decisions early on. Perhaps controversially, I believe that iterative, incremental development of the sort that agile methodologies advocate is fundamentally somewhat inefficient - it leads to lots of meetings, lots of re-writing the same code, and so on. But by accepting those inefficiencies we can significantly de-risk software projects, and most of the time it’s a sensible trade-off: succeeding inefficiently is better than rushing headlong into failure.

InfoQ: When do you suggest not to use agile?

Gleeson: When you can’t get buy-in, from not just the software team but also the other stakeholders. People often forget that agile is a process that requires active participation from everyone involved, not just the developers. If you have a group of coders who are committed to, say, Scrum, but the executive who sponsored the project doesn’t want to come to fortnightly sprint reviews, that’s a recipe for disaster. Equally, if software only forms part of a large cross-disciplinary project, agile may not be for you: it’s a tool best suited to solve the problem of software project management, and it doesn’t always work when applied to, say, hardware prototyping, where successive iterations of a prototype can take months to put together.

InfoQ: What can managers do to prevent or reduce technical debt?

Gleeson: Time is the currency in which technical debt is accrued, and actually the financial metaphor works pretty well, because you pay interest on technical debt: the longer you let it stew, the further into debt you get. So the main thing that managers can do is fight to provide their developers with enough time to do their jobs to ensure that they don’t get into debt in the first place. Tech debt often crops up when requirements change and the code is jury-rigged to accommodate the change. Trying to prevent requirements from changing in software is futile - which is why agile is needed - so managing expectations to ensure that the response to change can be thorough, time-consuming ‘refactoring’ of software rather than debt-accruing jury-rigging is the biggest thing a manager can do to help.

InfoQ: Which programmer preoccupations should managers be aware of?

Gleeson: I think the most potent one is the love of the new. Software development is about constantly trying new things - because the stuff that’s repetitive can almost always be automated away - and this can lead to a tendency to fall in love with a tool, technology or technique simply because it is new. This can create a bias, and occasionally a total blind spot, that can cause developers to advocate bad decisions. Managers should always be on the lookout for situations where a preoccupation with the new is skewing a developer’s judgement.

Almost as powerful is hate. For a few different reasons (often to do with insecurity), developers can find themselves really investing in loudly disliking a particular language or tool, sometimes unreasonably, and occasionally quite counter-productively. In the worst case scenario it can create a toxic environment where other developers get belittled simply for the tech they have worked with in the past, creating tensions in a team. If a developer gets themselves into a state where they’re constantly railing against a particular piece of tech, it’s important for a manager to stop it becoming a problem, because it’s not productive and not healthy.

InfoQ: What's your advice for managers who want to establish a solid working relationship with coders?

Gleeson: Remember that coders are humans. Over the last 40 or so years, stereotypes of software developers have built up, often pretty negative ones, that characterise coders as almost a different species altogether. This is despite the fact that coding is a more and more mainstream profession, and people are arriving at it from a wide array of diverse backgrounds. So working from stereotypes about who coders are is very unhelpful. That being said, if you spend your day writing code, that affects your perspective about a lot of things, and it’s important for a manager to acknowledge that difference in perspective. For example, when building a user interface, a coder spends more time looking at the source code for that interface than at the interface itself, so it’s hard for them to always keep in mind how it will appear to the user. What’s going through a coder’s head when they talk about the interface will be very different to what’s going through, say, a graphic designer’s head. A good manager will anticipate and accommodate those differences in perspective, and take advantage of them rather than fight against them.

About the Book Author

Patrick Gleeson has been a coder and a manager of coders for the past 10 years. He has worked in a variety of organizations, from bespoke software consultancies to multinational corporations to tiny start-ups, and is currently CTO of Think Smart, a company that provides tools to help young people make better career choices. He also sidelines as a composer for film and theater, and once spent a year building animatronic puppets as part of a robot circus, including a mechanical octopus that played the xylophone.