This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.
The term “true original” is used to describe someone who is a trailblazer -- and it describes my father to a T. My dad was an early architect of software estimation, the process of predicting the time, effort, and manpower it takes to complete a software development project.
Thirty-five years ago, my father was a budget director for the Army’s computer programs. He had the unfortunate experience of having his funding significantly reduced when his IT team failed to properly articulate its software development goals in ways that were relatable to leaders. As a superior put it, “Whenever I talk to the IT guys, I hear about bits and bytes, programming languages, and bandwidth, but nothing that relates to time, effort, and cost.”
That comment sent my dad on a mission to develop a software estimation frameworkthat addressed the three points that his boss was most concerned about. He sought to expose what he called “a fundamental law of nature in our software production equation.”
The More Things Change…
Back then the process was known as “systems analysis” or “industrial engineering,” but it has since become known as “predictive analysis.” In the ‘70’s, as is the case now, the goal was to determine, as accurately as possible, how much staff would be needed to complete a project, the project’s cost, cumulative hours of effort needed for completion, and more. This was the beginning of using processes like the Putnam-Nordem-Rayleigh function (or PNR curve) – a software estimation model discovered by my dad - to estimate staffing and delivery needs, along with software production equations that were used to evaluate productivity, time, effort, and project size.
These core fundamentals continue to serve as foundational elements of software estimation, even as software development processes have changed significantly. Waterfall development methodologies, once the gold standard, have lost favor to more flexible incremental lean and agile methods. Comparing the development languages of 35 years ago to those of today is like contrasting 18th century speech patterns with modern colloquialisms. Risk management and the need to address cyber vulnerabilities have become major considerations. And the platforms themselves have evolved from centralized time-sharing, to desktops, to servers, and now to the cloud.
The nature of code construction itself has also changed. Code construction has gotten much more incremental over time. Most developers are no longer creating large chunks of code; rather, they’re configuring packages and using more powerful languages than ever before.
…The More They Stay the Same
However, developers are still writing code, and that’s why the estimation process developed by my father 35 years ago applies today. Regardless of whether a team is using agile methodologies or some other variation of modern development, if they’re writing code it’s imperative they adhere to the same estimation standards that were first developed 35 years ago. In fact, I would argue that having these standards in place is even more important today, as agile teams attempt to balance what they do best with the need to address businesses’ expectations.
Despite a software development landscape that is obviously far different than the one my dad initially experienced, the fundamentals behind software estimation, and the ways that teams approach development, remain virtually the same. We still ask two core questions – What’s the goal? How can we solve the problem? Then, we develop the solution. My father called this the “what-how-do cleanup cycle,” and it’s still very relevant today; even as methodologies and platforms change, the basic discovery process and work remains constant.
You can learn more about the past 35 years of software estimation in QSM’s complimentary 2016 Software Almanac. It contains some great information about core metrics, management styles, best practices, and more, and really digs deep into how to develop a successful estimation process for your own business. It’s an invaluable resource for a world that’s more heavily dependent on software than ever before.
It’ll also give you the unique historical perspective of my father, whose invaluable input into software estimation has helped hundreds of companies over the past several decades become more efficient and effective at developing solutions. I’m proud to be following in my father’s footsteps, carrying on the legacy he established during his time in the Army. And I’m excited about the next 35 years of software development. Who knows what they will bring?