Working with Developers

If you have never developed software, the process can seem opaque and confusing. Understanding what motivates developers and what they sweat can help you achieve better results when you are collaborating with them.

Although I do a couple of different things at work, I spend the lion's share of my time as a web developer. I do not work at a software development company though, but instead as a part of a larger company that develops software to accomplish other ends. This means I regularly work with lots of people who have never developed software before (and maybe never wanted to). My goal here is to give non-developers a better sense of what developers do so that projects go more smoothly, cost less, and finish with higher quality. I feel like, for a person who has never written software, developers may be a little too mysterious, and so I hope to clear up some of the mystery here by explaining

  • what we love about developing software
  • what are a developer's inner conflicts that s/he is trying to balance against; these conflicts can tip your project from awesome to nightmare if not mitigated
  • what being a developer does to your brain; that is, where do developers fall down
  • what you can do to make your projects more successful when working with developers

Of course, I have a few caveats. This is heavily influenced by the specific setting of my work experience and the teams I've been on; I can't claim this post is universal. In writing this out, I've also come up with some improvements and projects for myself and my team, and in that respect, I recommend other developers try writing something similar up. Finally, as always, I speak only for myself here, and not for my employer or colleagues.

Why We Love Developing

Developing software is not like normal life activities; it allows you to translate your thoughts and needs into tangible devices that realize your intentions and solve your problems. Software developers, at least ones like me in small shops, are not disconnected from the product of their labor. In the software development classic The Myth of the Man-Month, Frederick P Brooks, Jr. explains

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (Ch. 1)

And it is this, I think, that is so intoxicating. The day-to-day of software development is mentally taxing, often frustrating, and a little lonely. But the result is the ability to solve complicated problems almost out of thin air. Even better, the things we make are virtually tangible; we do not usually create processes and memos of understanding, but instead systems with interfaces and outputs that people actually interact with. Having a product that you can point to with capabilities that you can describe is strikingly satisfying.

Problem solving is important to the developers I know. We are not exactly artists (at least not all of us); we do not create things just to delight and evoke. We like to make things that make life easier, things that are used, things that people care about. We hate inefficiency and people doing tasks that machines can do, and we like making machines do repetitive tasks. We also like to learn something in the process; once you're hooked on developing software, there's a strong urge to get better at doing it (and to make it less frustrating, mentally taxing, and time consuming). 

What Are Developers' Inner Conflicts

Developers are, like all creative people, tormented by several sets of tradeoffs (or inner conflicts) and systemic problems in their craft. The most frustrating (and, paradoxically, enriching) can be pithily summarized:

  • Software is an asset, source code is a liability (thanks to Alan Cooper for the formulation)
  • Change is inevitable, and potentially very expensive
  • You have to use a computer to run a program
  • Adding people to a late project makes it later (Brooks's Law)

Software is an asset, source code is a liability

Developers work to create software. Software is the stuff you use on your computer: your web browser, word processor, favorite game, and websites like Twitter and Google. Software is clearly an asset; it makes your computer do valuable work and makes your life easier. To make software, we write source code (code for short) in a programming language, which is then translated eventually into software you can use. It's at this making software part that things go to hell.

The trouble is, every line of code we write is fraught with problems:

  • The more code, the more room for bugs; we translate fuzzy ideas into very concrete logic — sometimes, that logic is imperfect, especially when it is very complicated
  • The fastest, most secure code is the code you never wrote; the more complicated the code, the more room for performance and security problems
  • We're in our programs for the long hull — the amount of time we spend actually writing new code is small, compared to the time we spend maintaining existing programs; every new line is another line you need to understand 14 months from now
  • Writing code forces concrete decisions, many of which we make on the fly; every line is a potentially misunderstood intention, which we will later have to delete and rewrite
  • Code rots; we upgrade systems, add features, and fix bugs, any of which can break some older code that we haven't even touched

As such, we want the simplest design that will meet your needs. We love consistency; every special case means more code of questionable long-term value. (Special cases are the most expensive when someone is trying to understand code a few months or years later, or when we're trying to make a major change — like responding to a real-life customer need). When planning software, we want people to justify that the features they want will be used, because once we write the code, we have to live with how it affects the rest of our programs for as long as they're used. Worse, unused features can block us from quickly implementing new, actually useful ones.

Change is inevitable, and potentially very expensive

We know much of the code we initially write will be changed. We will imperfectly understand a client's requirements. The client will misunderstand much of his or her own needs until s/he sees them made concrete as software. The situation surrounding the software will change, requiring the software to pivot to meet reality. 

The trouble is, change is often expensive. There are two types of change: ones we planned for and ones we did not. With anticipated changes, we can typically make a change without disrupting the system; we've made ourselves places to configure the change, or ways to plug into the existing code without disrupting existing parts of the system. In unanticipated changes, most anything could happen — the change could be very simple, or it could require we rewrite 80% of the existing system.

An example could make this more concrete, using one of my favorite sites I've developed: DC Green Scene, a calendar of energy and environment events in DC. The calendar has a variety of filtering options, such as filtering by date, event type, and event topic. We anticipated the topics would evolve over time, and so we made it very simple to add new ones; adding and removing topics doesn't require a programmer. We actually capture a lot of information we could filter on (such as event location and cost), and adding these as options wouldn't be terribly complicated either.

However, imagine that we realized we were missing some critical variable in our filtering, such as the event size (to differentiate small meetings from conferences). This we did not anticipate, and it requires the following types of change (with the language required to make the change in parentheses):

  • Add the size field to the database, and figure out a way to add event-size data to the existing events in the database (SQL)
  • Add size filtering options to the code that actually executes the filters (Python)
  • Add the size information to the event's display on the homepage and on the event's page (HTML, CSS)
  • Add code to execute the size filtering dynamically (Javascript) 

So for this relatively simple change, we end up changing about seven files and using five different "languages." This doesn't count the design and usability work required to make the new feature work with the existing look. And that first change, where we need to collect new data about old events, is potentially a nightmare of busy work, or a confusing usability problem as we try to signal that size filter doesn't always work.

The natural question is, of course, why not make the system infinitely flexible, so that every change is simple? We certainly strive for simple, flexible systems, but often flexibility simply adds complexity to the code. A developer will sometimes say a system is over-engineering: this is when a system has been designed to be highly flexible in ways that no one will ever use. In such a system, simple tasks can become very complicated, because you use the same machinery for simple tasks as you would for very complex ones. Worse, you end up with lots of extra, unused code, which I'm sure you understand is undesirable after reading this far. 

Thankfully, there's a mitigation here: the earlier you realize you've made a mistake, the easier it is to fix the problem. When we first started writing DC Green Scene, we could easily add new fields to capture data and filter that data; there wasn't nearly as much code to upset at the beginning as there is now. Paying attention to mockups, prototypes, and early demos is essential; I know they usually look strange and it's hard to get past the interface, but seriously working with a prototype or half-functional product can save a ton of time down the road.

You have to use a computer to run a program

The essence of a developer's job is translate a human's ideas into instructions for a computer. Computers, however, are very unlike humans. Computers are terrible with assumptions. They cannot be given a vague picture of what you want with a little context and understand it. Everything must be described in minute detail. This means

  • every little detail requires a decision — what order things should be listed in, whether punctuation is bold or not, everything
  • when we tell the computer to do something stupid, it does exactly what we told it to

Sometimes, we use systems that provide functionality for us (e.g., when we use a content management system or some other customizable application). Unfortunately, this really just means that someone else made a lot of decisions for us, which might be great and might be totally wrong. In the end though, someone has to sweat the details, or they won't exist in the software at all.

Adding people to a late project makes it later

I used to hate estimating the timelines and costs of software projects. The trouble is, if you haven't written a type software before (e.g., someone asks you how long it would be to make a facebook competitor, but you've never written social networking software), it can be very tricky to have any clue where the pain points will be — and it's in the pain points that your project starts to slip. What always made this process more difficult is the realization that whatever we spec at the beginning will change, but deadlines typically won't.


From the outside, both of these problems look like they could be solved by simply bringing in additional staff. If we get behind due to some unexpected technical trouble, or if the client realizes they need some difficult-to-implement realtime prediction system, we'll just bring in some freelancers. Unfortunately, adding additional developers to a late project will just make it later. The logic here is that once you have a substantial amount of code, it can take longer to bring someone up to speed than it would to implement that person's features. The problem is so well understood, it even has a name and a wikipedia entry: Brooks's Law

Brooks's law has implications: the initial team has a huge effect on the final delivery of the software, and new features added later in the development process likely mean the removal of some other, not-yet-implemented features. If the scope of a project expands substantially beyond its initial description, it will likely be impossible to meet the initial deadline.

A bonus conflict: Writing code requires a ton of focus

Finally, there's a problem that I couldn't pithily summarize but that feels too important to leave out: writing code requires an excess of focus. The number of things you have to remember to write a web application is absurd; I once read programming is the art of balancing an impossible number of details long enough to get an idea into your text editor.

Writing complicated code requires a specific state of mind akin to writing a flowing narrative; you need focus that excludes most everything else, and if someone breaks that focus, it can take hours to get it back. Paul Graham writes about the implications of the state of mind required to write code in Maker's Schedule, Manager's Schedule:

Most powerful people are on the manager's schedule. ... But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

This means many little interruptions through a day or meetings dotting the morning or afternoon can cause sizable delays by making it hard to get the necessary concentration to implement large features.

For my team, there are additional scheduling considerations: We divide all our work into two phases, development mode and deployment mode:

  • During the development cycle, we tend to work more slowly and carefully, while at the same time taking bigger risks with the code. These bigger risks mean that we can make bigger changes that are actually maintainable.
  • When we're in deployment mode, we expect we're going to be making our software available generally very soon; thus, we are looking to break as little as possible and work as quickly as possible — so we cut corners and add quick and dirty fixes, which we hope to resolve during the next development cycle.

The trouble comes in when we're in contant deployment mode (because the schedule was unrealistically agressive, the scope crept, or the content or approvals didn't land). When that happens, if we're rushing and just piling features in without adequate planning because deployment is "any minute now," we may end up making a mess of our own codebase, making later features much more expensive.  

Where We Fall Down

There are a few areas where I have noticed my developer friends and I fall down, I think likely by the nature of our jobs. As every developer is different, any one might be able to combat some of these deficiencies, but they're worth looking out for as a non-developer.

  • It's easy for us to get the "new/shiny's," wherein we find neat new technologies that solve some problem we've recently had; unfortunately, this is how a two person development team ends up with eight products written in six entirely different languages — making it very hard to staff properly in the future
  • We have trouble keeping the really big picture in mind; developing is a lot of very detailed work; unfortunately, that doesn't leave a ton of room for keeping the master plan in mind, which makes it progressively harder to give high level feedback on projects as we get into them
  • We can't know for sure if what we've made meets your needs; only you know what you really had in mind, which means your attention and testing are crucial for knowing whether we've correctly implemented a project.
  • The last 10% of any feature is hideously boring: it turns out that the last 10% of a feature is usually figuring out all the little ways that the other 90% break or are hard to understand, and so is really tedious, time consuming, really important — and we might need a little push to get through it.
  • We over-rely on technological solutions: I know I often assume that we need to automate some process that no one expects or even wants to be automated; I assume people should do as little work as possible, even if it's very time consuming (and thereby expensive) to get the computer to do some simple piece of person work.

The valuable thing about realizing these weaknesses is that you can then combat them; knowing is, after all, half the battle. For example, at home I'm constantly playing with new applications, frameworks, and languages, but at work I'm pretty conservative about allowing new technologies into our stack; the more technologies you have to know, the less time you have to know any one of them well. 

What Can You Do To Help?

Armed with an understanding of what motivates developers, what makes them crazy, and where they're prone to weakness, you're hopefully brimming with productive changes you can make to improve the software products your company produces. Hopefully, you're thinking that going forward, you'll

  • think hard about what you want, finding good examples of similar products to clearly communicate your desires
  • think hard about the value of new features that you ask for during development, and think about which already-agreed-upon features you can live without to get your new features
  • sweat the details of projects together with your development team
  • pay close attention to prototypes and early demos to catch misunderstandings early
  • embrace technology — I'm not kidding; the more conversant you are with technology, the more likely you will be able to think about your problems in a concrete way that we can actually solve
  • remember that the most flexible system is not necessarily the best system
  • be realistic with your deadlines, knowing now that constant deployment leads to long-term panic