“Failure to plan is planning to fail.” If that is true – and it has been quoted verbatim or slightly modified so many times throughout modern history, there has to be some truth – why does most of the engineering community seem to detest planning so much?

Engineering planning doesn’t mean whipping out a block diagram or pseudo code, then off to the implementation races – that worked in the old embedded days, and may still work in Makerville, with relatively small projects and few interfacing requirements. For bigger, sometimes safety-critical projects and the system-of-systems with major interoperability at stake, planning is essential, with development of well thought-out requirements. In some cases, requirements grow into complete specifications, becoming formally standardized for broader industry use.

There are four reasons engineering, especially the open source community, wants to blow up the planning process as we know it.

It’s slow. A recent post on GigaOM by Vidya Narayanan titled “Why I quit writing Internet standards” is indicative of the problem: the pace of standards organizations is nowhere near keeping up with the pace of innovation, especially in fast moving segments like the IoT. Real-world complications like patent disclosures, legal wrangling, and regulatory compliance can slow things down even more.

It’s painful. I admit, I’ve dozed off in more than one standards meeting, which are often like soap operas. You can skip a meeting and miss essentially nothing in many cases, or at least read through the meeting minutes and find the important stuff in minutes instead of days. People familiar with formal standardization bodies understand Robert’s Rules of Order, but in many cases the politics, process, and semantics vastly outweigh work being done on the actual specification. Does this sound at all familiar?

@L2myowndevices but then how will I get to spend a year on calls discussing "should|shall|must"?

— Joe Speed (@JoeSpeeds) April 13, 2014

It’s difficult. Requirements writing is an art, specifying something implementable and verifiable, without ambiguity. I recall one marketing-engineering meeting where my engineering manager, a guy I respect greatly who in this case was trying to help, looked at a feature request and comprehending the difficulty in verification said: “You didn’t say it has to work.” (One reason to opt for a formalized standard: somewhere, someone has a way to verify interoperability.) His point was well taken, and we set off to understand the testing problem.

It’s unrewarding. Said nobody, ever: “Wow, there’s the guy that wrote IEEE 12345-2014! Let’s get a selfie with him!” To the victor go the spoils, and by most measuring sticks victory means shipping product to the market, not creating a PDF with a lot of details most people will never see. A select underappreciated few make a career out of standards, partly because they understand systems engineering concepts and the politics of their forum, and partly because few others aspire to and can endure the endless mind-numbing minutia interrupted by moments of progress.

I get it, but as I indicated in my Tweet sharing the Narayanan post, I think we are seeing signs of too much disruption when it comes to designing systems-of-systems, where everything connects to everything. I don’t want to suggest all is doomed by skipping or minimizing planning, or that open source is the problem; plenty of open source projects are producing well-formed results, without a lot of overhead.

I don’t like agenda-driven politics and change at the speed of molasses in January, either. The fact that the current standards process is flawed and requirements are often difficult doesn’t mean we can afford to avoid them. Too many attempts at disruption in the name of time-to-market can have dire consequences for organizations down the road – the disruptors may become the disruptees, when the systems standards materialize and effectively invalidate off-the-map specification-by-implementation. They say you can spot pioneers easily, because they are the ones with arrows in their backs.

In an Aldec Q&A with Randall Fulton, an FAA consultant Designated Engineering Representative (DER) who instructs an upcoming DO-254 Practitioners Course, he lays out some of the risks associated with planning or lack thereof in a DO-254 context. Admittedly, working in avionics, medical, and other high-certification environments forces the issue by mandating artifacts to demonstrate compliance. I think his advice applies more broadly, to any effort where blocks of IP are strung together into a system, be it a chip or an airframe:

Allow adequate time for planning and creating [specifications]. Take a requirements writing class. Write requirements before finishing the design.

If it were easy, anyone could do it. We could have days of discussion on requirements writing, standards bodies, IP interoperability, and open source culture, and what needs to change if we are to avoid a complete mess as complexity and connectedness continue to increase. What are your thoughts, and can you cite an example where requirements/standards helped or hindered a development effort?

lang: en_US