People often treat standardization as a self-evident good.
They want everyone to do everything the same way so it will be standard.
A short thread is in order here.
The primary reason we standardize things is for interoperability.

If we're not going to interoperate, then there's no point in standardizing.

If we ARE going to interoperate, then we need standard *interfaces* not standard everything.
This suggests that we don't need everyone on every team to work the same way, or for teams to operate (internally) the same way other teams interoperate.
There is another concept, though: standard work.

Standard work in manufacturing is to ensure that everyone does the work the same way every time, consistently, as a basis for improving the work incrementally.

Fine if you're turning out N identical widgets per day, right?
Standard Work is constantly being updated and improved. THAT is the reason for standard work.

Whatever you do right now is your standard work.
Your input and your output vary constantly. They're never the same from job-to-job. What looks like "just add a button" to someone who isn't doing the work seems pretty standard, and you'll build it from standard components (ah, that interoperability thing), but it's unique.
If it already existed, you would not have to write it.
Once it exists, you will never write it again.
So if the input and output are constantly varied, what is "standard work" for you?
It seems that "standard work" can only apply to the habits (and micro-habits) you apply to doing your work every day, since it doesn't apply to the inputs and outputs.
How crucial is it that every person has an identical approach and set of habits? Should they be the same across teams doing different kind of work, in different stacks, for different clients? Or is that a place for only interface standardization (so teams can work together)?
Maybe there are habits we can share; approaches like TDD or DbC, version control behaviors (CI), or release behaviors (CD vs Big Bang).

But teams do different work, and may need different habits.
We shouldn't assume that standardizing all work identically is a good idea.
There is no way to standardize humans and it's not even a good idea to try. People bring themselves to the work (it's 11/12ths thinking, you know) and diversity results in better decisions and fewer defects.
Maybe next time you talk about standardizing anything, you'll think about which kinds of standardization you mean, which you really need, and where you should grow diversity instead of standardizing.


It's a choice.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Agile Otter Tim

Agile Otter Tim Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tottinge

8 Dec 20
The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive.
I'm very sorry that this quote didn't show up with quotations and a link. It should have. I'm not sure where it came from now.

This saddens me. I hope it's not lost.
Read 4 tweets
3 Dec 20
You know what I don't do as a developer?
Memorize a big codebase.
I used to try, but then found I couldn't do it.
As a result, I have to make it scannable, discoverable, readable.
This has an unexpected benefit.

As it turns out, human memory is not a shared resource. There is an advantage to the person who knows how it all works, provided nothing changes (much).

But nobody else owns your memory, and it leaves with you.
I later found out that my "inability" to memorize a big code base is the reason people appreciated my code and found it useful and maintainable.

I didn't really do it for them at first, but as a survival tactic in a world where a lot of people had better memories than me.
Read 8 tweets
29 Sep 20
One of the standard issues with going to swarming or mob programming is always "How will we spot the bad programmers then? How will we catch the people who are loafing? How will we spot underskilled people if they don't do individual work?"
I went as far as to add it to my slide deck when I am teaching whole-team structures. It is going to come up anyway, and people are usually glad it's already in the topics list.
Of course, the first thing I say is "I don't know. I've not seen it yet. Swarms seem to keep everyone involved and interested pretty much all the time." This is true. It's hard for people to believe.
Read 11 tweets
4 Sep 20
We are once again offering the Technical Excellence Workshop as an open-enrollment experience this October.

It's an 8-week experience where we spend a few hours a week together, and we explore technical skills, perspectives, safety, behavioral skills, & leadership.
There is access to expert eLearning and there are exercises to perform during the week (some canned exercises, some live exploration) that will change how you look at your work and your organization.
Students from prior iterations have said that they had better interactions with their teams in the first week. Some claim that it made them better programmers. They have been able to initiate continuous improvement in their organizations.

Others learned to explain and teach.
Read 5 tweets
3 Sep 20
You know, we all considered "data class" to be a code smell (if not an antipattern) for a long time.
Generally, I still see it as being a flaw, but the world has changed a bit.
XML docs are essentially data classes.
JSON docs too.
Read 8 tweets
18 Aug 20
There are different motivations for role success.

But I have to wonder if sometimes it's a kind of revenge fantasy rather than a positive drive.
"I hate being told what to do, so I am going to be the one who does the telling" is a kind of revenge fantasy, maybe.
Certainly "they said I would never amount to anything, so I'll show them!" is a revenge fantasy.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!