Development Overhead

What does a developer spend his time on? Writing code, debugging, thinking and communicating with colleagues (that includes meetings). Anything that is beyond these activities is unnecessary overhead (some meetings are also unnecessary, but that’s a different topic).

And yet, depending on our language and tools, we have to do a lot more to support the process of writing code. These activities include, but are not limited to:

  • manually format your code – the code has to be beautifully aligned and formatted, but that’s an extra effort.
  • using search and replace instead of refactoring – few languages and tools support good refactoring, and that’s priceless in a big project
  • manually invoking compilation – compile on save gives you immediate feedback; the need to manually run a compiler is adding a whole unnecessary step to your coding process
  • slow compilation – ontop of the previous issue, if your compiler is slow, it’s just a dead time (mandatory xkcd)
  • slow time-to-deploy – if the time from writing the code code to running it is more than a few seconds, then you are wasting enormous amounts of time. E.g. if you need to manually make builds and copy files on a local server.
  • clunky resource navigation – if you can’t go to a given source file in a couple of keystrokes
  • infrastructure problems – you depend on a database, a message queue, possibly some external service. Installing and supporting these components on your development machine can be painful. Recently we spent one day trying to integrate 3 components, some of which had docker instances. And on neither Windows, nor Mac, Docker worked properly. It was painful error-google-try-error-google process to even get things started. Avoid immature, untested tools (not bashing docker here, just an example, and it might have already been improved/fixed)
  • OS issues – if your OS crashes every couple of days, your I/O is blocking your UI, you sometimes lose your ALT+TAB functionality (which are things that I’ve been experiencing when using Ubuntu), then your OS is wasting a significant amount of your time.

Most of the manual tasks above can be automated, and the others should not exist at all. If you are using Java, for example, you can have a stable IDE, with automatic formatting and refactoring, with compile-on-save, with save-and-refresh for webapps. And you can use an operating system that doesn’t make you recompile the kernel every now and then in order to keep it working (note: hyperbole here).

It’s often a tradeoff. If I have to compare Java to Groovy in terms of productivity, for example, the (perceived) verbosity of Java is a minor nuisance compared to the lack of refactoring, formatting, etc, etc, in groovy (at least that was the case a few years ago; and it’s still the same with scala nowadays). Yes, you have to write a few lines more, but it’s a known process. If you have immature tools that are constantly breaking or just don’t work (and that is the case, unfortunately), it’s unknown how you should process. And you may end up wasting 10 minutes in manual “labour”, which would kill the productivity that a language gives you. For me Linux was also such a tradeoff – having the terminal is sometimes useful indeed, but it did not justify the effort in keeping the system working (and it completely died after a version upgrade).

Because I really feel all that overhead draining my productivity, I am very picky when it comes to the technologies I use. Being able to type faster or write less lines of code is fine, but you have to weigh that against the rest of the procedures you are forced to do. And that’s part of the reason why I prefer an IDE over a text editor, I don’t use Emacs and I don’t like Scala, and I don’t use Linux.

Your experience may very well be different (and if facebook checking is already taking half of your day, then nothing above really matters). But try to measure (or at least observe) how much time you spend not doing actual programming (or thinking) and have to do “automatable” or redundant stuff instead. And try to ignore the feeling of accomplishment when you do something that you don’t have to do in the first place. And if your preferred technologies turn out to be silently draining productivity, then consider changing them (or improving them, if you have the spare time).

5 thoughts on “Development Overhead”

  1. I couldn’t agree more. It becomes clear after you have to maintain a project after somebody else. No matter how bad the code was – if it was written in java – you can often handle it by refactoring, piece by piece. But if it’s poorly written javascript then you can really start to hate that language (even though the language itself is not so bad, but you have maintain some standards while creating it).

    I also agree about other stuff. If your deploy/release process is taking too long, you have to improve it by using some build tools, etc.

  2. I was totally with you until “…I don’t use Linux”.

    But your point is the same whether or not one uses Linux. If it’s useful and saves time, use it. If it doesn’t, don’t. (A restatement of Miyamoto Musashi’s “Book of Five Rings”: “do no useless thing.)

    I will say though, if you’re fortunate(?) enough to be able to do everything inside your IDE or Java or whatever, then you’re in a pretty rare place. I have to script stuff all the time in *support* of the rest of the work we do, and w/o my simulated (cygwin) linux under Windows, I would be forced to do many tedious things… manually.

    (And one of these days I’ll ‘throw off my chains’ and put windows in a virtual where it belongs, just so I can use Outlook, and do everything else in Linux. πŸ™‚ )

    IOW, don’t knock it if you haven’t had the need for a “real” operating system. πŸ™‚ http://tomayko.com/writings/that-dilbert-cartoon

  3. I agree to a point, but that point is very early in your reasoning. I do not pursue new tech on a whim, but I try to observant about thing. I also try to follow the maxim: Do it one time and don’t fret, do it twice and pay attention, do it three times and automate. I have two acquaintances: one was an electrical engineer who only knew fortran. He wrote a compiler in fortran to show me that it was the only language necessary. The other used a spread-sheet to write a document because he did not know how to use an editor. And then he did it again. And again. They both used the argument that what they knew at the moment served them and they did not have time to learn how to use newer (and to their point of view, irrelevant) tool.

    Not learning Scala or Clojure because you can do the same thing Java is a very short term excuse. The productivity improvement will compound as you gain expertise. Programmer productivity is consistently “lines of code per day” irrespective of the actual language used. That means that if I can write 50 lines of code a day, and I am using Java, then I get less work done than using Clojure (or some other more expressive language).

    As far as not using linux, That baffles me. Working on windows is a constant battle with trying to get things working on a toy operating system. You constantly have to work around differences and deficiencies to achieve tasks that just work on a *nix based system. It may be the devil you know, but that devil is now, and always has and will be stabbing you with his pitchfork.

Leave a Reply

Your email address will not be published. Required fields are marked *