Soviet Shoe Factory Principle

The factors that are easiest to measure or most visible are the ones that get the most attention, regardless of their importance in comparison to other factors. Another way of saying this is that factors that are easiest to measure or model are not necessarily the most important ones and/or a complete picture, but human nature often forgets this.

In Soviet Russia there is a story of a shoe factory that was pressured to increase production, as measured by quantity of shoes produced. However, the factory was a bit short on materials. So to increase production, the factory decided to produce more children's shoes, which require less material. Eventually there was a severe shortage of adult shoes, especially larger sizes. However, the factory was meeting its production goals on paper.

We can also imagine that if size quotas were given, there'd be lots of ways to skimp on quality. For example, less threads could be used. If the authorities start counting threads, then old thread can be used. If they find a way to measure the age of the thread (however unlikely), then use cheap leather, cheap glue, cheap paint, etc.

Examples found in software:

Nice aesthetics even though underlying quality is suspect. This is particularly easy with documentation, particularly automatically generated documents, and with web pages.
All features as found on the specification are included, but the user interface is awkward. The vendor can claim, "we have all the features you need; thus, pick us."
The portions of the software used by high-ranking managers is given more attention than those of lower-ranking personnel.
The code is developed using every design pattern and coding "best practice" known to the top practitioners in the field and is copiously and automatically documented, but it doesn't handle the business domain use cases the customer expects, and throws user-visible exceptions on user spelling errors.
over-reliance on LinesOfCode
The company has all its project managers use a central database, part of this includes a list of their project milestones and whether they were met. The project managers were told this was for their convenience, the upper management wasn't going to track it. After one project manager truthfully reported his milestones (and setbacks), he received disciplinary action for not meeting his goals. All project managers now enter 1 milestone, due at the end of the year, usually with goals that can be met within weeks. No one has yet been admonished for a vague or low number of milestones. (The better ones still track real milestones privately, others have started believing their own CoverYourAss entries). (This last is a common side-effect of XP. It's why IdealDays were turned into GummiBearsOfComplexity.)

A database engineer was using wide tables and on paper he was meeting deadlines, completing projects, and getting paid well. Every goal was proven on paper as projects were continually being completed. However, if the engineer had migrated to thin tables, his customers may have even been happier... and the projects would have been completed with more correctness and precision and less bug repairs, even if the project was still being completed with wide tables on time, on paper.

EditHint: I don't think this is the best place to discuss this. It is a complex topic that is difficult to summarize other than claiming "X is great", "No its not", "Yes it is", etc. (FearOfAddingTables)

[There may be a similar topic floating around. If so, then perhaps we can look into a merge.

A Big software corporation has huge beliefs in having all employees setting goals (and meeting them, in which case you may be rewarded in some way). One middle manager wanted to play the game by the rules, so he got his manager to agree on three goals for him and his department consisting of around 50 developers. The goals were of the easily quantifiable kind: number of certifications, utilization degree and a thing more that I can't remember what was. The goals were met, but everything else was left to itself. The manager got his promotion and but his department in ruins.

This is so important it must not be buried here in a page name which does not convey the full importance. It is not just a question of software development. -- JohnFletcher

I don't think you need to worry about that, John. This page is under the category of metrics, and that topic gets a whole lot of attention on this here discussion board. Heh. -- MartySchrader

Not to me confused with the Soviet shoe factories that produced only one type and orientation of shoe - with the other half of the pair being shipped in from 500 miles away.

The Soviets sure had a hard time getting shoes right ;-)

Just like Amerukans have a hard time getting their urban legends right...

And presidents.

Gee! The Ruskies sure don't have that problem, huh? :-)

But Putin is popular and that is why he remains. Our "democracy" is failing to get rid of an unpopular man stuck in "stupid" mode (GWB era).

He'd be popular too if he could bump off journalists at the same rate as Putin...

Karl-Rovian slander is almost as powerful.

I remember a variation on this that had to do with Soviet padlock production and, I think, Soviet ankle sock production as well. Since production was measured by weight rather than by unit, Soviet locks tended to be rather large and dense. The same goes for Soviet ankle socks. Probably apocryphal, but a worthy metaphorical warning about measurements all the same. I'd like a pair of those ankle socks though. --DonOlson

I remember one story from a high-school history textbook which was a factory making toy plastic balls had to meet a quota of balls per month, but was never supplied with enough plastic, so it ended up making them thinner and thinner to meet production requirements without any regard for whether they would pop as soon as one kicked them.

Perhaps it's unfair to pick on just communism. Capitalism has it's own cases. For instance, a consumer may compare two store radios on style and sound quality. However, one of the radios may drain batteries twice as fast and have an adapter that is not only flimsy, but very expensive to replace. Most consumers cannot check these in a store.

I think it is partly because bigger organisations can get away with incompetent management and useless products for far longer than smaller ones. A coffee sop selling tepid mud and stale sandwiches will die fairly quickly, but big companies often die slowly, and government-backed or government-owned companies are the ultimate in giant organisations. That's how British Leyland was able to reach such depths of mismanagement, and a communist sate extends that even further. Of course, state-owned enterprises are not inherently inefficient - DB is a fairly obvious example of a successful state-owned company.

I've worked for some pretty sleazy small companies. See LieOrStreet. And, small companies can often take bigger risks because the stakes are smaller. McDonalds putting saw dust filler into burgers would kill tens of thousands of stores or even the entire company if caught, while a the mom-and-pop burger joint only risks a single shop going out of business, and the owners can just go work somewhere else selling smart-phones or whatnot if things burst.

Factoring SSFP into Planning and Decision Making

Based on material in IfFooIsSoGreatHowComeYouAreNotRich where the benefits of the "new" or "better" approach may not be apparent to decision makers such as tool choosers.

Some of it may be a case of SovietShoeFactoryPrinciple, but one should probably factor in the existence of SovietShoeFactoryPrinciple when making economic decisions or recommendations. The "systems" must work (fit) in environments where decision makers may not have perfect knowledge. If you plan with the assumption that decision makers are all-knowing, your plan will probably fail when put into the real world where SovietShoeFactoryPrinciple plays a big part because they will eventually boot out systems that don't fit their expectations as-is.

Us techies have a tendency to presume the "best" tool in our tool recommendations without considering this. This is because we tend to look at "raw logic" first and people issues second; but this is often a mistake because people are a big part of the equation of the work world and economy whether we want them to be or not.

It could be argued that techies are making a SovietShoeFactoryPrinciple mistake by ignoring the "people side" because it's far more difficult to quantify than things like code size or maintenance steps.

This is why, at a certain huge Bay Area company with an elaborate code review process, I published an internal InsanityWolf? meme "Submit shit-on-a-shingle code changes / with perfect style and commentary"...

...shortly before getting sacked. --PhlIp

See: MacroAndMicroRigor

CategoryMetrics