Q: Why say "ensemble"? Just use the proper name "Mob Programming!" Is this just PC run amok?
A: I needed a term to encompass Pair Programming, Mob Programming, and Swarming. That it's inoffensive is a very nice and welcome bonus (worth it).
You know, people snigger when I say "pairing" as shorthand for pair-programming. It suggests sexual behaviors.
People also flinch when I say 'mobbing' because it is a term for grouping up to bully people in schools and workplaces.
"Grooming" is another - suggesting pedophilia.
We deal with words as they are used and try to not draw connotations we don't mean. That's just being clear.
"Ensemble" is a good category term. The other, better, term is "teamwork" but people have coopted that to mean all kinds of "working near but not together."
"I tell you what to do, and you do it. That's teamwork" says the PHB on one Dilbert cartoon.
"Each of us does our own work: that's teamwork" many believe.
"Team player" is one who attends meetings and goes along without making waves. ¯\_(ツ)_/¯
"Ensemble" suggests multiple people doing the same thing together.
That's like "five musicians playing the same song at the same time in the same place."
It's a better image.
Where people get confused is when they think of ensemble programming as "four people doing the job of one."
That's such a misunderstanding.
Adjustment: think of "four musicians playing the same song" not "four musicians playing the same flute" and you get the idea better.
Rather than "doing the job of one" try to think of "doing one four-person job" -- the jobs aren't as fine-grained if you're doing ensemble programming.
Think how much "breaking down and assigning" that saves you, as the lead/manager!
My favorite motto for ensemble work is "whole teams doing whole jobs."
See what methods the primitive type has which are not appropriate for the domain of variablename. What does type do that variable shouldn't?
string CustomerId;
What does string do that a customer ID shouldn't?
It can be
* passed as a time zone.
* upper/lower cased.
* concatenated to/with other strings
* passed as a filename to open()
* centered in a field of spaces
* used as a format in a print statement
* searched
int typeCode;
It can be:
* operated upon bitwise
* used as a port number
* treated as a boolean
* multiplied/divided/added/subtracted
* overflow/underflow
* passed to so many functions!!!
Just read a story about a new COO who started their first day on the job by cleaning the kitchen.
They drew a line saying that " spread the word that the next person I caught leaving a mess for their fellow employees to clean up would be shown the door."
Leaving a mess for their colleagues to clean up?
Sounds like Business As Usual in a lot of corporate software groups.
"If I don't do a good job, then that's okay. I can close the ticket and someone else will fix it."
Because, sadly, in many shops "getting things done" is "closing tickets."
"Look how much we did! We closed 20 tickets!"
"What can we demo today?"
"Well, nothing. It doesn't work yet and we can't deliver, but 20 tickets!"
"That's fine, then. Next sprint, we want 30 tickets."
Why don't you have tests?
Why don't you refactor?
Why is the code so bad?
Why can't we be responsive?
Why are we slowing down so much, so fast?
The problem with sprint packing (maximum amount of work per time box) is that people have to cut corners (including quality, design, testing) to make a tight deadline -- only to be given one equally tight or tighter.
Ad infinitum.
The kind of "go faster" that teams do to keep up with the work is like the driver ignoring warning lights, not getting tires changed, not washing the outside or throwing away trash.
It's an ugliness that piles up because there isn't time for caretaking.
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.
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.
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.