Premature Standardization

Yet another in the family of the prematures.

Many would argue that standardization is always a bad thing, so in that sense all standardization would be premature. But as systems get large and chaos becomes apparent, there is usually a rational approach to standardizing. The amount to standardize and the time to standardize are both important factors.

PrematureStandardization is closely related to PrematureGeneralization, because standards, to be applied, have to be somewhat general. If it's too soon to generalize, it's definitely too soon to standardize, owing to this relationship between the two. Many managers (especially the junior ones) have a tendency to want to standardize as soon as they see a pattern. Sometimes managers attempt to build a development organization on pre-conceived standards.

There repercussions at the human level from PrematureStandardization. Attempting to standardize in areas where people are attempting to invent will impact the invention process.

PrematureStandardization is also related to PrematureOptimization, and in fact this is probably the prime reason why managers leap to it so readily. Rather than being perceived as allowing multiple redundant technologies to run in parallel, wasting time and resources, the over-eager manager will attempt to standardize at the earliest possibility, wishing to earn the title of "efficient".

Another possible reason why managers standardize prematurely is that standardizing is the only real skill they possess. This is especially true of programmers promoted to managers without sufficient people experience. A good programmer refactors instinctively, and it's a short jump from refactoring code to refactoring the workforce and everything else that moves.

--WaldenMathews (with apologies for explaining the obvious yet again)

The standards are made for interoperability. Is there such a thing as a PrematureInteroperability??

Some standards are for interoperability, but not all. I can't think of an example of premature interoperability, at least not an interesting one. But just because X can't be premature doesn't mean the standard intended to enable X can't. Isn't it premature to standardize for interoperability when you don't yet know what things are going to interoperate and what's essential for that dialog?

What is meant by "standardization" in this context? I usually try to take a standard approach initially and vary only when forced to. I would probably argue that starting out with a custom approach is premature uniqueness. --WayneMack

In this context, by "standardization" I mean the invention of standards to control lower level constructs. For example, the invention of a coding standard in a small department that hasn't written any code yet, is often found premature. Adopting an already mature standard is less of a risk, and for obvious reasons, but not without risk, also for obvious reasons.

Is the problem standardization or a combination of lack of flexibility and lack of knowledge when creating the standard? --

The most flexible standard is no standard. Put another way, the purpose of standards is to introduce some beneficial inflexibility. If a standard is too inflexible, it could be because it was formulated before there was enough knowledge of the diversity over which it would be applied. So yes, lack of knowledge is the hallmark of prematurity in these matters.

Couldn't the opposite argument, that standardization is most effective when introduced at a very early stage be advanced quite successfully? Using your example of coding standards, if the standard is defined prior to any code being written, all developers begin with a clean slate. This reduces conflict that can arise when the defined standard is released later on, and looks very similar to one developers style rather than another. Introducing the standard early also insures (in as much as a standard can) that all code created will conform to the specifications, rather than having some portion of pre-standard code in existence that may be completely unlike anything in use after the standard is created. Code is a tangible construct. Because of this, things along the lines of coding standards seem to be less prone to problems caused by premature standardization. Another thought is that any field/area/topic that has had sufficient time to develop can successfully have standards dropped into a new effort, as they have been able to define a set of best practices. Standards may be premature in an area or endeavor where there is no prior work (since all such standards must be either highly arbitrary or based upon expected similarity to another field), but I don't see why somthing along the lines of a coding standard for a new development group would be premature. --SeanMcNamara

It seems there are two things that can be premature in this picture. One is the standard itself. If it hasn't stood the tests of time and experience, it's not mature, making it premature. The other is the readiness of a group to yield to a standard, any standard. An otherwise appropriate standard may not fit with a group not ready to settle down with a particular standard. It goes to your exploration paradigm, Sean. So, either of these phenomena could result in a premature standardization effort, and of course they could also occur simultaneously (if you're lucky). -- WaldenMathews

I think my concern stems from a belief that both issues (immature group, immature standard) can only be fixed by attempts at standardization. Developers might be uncomfortable working with a standard the first few times one is foisted upon them, but after using it for a while, it should become second nature. The same is true with the standard itself. Only by attempting to use the standard will it's weaknesses become apparent, which leads to a refactoring of the standard, which eventually leads to a robust and usable standard. Without attempting to standardize, there is no progress made by either the developers or the standard itself. I agree that early adoption is often painful, but someone has to do it. --SeanMcNamara

See http://java.sun.com/people/jag/StandardsPhases/index.html --GlennVanderburg

Note: This paper (while excellent) seems to confine itself to hard standards, those that cannot be modified after their creation (which is not surprising given the background and situation of the author,) whereas the items described in the inital comments of this page might be more accurately considered soft standards that can be modified throughout their lifetime. A core feature of XP is it's willingness to incorporate feedback from prior iterations back into the standards and processes to be used on the next iteration/project.

You might like to start a forum for the discussion of soft standards and see if that concept stands on its own, or whether it's just another name for evolutionary development and exploration. As far as I know, the idea behind standards is to eliminate variability (no, not all of it, of course), and so in that sense Standard=Hard, and what's not hard exists outside the standard.

A standard is simply a well defined solution to a general class of problems. A standard will rarely be a perfect solution to any specific problem, but most likely it will address many of the less obvious issues that are overlooked when rolling your own solution. Basically, if the standard fits, wear it.

A long time ago, in a far away place, during the first-generation (X10) X windows standards process, Larry Tesler offered an analysis that has always seemed helpful to me.

Larry observed that there are two kinds of standards.

The first attempts to codify "accepted practice", so that it doesn't need to be constantly reinvented and so that various teams can learn from each other's experience. Some great examples of these are electrical (UL) standards that govern things like receptacles and switches, screw threads, and plumbing fixtures.

The second are attempts to create new markets by inviting multiple participants to cooperate in launching new technologies. Some great examples of these are the CD audio standard, XWindows, and Java.

Finally, Larry observed that standards, especially interface standards, exist in order to allow the resulting components to be interchangeable. That requirement often forces a degree of operational rigor that drives a particular standard towards acceptance or early obsolescence. For example, many have argued that the widespread adoption of CORBA/OMG has been slowed because that community made the standards process so arduous, and the interchangeability so tenuous, that by the time it worked nobody cared.

Viewed from within this framework, PrematureStandardization is a problem for standards of the first category. Early standardization is an absolute requirement for the second. Perhaps this distinction helps clarify why so many successful arguments can be made for each side of this discussion.

TomStambaugh

I see this distinction among types of standardization as being a distinction among motives for standardizing, but when I look closer at the essential act of standardizing them, I see more similarity than difference. Standards are always about interfaces of some kind, although your scope will influence how you see this. If we have a standard development process, then it is perhaps invisible to the outside world, but it is only standard to us if it involves visible interfaces between us and it. Otherwise, there's no way to observe whether we are following the standard or not, and if that's the case, then there is no standard. Maybe this is why I see UL plugs as being an example of standardized interface, not standardized practice.

Do standards really create new markets, or do they sculpt emerging markets? I think to answer that, you also have to ask what the "early" part of "early standardization" really means. To me, "early" (to the point of premature) means relative to experience. When a standard like CORBA is unleashed on the public, it's fairly late with respect to experience, although perhaps early compared to other standards. As for creating markets, I don't believe you can create one just by putting a standard out there, so I go with the "sculpting of emergence" theory.

I think your insight about the pushing of early standards precipitating fate is in line with my original point: at what point are you ready to commit to either sink or swim but nothing in between? Personally, I want to be a strong swimmer before I go there. To put it more cleverly, is it more important to swim, or to crawl? -- WaldenMathews

Here's the kind of thing I was originally thinking about. The manager of a group decides that the group should start developing their applications as web applications. One or two products are developed. On one of these, a developer uses a sophisticated tool and puts a lot of time into making a professional looking set of pages. The tool relies heavily on style sheets. The results are pretty good. The group still has almost no experience with Web design or styles. At this point, the manager decides to standardize on this particular look and feel, this particular tool, even these particular colors. Is this the right time to standardize such things? I thought not. -- WaldenMathews

Why Not? You said the results were pretty good and did not list any problems. With all your hypothetical team needs to do and learn, why not just proceed using the recommended tool and colors? If the approach leads to difficulties in the future, you can address them then, but currently it does not sound like the team has yet aquired enough information to justify an alternate approach. --WayneMack

The team was born with an alternative approach, a whole bunch of them in fact, to the tune of about one per member. The main thing is that the team is about the business of acquiring information, and standardization impedes that process. -- WaldenMathews

If the team had a multitude of different approaches, I would say the manager made a very good call. He picked one that seemed to work. Until information arises indicating short falls of that approach, go ahead and use it. If that information comes up and the manager refuses to re-evaluate the decision, then I would have a problem. If you have multiple alternative solutions, pick one (at random if need be) and get some relevant experience in it. Don't keep switch based on developer's whims. --WayneMack

But Wayne, standardizing kills the dynamic that causes such information to arise. Then somebody says "well, there don't seem to be any short falls, so I guess we were right." In terms of ExpandToContract, the expansion part was crippled. --Walden

First, let me express my frustration at following a debate between two people with the same initials. If I misattribute somebody's position, feel free to correct it in place.

Walden said: At this point, the manager decides to standardize on this particular look and feel, this particular tool, even these particular colors. Is this the right time to standardize such things? I thought not.

Is the manager setting these as a standard -- you must use these -- or as a default -- in the absence of a decent reason to do otherwise, use these? I can see some good arguments for making them the default, but given the team's level of experience, I agree that making them a standard is premature.

Also quoth Walden: As for creating markets, I don't believe you can create one just by putting a standard out there, so I go with the "sculpting of emergence" theory.

I'm not sure I agree with this: didn't TimBernersLee just "put a standard out there" (HTML-over-HTTP)? And didn't that create a very, very big market? Maybe I'm misunderstanding what you're saying, but sometimes you can standardize early. It seems to work better for isolated geniuses than for huge standards bodies, though. --GeorgePaci

George, nice distinction between between forcing and providing defaults. In the scene I described, it was a matter of forcing, which is another way of saying limiting possibilities. With respect to HTML and HTTP, had there been no need to communicate, would their appearance have created that need? I split hairs here and say that the market existed and these standards sculpted its emergence but didn't create it. More importantly (to me), you and I can communicate over the Internet without using HTML or HTTP if we so choose. -- WaldenMathews

Indeed, for a brief period of time Gopher was bigger than HTML/HTTP, at least in the U.S. And the fact that Mosiac supported multiple standards (HTTP, FTP, e-mail, Gopher, Telnet, TN3270, WAIS) was an important factor in its success (and the resulting explosive growth of HTTP into today's default method of Internet publishing). -- JeFritz

The problem is that you can not be flexible in everything and create anything. HTML, HTTP, FTP TFTP, Telnet, etc. are possible because of the use of TCP/IP as a standard. TCP/IP is far from the ideal standard (witness the security problems arising from it), but adoption of it, as opposed to constant re-evaluation of alternatives, have lead to progress, advancement, and creativity. I believe this is directly analogous to the manager locking down the selection of development tools to allow his development to spend time creating useful results as opposed to reviewing alternatives. --WayneMack

Yes, but. You see, this page examines the timing of the introduction of standards, not the concept of standards itself. We are agreed that standards allow economy of communication and all the good things that go along. The question is, when in the lifecycle of something is it the right time to standardize?. TCP/IP is a de facto standard (which may deserve another discussion in its own) that underwent a development during which some changes were made. It became standardized through usage, which means somewhere "out there" in the lifecycle. No so with the imposed development tools and presentation styles I referred to.

(Note that even though tool selection has been "locked down", the more capable members of the group continue to explore alternatives on their own time. What does that tell you?)

-- WaldenMathews

Shouldn't YesBut? be a WikiWord?