Lamenting with a friend that the majority of code we see in the wild is written by people who don't know the first thing about writing code.
Maybe we can muse on this? There is something interesting going on here.
I've seen two serious exceptions to the lament:
1. They are working with a technical coach. 2. They are in an ensemble
Otherwise, the best we can say most of the time is that it achieves the effect (often in the worst possible way).
Otherwise, any basic understanding of software design, coupling, cohesion, software organization, OO or functional, etc is not evidenced.
If your company doesn't have (or, I suppose, rent) technical coaches, doesn't send developers to any craft training, and doesn't have mentorship programs, then you're probably seeing the same things we see.
But if you're finding that people (relatively new to sw dev) enter your company and develop design-sense, technique, quality code (internal and external) and work well with others....
PLEASE tell me what you're doing so well!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
So here's what I wanted to think on today: Continuous Improvement.
It has two features to consider:
* It's about making improvements
* It's continouous
Let's take the 'continuous' bit first:
* You're not in it for a burst or for a while, you're in for good.
* Nobody has completed their continuous improvement program. Ever.
* It's not "hopping from rock to rock" - improvements sustain and accumulate.
If you "improve" by expending greater physical effort and endurance, you can't do continuous improvement. Working harder isn't an improvement at all.
You have to sustain if you're to be continuous. Lower the level of effort necessary to succeed, don't brute force it.
So a given web application has an architecture which involves a UI and an API and under that some domain objects, data, etc.
When a new feature comes up, there is a gherkin test that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working.
The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way.
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!!!
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."
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.