Kingdom of Code: The Old Gods and the New

(Originally posted at: https://medium.com/@dhkirk/kingdom-of-code-the-gods-of-the-old-and-the-new-part-1-of-2-f902bf32910d and used with permission.)

This is inevitably going to get tagged as TL:DR. If you are thus inclined, skip to the last section now. For originality, it’s called LAST SECTION

I wrote my first program over fifty years ago — for the historians out there, a few lines of Fortran that ran on a PDP-8. Today, I’m writing an app in Swift.

For his tenth birthday, I got my son a Sinclair ZX80 home computer and taught him Basic. He created some amazing stuff — we hacked together.

I am more Old Gods, he is the New. Fast forward.

Over that half century, I’ve been involved with every aspect of software; development, test, support, product management, operations, marketing, sales, and general management — and I had at least one major screwup in each! The biggest — and funnest — job was SVP of the IOS Technology Division at Cisco — IOS was Cisco’s core operating system, running in 80% of the Internet’s routers and switches, before they licensed the name to Apple for their core operating system. But I’ve also learned incredible lessons from job’s at IBM — in the glory days of mainframes, and at America Online — at the dawn of consumer Internet — in fact there, I had everything I’d hung onto challenged and reinvented.

So here I am, carrying water for my wife who is studying to become a veterinarian — which is x100 harder that any startup — covered in cats, and bantering about the history and mystery of software with my son — product development manager with twenty years before the mast — when we are not bantering about Pink Floyd or rugby.

And in our reflection upon the state of software programming and production today I am compelled — hell obliged– to say something, from the vantage point of having actually lived through most of the history — sometimes painfully, sometimes very painfully.

I’d start with a fundamental belief that software and software development is intrinsicallythe same today as it was in the 60’s … only the names have changed. Even the job titles have changed: computer programmer, coder, software developer, software engineer.

I’ve programmed (much prefer programmed than coded) in IBM assembler language (BAL), and in Swift — and many languages between — and, arguably or with tongue firmly in check, the skills are essentially the same; problem definition and statement, finite state management, creative thinking, and pattern recognition. Yes, of course, any programmer needs to have a language with which to speak to the computer or complier or interpreter, but just as there are equally brilliant physicists that speak English or Spanish, so a great Cobol programmer is as equal as a C++ programmer.

And a great programmer is?

A crafts(wo)man — in the renaissance sense of the word — who creates a required user experience (no, no, no — so much more than merely UI/UE) within a determined time and cost. One of the good lessons of our history is that we have rejected the idea of applying a metric of performance on programmers. Way, way back, we talked about KLOC/day (K=1,000’s Lines of Code), and we argued whether or not the metric should include comments. But then we saw lots of uncommented code that no-one could maintain. Ah, the law of unintended consequences.

Later we had Function Points (FP) — an attempt to quantify the complexity of a program in consistent units as a proxy for effort. Much more holistic, but equally flawed and subject to the same laws of unintended consequences. But, even knowing that we will never get to a definition of programmer productivity, every good manager knows — empirically — that a really good programmer is several orders of magnitude more productive that a mediocre one, right?

I still hate the title; software engineer. But did you ever wonder why our industry tried to reduce a uniquely creative discipline to one of highly, deterministic physics?

Glad you asked.

In the late 70’s and early 80’s as computers scaled down in physical size and price (to mini-computers, but not quite to the server and personal level yet) the software industry exploded (figuratively and literally). The rush to create enterprise and mission critical applications eclipsed the California gold rush. But with great haste came great waste. Almost weekly, another major failure hit the headlines, like the US Air Traffic Controller system that was started in 1982 and was scrapped with an estimate $3B-$6B waste (inflation adjusted to 2019, that’s $25B-$50B). And major software failures started to plague US military projects. Executives where demanding accountability (heads didroll, but that seemed to become a badge of honor) and executive attention to the software development process — in an attempt to restore faith in software development in much the same way as Deming restored quality to the Japanese auto industry in the 50’s.

And the US Air Force funded a project with the Software Engineering Institute (SEI) that eventually spawned the (in)famous Computer Capabilities Maturity (CMM) model and levels, that then started to measure the maturity of (software) organizations by the maturity of the software development/delivery processes. And yes, it really did induce migraines.

I vaguely recall a meeting in pre-Mumbai Bombay (this was almost 30 years ago so its paraphrased as best as I can) where an CMM-Level 5 outsourcing company presented something like:

Total FP’s in application = x (remember FP = Function Points)

To deliver system in n days, we need:

Required Software Engineers = FP/y
(where y=average weighted productivity rate)

Required Test Engineers = 20% of Software Engineers

Required Doc Writers = 10% of Software Engineers

Required Project Managers = 2 (1 onsite, 1 offsite)

Just claiming CMM-Level 5 certification and using Engineers in every job title, magically made the software project deterministic and the process engineering-grade.


Another half a generation later and, today, the software world changed again: Web, devops, mobile, etc. etc. etc. and now we have another, new vocabulary … Lean, Agile, MVP, scrum, backlog, standup, drill-down, hokey-pokey.

Just let’s be empathetically clear …


With small, multiple releases you can’t tell the difference between waterfall and iterative.
MVP sounds a lot like rapid prototyping without revenue expectations.

Agile is not the same as agility. Releasing crap can be done very fast.

BUT … the fundamentals of software haven’t really changed and there are some [tongue-in-cheek] laws that are impervious to change …

  1. It’s done when it’s done … plan around that.
  2. Fixing bugs in the field is x10 more expensive that in-house … beta is to test the deliveryprocess, not to trick early customers into doing your QA.
  3. The right time to ship a release is when the cost of not releasing it exceeds the cost of releasing.
  4. The biggest single flaw in every development process is letting the C-levels see the sausages as they are being made.
  5. You can only ever have any two of the following: cheap, fast, or good software.

Software delivery management — in a startup- happens in a conference room, sleeves rolled up, sweating the details together, with shared vision and mutual skin in the game.

Nothing — NOTHING — delivers better software than an empowered, motivated crafts(wo)man who is given the opportunity to take pride in their creation.

And if you’re a startup and this is your first rodeo, hang onto that steer as though your life depends on it … for it does, well at least your company!

But … that’s Old Gods stuff. The New Gods need to speak. That’s Part 2.

Startup Events at Raise Ventures

Contact Raise

We'd love you to join our community. If you want to get involved with Raise, let us know more about you below.