Last time we talked about a few things that go wrong in the IETF — this time we’ll talk about a few more things that can go wrong.
Boiling the Ocean. Engineers, as a rule, like to solve problems. The problem is we often seem to think the bigger the problem, the better the solution. So what do we do? We boil the ocean (or peanuts, as the case might be). This is particularly bad in the IETF for various reasons.
First, as working in the IETF becomes ever more professional, and as many companies attempt to justify the money the spend on IETF work, the number of drafts you author becomes a primary determinant of participant value. Right or wrong, this is just a reality IETF’ers deal with. When a new idea or direction of work comes along, it’s really easy to jump in with a lot of new requirements or drafts or ideas that are really recycled from the last five problems, but with new names on them. It’s easy to build an impressive body of work quickly in the IETF. But the real work gets done when no-one cares about who gets the credit.
Second, vendors are coming to the IETF with what might be considered fairly complete solutions. There are a number of reasons for this — for instance, the more complete the system is, the more likely you are to get it through “as is,” and therefore maintain some sort of competitive advantage. Complete solutions tend to engender a lot of thought around corner cases, which means a lot of complexity, which means — boiling the ocean. Rather than building simple protocols that solve a point problem, there’s a natural drive to try and solve every problem in the space.
The result is often a huge set of spec’s that are a “flood” (see last week’s post), or become so entangled they are difficult to read and understand, slowing the entire process down.
Ad Hominems and Other Wiley Beasts. A second point about engineers, in general, is that they aren’t very good with people, or (honestly) with logic in the larger sense. Engineers, particularly engineers who deal a lot with software development and protocol specification, tend to end up seeing logic as boolean logic, rather than logic in a larger sense. I’m constantly astounded at the level of straw man, ad hominem, and other sorts of logical fallacies and attacks. In the theological world, such attacks would often immediately stop the flow of conversation as the logical fallacy is backed out. In the IETF, such attacks are often considered solid arguments meant to end the conversation.
Overall, the IETF is much more like the “wild west” than the “wild west” probably ever was — minus the derringers and dancing, of course. It’s a rough a tumble world, not for the faint of heart.
Next time we’ll talk about why the process is slow even when everything goes right.