Why do simple things take so long?
“I was in Boston recently and visited Old Ironsides at its berth, coincidentally at a time when the ship was being painted. I chatted with one of the supervisors and asked him about the length of the government specifications for this particular job. He said it numbered two hundred pages and laughed in embarrassment when I told him to take a look at the glass display case showing the original specification to build the ship in 1776, which was all of three pages.” - Ben Rich, from Skunk Works: A Personal Memoir of My Years at Lockheed
Why does it take a 200 page specification a re-paint ship which was built from a 3 page specification? How many kinds of paint were there 1776? How many colours were available? Presumably, when the ship was built, most of the requirements were implicit, just understood and assumed by the builder.
This is partially addressed by one of the principles of the Agile Manifesto http://agilemanifesto.org/: emphasize working software over comprehensive documentation. This can be achieved by having small, self-organizing teams, that understand the domain well enough, they can identify the next task and have what they need to take action. They know the ship has to be painted, they know what paint is required, and know how and when to apply it.
This can be hard to scale. Our development team knows our web stack, and our business domain, really well. We have great turnaround times on turning ideas into functional code delivered to production. But if we need something beyond code - let’s say, we’ve got to introduce a new brand, which requires a new domain - we’re not in a position to assess the interaction between our DDOS-protection vendor, network routing, load balancer, server setup, and have to engage external teams.
Similarly, I’ve encountered these issues when working on projects with Canada’s “Big Five” banks. I’ve seen projects held up for months by small things, such as making small changes to a file transfer - something that ultimately takes the right person a few minutes to implement - once the right person is found, allocated over competing priorities, and changes documented. What is operationally very efficient for the bank is less nimble for changes.
What has changed since the days of a 3 page warship specification? How do we efficiently use 30 minutes of SFTP administrator time a year, who has no context to a broader project? How do we get that 30 minutes allocated at the right time? When using niche skillsets across a project, how do we avoid a 200 page spec? Who has the skill to build a 200 page spec across diverse skill sets when we need something new? How long does that take?
Why do simple things take so long?