Latency and Software Developers

I was recently having a conversation where someone asked me to compare real time and low latency Linux kernels.  I used the phrase “real time is the enemy of low latency.”  This caught some attention and I was asked to explain what I meant.  In order to accommodate the needs of real time processing we need to add a certain amount of overhead so that we can accurately and reliably predicate the amount of time that a procedure will take to complete.  In order to do this we incur a certain amount of overhead and this overhead contributes to latency.  In order to move as quickly as possible we would have to remove this overhead and thereby decrease latency but without having the predictability for which the overhead had allowed.

Today I was reading a paper on Agile development and traditional software development methodologies and it occurred to me that we were essentially talking about the same concept.  Programmers are a lot like organic, squishy CPUs chugging along churning out data.  The concept behind traditional development methodologies (or schedulers, if you will) was to make sure that developers were able to turn out a project or a piece of a project in a predictable nature – so predictable that projects could be projected years in advance with meeting rooms scheduled and the caterers hired for the release party.  This predictability is provided by the inclusion of a large amount of management overhead that hinders rapid development.  All of those status meetings don’t come for free and incur large amounts of lost productivity in exchange for keeping management up to date as to the release schedule.

Agile development takes the opposite approach.  In Agile the idea is not predictability, at least not to the same extreme level.  Agile really focuses on producing software with minimal latency – getting it done and out the door as quickly as possible even if that ends up surprising the marketing and sales departments and no box art has been approved yet.  It does this by lowering the management overhead and reducing artifacts that interfere with the actual job of producing a product allowing the team to move more quickly.

Leave a comment