Ever wondered what Programmers do all day long? Are they just typing code non stop?
Let’s investigate it.
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 metrics or not is questionable.
“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. Let’s see what are different studies found:
- Fred Brooks said 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 (10,000 LOC) through to 1.5 to 25 LOC per day for large projects (10,000,000 LOC).
It’s not many, is it?
Quite shocking instead.
From my experience, I write much more code on some days but very few on other days. I can write 10 lines of code in a minute easily so I should produce 4800 LOC easily on a day average.
Ever wondered what else a programmer can do apart from coding?
Let’s investigate…
Spending Most of Our Time Figuring Out What Code To Write
What can be the difficulties to write code? What are the prerequisites of writing code?
- Reading and understanding existing code: The existing code base is hard to understand. Developers spend loads of time to understand the existing code then translate it into the context of the problem they are trying to solve finally writing down the final code is just the end product of a longer journey.
- Mapping out the architecture, the big picture: developers need to see the big picture and understand it first, before changing that few lines of code, most of the time lack of documentation of the architecture makes the developer life very hard.
- Understanding the business process: developers also need to understand where the line of code fits in to the business processes. This process can be very difficult as normally:
- Nobody knows how it works anymore. The people who developed the software have gone long time ago.
- Documentation is out of date.
- Difficult to correlate the domain processes and the code.
The time spent on the figuring out bit depends on the developer’s experience, business knowledge, how the code is organised, how clean and readable the code.
Moving an experience developer to a badly written, -architected and -documented project also needs to spend the extra time.
Also a productive developer on a familiar well designed, -architected and -documented project can be very unproductive on an unfamiliar low quality code base.
What Can Be Done To Reduce The Time Spent On Figuring Out What Code To Write?
Design A Software Architecture That Is Easy to Understand For Anyone Independently From Experience, Business Knowledge
It’s hard to extract architectural concepts and business processes from code but it shouldn’t be that 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 on figuring them out, mapping them to the code so we would be more productive of writing more line of codes.
Code should be informational and tell what are the business processes, we shouldn’t go to the drawing board to visualise the current state of the business processes, code should visualise it.
Use Architectural Abstraction
Architectural abstractions help to express that a piece of code (module, package, class, method…) implements an architectural concept. It makes easy for the human reader to determine what kind of architectural concept a given code is.
It can also allow tool integration to do interesting stuff like generating persistence or static architecture analysis to check for validations of the architectural rules.
Expressing DDD concepts also very useful. It can give a free documentation.
For Java jMolecules is a project to provide Architectural Abstractions. It uses annotations to document to make architecture and DDD concepts readable.
Structurizr is also a great tool to visualise well designed code base into architectural view.
Use Bounded Contexts To Find Boundaries For Sub Systems
First of all, let’s clarify what is a Bounded Context (BC)?
A context means a specific responsibility. A bounded context means that responsibility is enforced with explicit boundaries.
For instance:
The IT department is a bounded context. It has the responsibility to handle everything IT related in the company. The Accounting department handles everything accounting related, including payrolls. Both have very precise responsibilities and their boundaries are pretty explicit.
Both are respecting each others boundaries and act according to their responsibility. But the IT department is itself organised in 2 groups: the software development group and the administration group. The first group implements features and fixes bugs. The second group handles servers. Each group is a bounded context as well. They have their own responsibility and explicit boundaries.
We can use tools like Bounded Context Canvas to find the optimal boundaries for sub systems.
You can use tools like Contexture to automate the Bounded Context Canvas.
Use Message Flow Modelling To Define Interactions Amongst Bounded Contexts (Sub Systems)
Focusing on the boundaries aline will not lead to good design. Focus on the interactions between BCs. To design loosely-coupled systems, you need to uncovered all the hidden coupling.
Bounded Context Canvas defines the incoming and outgoing messages to and from the BC.
Is the message a Command so the sender decides what happens or an Event and the receiver decides what it does?
Is it an Orchestration or Choreography?
Minimal (only id) or Fat event?
Domain Message Flow Modelling is a tool to help modelling and visualise the interactions.
It is a good tool to use as a peer reviewing the architecture similar to the pull request for code.
Core Domain Charts To Identify The Most Important Sub Modules
Every architectural decision has business consequences so a good architect needs to know the business model very well.
Core Domains are the parts of your domain where the expected ROI is greatest, and deserve the highest focus.