Let’s first talk about the phenomenon called “Lump of Coding Fallacy”. People (including software developers/engineers) assume that software development typically consists of people sitting down and spending their work day writing code. Upon closer examination, it becomes obvious that such assumptions could not be more wrong.

Even doing a little bit of introspection quickly reveals that so-called coders are spending just a fraction of their work hours actually coding.

So if that’s not the case (gasp!), what are those highly paid coders wasting hours on? Browsing Twitter/social media? No, not really. Most of the time spent in the typical workday of a coder is spent on two activities:

1. Scanning/reading code (other people’s code as well as code written by the programmer who is doing the scanning/reading)
2. Geek-at-keyboard activities (GAK)

If a coder is spending hours upon hours scanning/reading code, that time is certainly not productive. They are getting paid to get entangled in opaque code, trying to make some semblance of a sense that is buried inside lines of code. As an employer, I certainly do not want my money to get spent of such non-productive activities.

How to fix this haemorrhaging? Insist on quality software development principles, processes and practices. We call it clean architecture, clean design, clean code (read up on it, if you need a refresher).

If the architecture/design/code are clean, there will be no need to spend hours/days scratching one's head trying to figure out what is the code supposed to be doing, and how to modify it without risking breaking some important functionality.

So we see that clean software practices are one strategy to reduce the snowballing cost.

What’s the other strategy? Minimize GAK activities (the other wasteful software practice).

What are GAK activities?

GAK activities relate to time wasted at the keyboard (actually typing) that does not produce any code. Again, as an employer, I don’t want my money to go toward financing such wasteful activities.

When are coders using the keyboard to type and not produce code? There are several such situations:

1. Debugging
2. Entering test data
3. Playing with the environment/configuration

None of the above three activities produces code. People can spend hours/days/weeks in such unproductive state. I’ve witnessed developers waste entire workday on some frantic debugging. No one should be expected to get paid by wasting hours debugging. Why? Because if you need to debug the code you wrote, that is a clear evidence that you don’t know how to write code in the first place.

What about the situation where a coder has to debug other people’s code?

If some code other people wrote is so opaque that it cannot be understood without starting a debugger and stepping through it line by line, it is unsalvageable. At that point, coders should cut their losses and ditch that code and write the needed functionality properly.

What’s the problem with entering test data? This type of activity is non-productive. Making changes to the code and then re-entering some data in order to test it is one of the worst ways to waste other people’s money. Such activities must be banned from the software development teams.

What about spending time configuring the environment? Again, it is wasteful and should be banned from the teams. Dependence on environments and infrastructure is a surefire sign of dirty architecture, dirty design and dirty code (read up on Alistairs Cockburn's Hexagonal Architecture).

How to avoid slipping into GAK activities? Two-pronged solution:

1. TDD
2. Service Virtualization

In summary, the best way to minimize the cost of software development is to engage mature teams who are well versed in producing clean software. At the same time, instigate strict policies that ban any GAK activities during work hours on the project.