Programmer Performance Optimisation

Software developers are not generally IO-bound. The speed at which I can type is not the bottleneck in terms of how fast I can produce software. I’m definitely CPU-bound. This means that there is little performance gain to be had from scaling out to 1 or more keyboards per developer. The pipe between my brain and the IDE is fairly idle a lot of the time, with occasional bursty traffic that still comes nowhere near 50% of the available bandwidth, even on a single half-duplex keyboard architecture.

As developers are generally CPU-bound, scalability can be achieved by moving to a multiprocessor configuration, with 2 developers sharing the same IO channel. The instruction pipeline optimization that can take place with a shared memory configuration can result in a better than linear performance increase.

Rewrites

I’ve worked on a few migration / rewrite /port projects in my time. They almost universally had no technical merit in and of themselves. From a developer’s perspective, a rewrite of an existing system basically means taking a stable, tuned application, freezing all new features, and writing it again in a language that’s newer, possibly more buggy, and probably less familiar to many of the team members, and delivering at best exactly the same features as the existing system, while taking several months to do it, with a risk of introducing new bugs along with it.

Migration projects are almost always done for political or cost reasons. Either the company has decided on a strategic plan to ‘go Java’ or ‘go .NET’, or (possibly less high profile, but potentially more significantly), is having a progressively harder time retaining developers with the skill set needed to support the existing system. Technology can also be made a scapegoat – so if a system is delivered that runs too slowly, or crashes a lot, the entire platform it happened to be developed with is proclaimed as ‘slow and unstable’, and the baby is thrown out with the bathwater.