Any trained software engineer knows that, in a development project, priority inversion means that a high-priority task has to wait until the completion of a low-priority task. Let me introduce an equally harmful type of “priority inversion” in managing software engineering forces: when priority is deliberately given to the least important and least complex activities at the expense of more impactful activities. Why would any sane manager do that? Hang on.
Introducing the case: “Just write the code; I won’t pay for anything else”
I recently discussed inside the company a situation in which one of our clients (if you just stumbled upon this post without any context, Auriga is a software development outsourcing company) denied our team any time spent organizing the knowledge gathered while investigating the product behavior. What the client said was, “I hired you to create the new version of the product quickly and efficiently, so I don’t want you to waste time on anything but writing code, and I will not pay for any time spent on putting together a knowledge base.” And, of course, the project was done on a T&M basis, so what we were doing and what they were paying for was their business, and it was their right to decide that. Right? Right. But…
You don’t hire service providers to “write the code”
But they did not hire Auriga to merely “write the code.” For that, they could have gone with a cheaper provider, or better yet, they could have contacted a couple of local high school kids and given them a detailed description of what “code” they should be “writing” on a day-by-day basis. Here is the algorithm; go type it in one of the programming languages. That’s easy. What Auriga was hired to do was not coding, but engineering—a significantly more complex activity in which the actual coding is one of the easiest and simplest parts.
Besides, as it often happens nowadays, a big part of the project involved not actually making changes, fixing bugs, and adding new features to the existing product, but at first “reverse-engineering” it. We were in possession of the code belonging to our client, and there were a couple of experts on their side who had actually participated in the product development years ago. But there was no architecture description, comments were scarce, and some of the internal protocols didn’t have any descriptions yet. So it was evident that Auriga’s engineers spent the majority of their working hours doing micro, mini, and mega spikes and investigating how the existing code actually worked, what fields were used in the network packets, or, for example, whether data was transferred as big-endian or little-endian values.
Doing activities other than coding is NOT a waste of time
The project was going well (No, it was not one of those projects that was doomed to fail from the beginning in which the client was making unreasonable demands only to make the provider give up and then make him a scapegoat.), and the team was growing. So it was no longer possible to keep all discovered information about protocols, APIs, and architecture in a collection of text documents at the back of an SVN repository. (Why documenting through comments and tests didn’t work is a topic for another, though related, story.) But the client didn’t let us spend any time on setting up and maintaining the knowledge base, knowledge management, or knowledge-sharing activities.
Well, at this point, you are probably saying, that was clearly wrong; the R&D project was evidently at least as much “R” as it was “D,” and dealing with knowledge was a very important element of the process. But, eventually, that’s an isolated case, why all the big words about “priority inversion.” Well, that was indeed one specific situation that we had to deal with, and we had to explain to the client why it was in their best interest to gather this info once and for all rather than have it re-discovered every other month by a new team member. But bear with me as I switch to a more general topic.
What percentage of time should be spent on coding?
Auriga executive management once gathered to discuss and revise the definition of services we provide to our clients. And since every one of us had experienced cases such as that mentioned above in the past, we went over what percentage of time the team should spend on coding. The general feeling was that the most appropriate figure was something like 80% and that many of our clients would lose interest in our services if it was less.
If you want my personal opinion, I can tell you that this figure is a clear indication of the priority-inversion paradigm widespread among those who manage software engineering activities. I am confident that the engineer should spend as little time as possible actually writing code and as much time as possible optimizing it. That implies preparing and maintaining solid testing, development, and the integration environment; writing tests (Ok, many managers include this in coding, but you’d be surprised how many don’t!); designing algorithms; learning new things; capturing knowledge; communicating with colleagues, clients, and end-users; and, above all, thinking. So, for me, it turns out that the ideal percentage of coding should be around 10%.
Determining popular beliefs
I later checked the Internet to find out if I was alone in my delusions. Fortunately, I found that there are other experts that share my opinion. Just check the following links: Many seasoned professionals place the norm at about 5–10%:
- What Do Programmers Really Do Anyway?
- How Much Time Do You Spend Developing/Writing Code? (http://www.coderanch.com/t/630523/Jobs/careers/Time-Spend-Developing-Writing-Code)
- Some Lesser-known Truths About Programming (http://automagical.rationalmind.net/2010/08/17/some-lesser-known-truths-about-programming/)
- How Software Developers Really Spend Their Time (http://readwrite.com/2013/04/25/how-software-developers-really-spend-their-time)
The last contribution is actually an attempt to show how much time is usually wasted. But there are some great thoughts in the Comments section of the article illustrating the idea that “coding” is seriously overrated as the main activity in software development.
The best concise argument I have added to my range was provided by a commenter on the same entry:
I often compare writing software with doing a crossword puzzle. How much of the time spent on a crossword is writing the letters in the boxes? Not much.
I couldn’t agree more.
Of course, the subject itself needs much more attention, and I may return to it in my future posts, but it is quite enough food for thought for now. I hope you were not distressed by the questions raised, and I will see you in my future posts.
