What Do Software Developers Actually Do All Day?

Ever wondered what programmers actually do all day? The assumption is that we type code non-stop. The reality is quite different.

How much code do programmers average per day?

Lines of code (LOC) is a simple way to measure programmer productivity — whether it is a useful metric is another question entirely.

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

— Bill Gates

But it is at least easy to measure. Here is what different studies found:

Fred Brooks wrote in The Mythical Man-Month that programmers working on the OS/360 operating system averaged around 10 LOC per day
Capers Jones measured productivity of around 16 to 38 LOC per day across a range of projects
McConnell measured productivity of 20 to 125 LOC per day for small projects through to 1.5 to 25 LOC per day for large projects

Not many, is it? From my experience, I write much more code on some days but very few on others. I can write 10 lines of code in a minute — which should mean 4,800 LOC in a day. So where does the rest of the time go?

Spending most of our time figuring out what code to write

What are the prerequisites of writing code? What slows us down before we’ve typed a single line?

Reading and understanding existing code — the existing codebase is hard to understand. Developers spend enormous amounts of time translating existing code into the context of the problem they are trying to solve. The actual writing is the end product of a longer journey.
Mapping out the architecture and the big picture — developers need to see the big picture before changing a few lines of code. Lack of documentation of the architecture makes this very hard.
Understanding the business process — developers also need to understand where the line of code fits into the business processes. This is difficult when: nobody knows how it works anymore (the people who developed the software left long ago), documentation is out of date, or it is difficult to correlate domain processes and code.

The time spent on figuring things out depends on the developer’s experience, their business knowledge, how the code is organised, and how clean and readable it is. An experienced developer moved to a badly written, poorly-architected, undocumented project will also spend the extra time. Productivity is contextual.

What can be done to reduce that time?

Design architecture that is easy to understand

It is hard to extract architectural concepts and business processes from code — but it shouldn’t be, because:

“A codebase is a database of architectural and business domain information.”

If we could easily extract architectural and domain concepts from a codebase, we would spend less time figuring them out and more time writing. Code should be informational. It should tell you what the business processes are. You shouldn’t have to go to a drawing board to visualise the current state of the system.

Use architectural abstraction

Architectural abstractions help express that a piece of code implements a specific architectural concept. They make it easy for the reader to understand what kind of architectural pattern a given class or module implements.

They also enable interesting tooling — generating persistence, running static architecture analysis to validate architectural rules. Expressing DDD concepts in code is particularly useful; it provides a form of free, live documentation.

Use bounded contexts to find boundaries for subsystems

A bounded context defines a specific responsibility with explicit boundaries.

Consider: the IT department is a bounded context — it handles everything IT-related in the company. The Accounting department handles everything accounting-related, including payrolls. Both have precise responsibilities and explicit boundaries.

The IT department itself might be organised into a software development group and an infrastructure group. Each is its own bounded context within a larger one.

Tools like Bounded Context Canvas help you find the optimal boundaries for your subsystems — a useful discipline before you start building.

Use message flow modelling to design interactions between subsystems

Focusing on boundaries alone will not lead to good design. You also need to focus on the interactions between bounded contexts. To design loosely-coupled systems, you need to uncover all the hidden coupling.

Key questions to ask about each interaction:

Is the message a Command (the sender decides what happens) or an Event (the receiver decides what it does)?
Is it Orchestration or Choreography?
Is it a minimal event (ID only) or a fat event (full payload)?

Domain Message Flow Modelling is a useful tool for modelling and visualising these interactions — and a good candidate for peer review, similar to code review for architecture decisions.

Core domain charts to identify the most important submodules

Every architectural decision has business consequences. A good architect needs to know the business model well.

Core domains are the parts of your domain where the expected return on investment is greatest. They deserve the highest focus, the best engineers, and the most deliberate design decisions.

Not every part of your system is a core domain. Understanding which parts are — and which are generic or supporting — shapes where you invest your architectural effort.

The productivity of a software developer is not measured in lines per day. It is measured in how quickly they can understand the problem in front of them and translate it into code that will still make sense to the next person who reads it.

Design systems that make understanding easy, and the code part takes care of itself.