7 min read
In the early days of computing, creating software was a physical act, more akin to factory work than the streamlined digital process we know today. Programmers meticulously transcribed logic onto coding sheets, distinguishing zeros from ‘Os’ and ones from ‘Is’. These cryptic symbols formed the instructions that would be punched into thick card stock decks. It was a laborious process that resembled typing pools, but it offered an important quality checkpoint – the ability to visually review the punched holes against the coding sheets, validating the integrity of the programs before they ran. It was vital that punched cards stay in order, and one early technique was to use a marker to stripe the cards. This was a standard technique that helped with visual cues of hands-on table-top process.
The diagonal line will help put punchcards back in order if they get dropped or shuffled during shipping or handling.
Grace Hopper: Making Machines More Human
Fast forward to the 1940s, and we meet Grace Hopper, a pioneering computer scientist and naval officer. Hopper worked on the Harvard Mark I, one of the first electromechanical computers. The Mark I was a behemoth, weighing nearly 5 tons and consisting of 750,000 parts. It used a paper tape mechanism, similar to punched cards, to input instructions.
Hopper’s work with the Mark I led her to a crucial realization: for computers to be truly useful, they needed to be more accessible to humans. She envisioned a future where people could interact with machines using languages closer to English than the inscrutable machine code of zeros and ones.
This vision led Hopper to develop the first compiler, a program that translates human-readable code into machine language. She also played a key role in the development of COBOL (Common Business-Oriented Language), one of the first high-level programming languages. COBOL brought computing out of the realm of scientists and mathematicians and into the business world.
The Digital Disconnect
As programming environments modernized, compliance processes remained rooted in their punched origins. Regulators that developed safety policies in factory, construction build codes and engineering specifications were now focused on IT and cybersecurity starting in the 1990’s. Firewalls first introduced in 1993, literally borrowed a name from building code requirements in skyscrapers.
Thus, compliance auditors clung to physical, artifact-based approaches, with screenshots becoming a digitized proxy for punched card code sheets. While time-stamped screenshots held legal admissibility, this methodology struggled to integrate with cloud computing and the accelerating DevOps cadences and CI/CD workflows in the 2010’s. Despite these disconnects, the legacy of punched cards continued to influence programming practices for decades.
The Enduring Legacy of Punched Cards
Despite the advances in computing that Hopper helped pioneer, punched cards remained a staple of programming well into the 1970s. Many early programmers have fond memories of carrying around stacks of cards, each one representing a line of code. Why would it continue in an era that had keyboards? Well, up until the invention of the cursor, the keystrokes would have to be exact, and painstaking effort to ensure every keystroke was correct. Cards, though from a bygone era, were still easier for QA purposes, as cutting and printing a new card was comparatively less effort for quick changes. But a single misplaced card could bring an entire program crashing down. So programmers had to think carefully about their code, as mistakes were costly and time-consuming to correct.
With hardware rapidly accelerating per Moore’s Law, software development and languages began to multiply to keep up. However, Conway’s law governed compliance and, as a result, the status quo of manual processes, siloed departments, and a lack of automation led to friction and inefficiency. Compliance became a bottleneck, slowing down the pace of innovation.
This tension is vividly portrayed in Gene Kim’s novel The Phoenix Project. The story revolves around an IT manager’s struggle to save a critical project amid organizational chaos. The conflict between the development team, focused on rapid iteration and continuous improvement, and the compliance team, concerned with stability and risk management, threatens to tear the company apart.
This fictional narrative reflects a very real challenge in modern organizations. Governance, Risk, and Compliance (GRC) teams often find themselves at odds with the agile methodologies of DevOps. Instead of working collaboratively with engineers to construct rules, they’re forced into the role of regulators, pushing policies from on high. This top-down approach creates silos, breeds resentment, and ultimately hinders the organization’s ability to deliver value.
The Current Crisis
The focus on tick-the-box exercises and zip-files of screenshots widen the cracks of the Punched Card Paradigm.
Carl Nygard, a Technical Principal at Thoughtworks with over 20 years of experience leading work across start-ups and large enterprises, warns in his article “Compliance in a DevOps Culture” on Martin Fowler’s blog.
“The unfortunate reality is that our experience shows manual compliance processes to be a form of ‘security theater’ resulting in delayed delivery of value without any material increase in the safety and security of the system.”
Even worse, as Troy Fine explained in an interview with Drata, there is no guidance for auditor on how to use continuous monitoring platforms. Therefore some auditors may only request exactly what will satisfy the SDLC audit, no more, no less, because they can’t “unsee” issues that might result in delay of certification. This leads to blinders focused on the certification and lack of investment in continuous compliance to manage risk at the speed of Devops.
Coupled with the pressure to “build fast” and “automate everything” at the expense of “breaking things,” is when quality, accuracy, and controls take a hit. Just as a misplaced punched card could bring an entire program crashing down, skipping critical compliance and security steps in the SDLC process can lead to catastrophic failures.
In 2017, Equifax suffered a data breach that exposed the personal information of 147 million people. The company faced $575 million in fines and settlement costs, not to mention the immeasurable damage to its reputation. This breach, like many others, was caused in part by a failure to patch a known vulnerability in Apache – a failure of the compliance feedback loop. The evolving cyber threat landscape and the increasing complexity of regulations have made compliance a business-critical priority.
image from r/cybersecurity
From Punched Cards to Co-Pilot AI: The Shift Continues
Today, we’ve come a long way from the days of punchcards. Modern programming languages and integrated development environments (IDEs) have made coding faster and more intuitive than ever. And now, with the rise of AI-based programming assistants like GitHub Copilot and OpenAI’s Codex, we’re on the cusp of another major shift.
These AI tools can generate code based on natural language instructions, promising to make programming even more accessible. It’s a vision that echoes Hopper’s dream of computers that can understand and respond to human language.
Yet, as we move into this new era, it’s worth remembering the lessons of the punchcard paradigm. The physical constraints of punchcards encouraged careful planning and attention to detail. As we increasingly rely on AI to write our code, we must not lose sight of the importance of human oversight and critical thinking.
The Next Paradigm: Compliance at the Speed of DevOps
Organizations now face a choice: continue with the punchcard paradigms of the past, or evolve their compliance models for the digital age. Recreating the physical review checkpoints of punchcards requires automating compliance into seamless digital equivalents: binary provenance and attestations.
This is where solutions like Kosli come in, providing an automated system of record thattracks changes, records attestations, then provides real-time visibility into the compliance state of your software and a historical record. It’s a modern solution to an age-old problem, bringing the discipline of the punchcard era into the age of DevOps and continuous delivery with a modern secure SDLC.
As we’ll explore in the next article, this new paradigm of Compliance at Speed of DevOps is not just about tooling, but about a fundamental shift in how we think about compliance. It’s about integrating compliance into the very fabric of our software development processes, making it a seamless part of how we build and deliver software. It’s the key to thriving in a world where the pace of change is only accelerating, and where the cost of non-compliance is higher than ever.
The SDEM Collection
Part 1. The punchcard paradigm: Tracing the roots of modern compliance
Part 2. The high stakes of SDLC compliance: Lessons from EVE Online’s battle of B-R5RB and Equifax
Part 3. From lean manufacturing to DevOps: The software factory revolution
Part 4. Just the facts" 🔏 🗒️ Introducing Software Delivery Evidence Management (SDEM)
