If by means of efficiency, superior process, and automation one person can do in an hour what another person would take a day to accomplish, then deliverable value cannot be measured simply as a function of the quantity of time spent performing a specific task.  It’s the tangible results that count.

 

Nowhere is this more evident than in technology, and in the software industry in particular.

 

It isn’t enough for software developers to simply be “busy.” The real question is: What are they actually getting done – in what quantities and in what state of quality?

 

It is these types of questions that brought to mind the concept of “velocity” with respect to software application development.  This is an important element of Agile software development.  However, to track production velocity, one must first define an accepted unit and scale of measurement.

 

For example, it is clearly understood when referring to a vehicle’s velocity, to measure it in terms of Miles Per Hour (MPH).  That’s because a mile has a specific measurable definition of 5,280 feet.  And, likewise, an hour is a specific measure of time, sixty minutes or 3,600 seconds.  From those two quantified variables, we get the formula:

 

Distance = Velocity x Time

 

Or it’s variant to determine Velocity:

 

Velocity = Distance ÷ Time

 

Is there an equivalent measurement of velocity when it comes to building software applications? 

 

Maybe something like: Lines of Software Code per Hour?  Not exactly, since there is no such thing as a standard length of a line of code.  A line of code can consist of a few characters, or it could be long, complex equations of variables, commands and functions.

 

Then we must consider the idea of efficiency and quality, beyond just sheer volume of lines of code. 

 

Some talented developers are able to produce very concise code that performs its job vastly better than the inefficient “spaghetti” code written by an amateur, bloat-ware that might indeed be of much greater volume, but is of lower-quality performance.

 

Then there is the notion of automation to roll into the mix.

 

In the context of “Low Code Development” we’re referring to all manner of automated tools that enable the development process to be accelerated exponentially.  Not all software applications have to start with a blank page.  Many functions in software applications are identical to what is needed to be added to other new applications, and therefore there is no prohibition to “copying and pasting” elements that have already been created, tested, debugged, etc. and are ready to use.

 

Many automation tools make development of common tasks a simple function of pointing and clicking via a visual interface to produce ready to execute code.  This is especially true in the cases of web development and mobile apps.

 

In reality, in the software development world, and within the Agile development process in particular, measuring velocity tends to be more of an internally-referenced and more subjective measurement, rather than something universally objective across an industry.

 

That is, an Agile development team may start out with a  prioritized Product Development Roadmap.  From that roadmap, a team is given its development goals for its next Sprint.  Within those goals, a Scrum Master breaks down those goals into specific tasks and assigns them to team members based upon each task’s priority and how it is “sized.”

 

That is, when it comes to task sizing some teams use the “Tee-shirt” model of Large, Medium, and Small.  These sizes are supposed to reflect the amount of effort estimated to complete the task, i.e. in terms of an estimate of hours.  The hours are then documented on a Burn-down Chart.  And then every day the Scrum Master gets an update from each team member as to how many hours have been expended on each task, which in turn lets the Scrum Master see the rate each task is getting “burned down” to zero, which represents completion.

 

So the concept of a productivity rate does indeed exist, but it is always relative to individual team members actual performance on specific tasks.

 

Presumably, over time, the Scrum Master will be able to observe which team members produce the highest quality work in the shortest amount of time.  Conversely, if a team member consistently fails to complete their tasks within a sprint, then there is occasion to determine why.  Is it the team member’s lack of timely performance?  Or, was the task’s estimate calculated wrong?  Was the task properly understood?  There could be many reasons for a failure to perform as planned.

 

The point is that the productivity rate matters – not just the number of hours someone spends working on something.

 

However, as noted, quantity of production isn’t the only consideration.  Quality is just as important.  This is one of the hallmark benefits of the DevOps approach to development.

 

In DevOps, new software isn’t just built, tested and deployed, but it subsequently gets monitored in full production operation, looking for ways to improve its performance, and those observations and measurements then serve as a feedback loop to go back into development to improve the software.  This process thus becomes the avenue to Continuous Integration & Continuous Development (CI/CD).

 

The monitoring function itself can be improved via Automated Testing that provides, among other things, regression testing to ensure that every new improvement that gets deployed doesn’t inadvertently break something that was already in place.

 

Therefore, in reality, true software development productivity is best understood as a tightly integrated function of both velocity and quality.

 

In many ways, the true production velocity and high quality are a reflection of the traditional CMMI model.

 

 

A software development organization that is laboring down at Level 1 – Initial (or Ad Hoc) tends to build things slowly, with lots of bugs that have to subsequently be discovered (usually by users) and fixed.  Conversely, a very mature software development organization at Level 5 – Optimizing, that builds things right the first time, rapidly, with few bugs, and is in a constant state of continuous improvement, gets high-quality software deployed much faster to satisfy the needs and goals of the business.

 

It is this continuum in maturity of software development organizations that has put a fresh spotlight and increase in the use of software development outsourcing services.  Why settle for an immature organization in-house when you can buy a fully mature development team for a lot less money than doing it yourself, and end up with much better results in less time?

 

This reality begs therefore the question of: What is a business’s organizational strategy for developing its software?  Is it simply to be the source of jobs for programmers, regardless of how fast they can produce and despite low-quality deliverables?  Or is it to get the code built that the business sells as its product/service and/or is part of its information infrastructure upon which the business depends to operate?  If the business strategy is the latter, then why not embrace high-velocity, high-quality, mature development services from a high-quality provider? Oh, and save money in the process!