I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.
– John F Kennedy, May 25, 1961
The complexity for minimum component costs has increased at a rate of roughly a factor of two per year… by 1975, the number of components per integrated circuit for minimum cost will be 65,000.
- Gordon Moore, “Cramming More Components onto Integrated Circuits – Electronics Magazine, April 19, 1965
Countless industry studies over the past several decades have revealed a harsh truth about engineering: the vast majority of engineering projects miss their schedules. In fact, we are so accustomed to missing schedules that the slip has become an integral assumption within our industry and within the engineering community. Nobody blinks an eye when they hear that an engineering project is late. In fact, the question is no longer whether or not we were late, but by how much. Our profession has utterly and completely normalized the notion of missing schedules, and the entire technology sector has shrugged their cumulative shoulders and gone along with the game.
Chronic problems provide fertile grounds for memes, cliches, excuses, and truisms, and entire industries have built themselves on the assumption that engineers will forever be behind schedule. With the possible exception of weight loss, few issues have had more futile advice thrown at them. “You can’t schedule invention.” “Adding resources to a late project just makes it later.” “Nine women can’t make a baby in one month.” “Creeping enhancements cause schedule slips.” – We could populate pages and pages with tips, tricks, and quips, and yet the truth remains. It is apparently impossible to engineer to a schedule.
Or is it?
Interestingly, two of the most massive, famous, and impactful engineering projects in history nailed their schedules against seemingly impossible odds. JFK set a deadline for landing man on the moon, and engineers beat the schedule by almost six months. Gordon Moore set a schedule for improving transistor density in integrated circuits, and engineering tracked it for ten years, then tracked his next challenge for four more decades.
What do these two examples have (that 90% of the engineering schedules in the world are apparently missing) that allowed them to be completed on time? Did Kennedy and Moore build the all-time best PERT and Gantt charts? Were these projects waterfall? Agile? Did the world’s engineers come up with the most accurate and detailed task decompositions and breakdowns, pushing them up through levels of management hierarchy where they were assimilated and matched with marketing requirements, then disseminated for review and tracked with weekly stand-up meetings? Perhaps they benefited from open-office-concept work environments fused with telecommuting for geographically dispersed team members using state-of-the-art collaboration best-practices? Were there variable compensation schemes and lucrative management bonuses depending on MBOs and KPIs versus plan?
Ummm. Nope.
One thing that each of these projects had in copious quantities was vision. Vision is elusive. Vision is transcendent. Vision moves problem-solving into an elevated context. The moon landing was a task – a scheduled event. But the benefits and impact of that project extended far, far beyond the scope of putting a man on the moon. Landing on the moon accomplished almost nothing of value, but the successful execution of the moon landing project, and the technology and infrastructure developed enroute to that goal changed the world. Similarly, cramming more transistors onto a chunk of silicon is a relatively mundane, almost academic exercise. But the penumbra of that project – the utter enormity of the technology and life-changing advancements that have been sucked along in the wake of that task – is almost incomprehensible.
Both Kennedy and Moore were acutely aware of the potential impact of their vision. In “Cramming More Components…” Moore foresaw home computers, automotive telematics, electronic watches, cell phones, and the infrastructure of the internet – all in 1965:
Integrated circuits will lead to such wonders as home computers—or at least terminals connected to a central computer—automatic controls for automobiles, and personal portable communications equipment. The electronic wristwatch needs only a display to be feasible today.
But the biggest potential lies in the production of large systems. In telephone communications, integrated circuits in digital filters will separate channels on multiplex equipment. Integrated circuits will also switch telephone circuits and perform data processing.
Computers will be more powerful, and will be organized in completely different ways. For example, memories built of integrated electronics may be distributed throughout the machine instead of being concentrated in a central unit. In addition, the improved reliability made possible by integrated circuits will allow the construction of larger processing units. Machines similar to those in existence today will be built at lower costs and with faster turnaround.
But Moore didn’t ask engineering to create all of those “wonders.” He simply told us to cram more components onto integrated circuits. The rest, he must have reasoned, would take care of itself.
It would be fair to argue that neither Kennedy nor Moore created an actual engineering “schedule.” They proposed a goal and a timeline or, in the case of Moore, more of a prediction. Moore’s prediction was not based on analyzing the engineering work to be done; it was a simple extrapolation of historical trends combined with a key bit of insight – that those trends would be likely to continue for a long time due to an apparent lack of obstacles. Kennedy’s moon shot was nothing of the sort. His was clearly a goal with a target date – again, with zero analysis of the engineering work to be done.
Perhaps the problem with engineering schedules is that we try to engineer them.
I managed large software development teams for a couple of decades, and one thing I learned clearly was that engineers have a certain logarithmic sense of time when it comes to estimating individual tasks. I noticed that when I asked an engineer “How long will XYZ take?” I would most often get one of two answers: “a couple of hours” or “three or four weeks.” I began to see that the “couple of hours” case meant that the engineer already had a few lines of code in mind, there was no ambiguity to the task, and I was getting an estimate for the normal time it took to do an empty engineering change – find the correct file, drop in the code, build, test, document, check-in.
The more interesting case was the standard “three or four weeks” estimate. That, I came to learn, meant there was ambiguity. The engineer did not have an immediate solution in mind, and experimentation would be required. When I followed up on these tasks, I further noticed a common sequence of events. First, after only a day or two, I’d get the, “This is going much faster than I thought” update. Often, there would be a demonstration that showed the new feature kinda-sorta-working, with a disclaimer that there was still plenty of work to be completed behind the scenes. If I checked in again in a week or so, things would still be “coming along nicely,” and I’d be told that we were “probably 80-90% done.” Ah, we were still “ahead of schedule.”
At the end of the “three or four weeks,” though, things would have taken a sinister turn. I was generally now told that we were “basically done, except for a few last issues to clean up.” I knew what this meant. We had just entered a stable state for schedule slippage, where we would remain at the “95% complete” mark for a period of time that could be anything from one day to six months. This was not engineering malpractice. This was the harsh reality that most engineers are simply incapable of creating reasonable estimates for engineering tasks they have not yet attempted. Interestingly, I found that there was no feedback loop, either. At the end of the project, when a “three or four week” task had taken three or four months instead, I began closing the loop – asking how long particular tasks had taken. Consistently, I’d get back the original estimate – “seems like it took three or four weeks.”
Perhaps moon landings and Moore’s Law did not have a magic ingredient that my schedules were missing. Maybe it was the other way around. Perhaps there is a convergence, where the true visionary can intuit the size of a huge task more accurately than we can deduce it through exhaustive analysis and decomposition, and perhaps the engineering spirit of problem solving and inspiration can meet that halfway. If a deadline is simply another key requirement, missing the schedule is a first-order failure to solve the problem. If a team of talented engineers is challenged and inspired to solve a problem, something transcendent often happens.
If JFK had not made his speech, or if Moore had not written his article, would we have had moon landings and a silicon-driven technology revolution anyway? Or was that original vision a key catalyst that partnered with the engineering spirit to manifest something from nothing? Of course, we will never know the answer.
Leave a Reply
You must be logged in to post a comment.