My disagreements around planning seem to revolve around metaphor: a plan is X. Different answers for X lead to different behaviors and different evaluation of outcomes.
“A plan is a prediction of the future” is a common metaphor. Nobody out and says that, because it is absurd in an atmosphere of substantial change, but that’s how some folks act.
“A plan is a chance to escape a local maximum” leads to different plans and planning. This plan is about stepping back from execution to see if there is a different path entirely.
“A plan is a sanity check”, likewise different plans and planning. If we are already doomed, it might be good to know now rather than later. (I’ve seen plenty of folks who act like they don’t actually want to know until later.)
“A plan is a commitment to another team” seems valid to me, but that doesn’t mean the plan has to be a prediction of the future. It means you commit to learn together about your needs and capabilities.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
After a while, you notice that not all programming is the same. Déjà vu sets in. “I’ve done this before.”
A list of distinctions in software design.
Reversible vs irreversible. Some changes are easily reversed. Make these quickly & with confidence. Other changes have consequences for the larger system. Make these only after double checking. Converting irreversible changes (even partly) into reversible changes creates value.
Structure vs behavior. Structure changes are mostly reversible. Behavior changes are likely irreversible (e.g. reporting different answers to tax authorities) & require multiple feedback loops. Separating behavior from structure changes creates value.
There are times in my career when I would have already pushed the Hardcore Button. My self-image was based on out-working, out-intensitying everyone. I wouldn't push it now, but I can understand if someone else does. Here are 3 strategies.
1. Push it & mean it. Before doing this, create a stop loss--if my health gets *this* bad or my relationships get *that* bad, it's not worth it. Because your health & relationships will suffer.
(I've seen too many suicides in tech, so suicidal ideation is a no-saving-throw eject. No matter how you feel, your job is not worth that. This is from experience.)
Took me 17 years of struggle, but I can finally explain cohesion in software design. I dropped the Cohesion chapter of the #TidyFirst book yesterday. I'll summarize here. tidyfirst.substack.com/p/cohesion#payWall
An element is cohesive if its sub-elements are coupled. A file is cohesive if all its functions have to be changed at the same time.
"Isn't that bad that they all have to be changed at the same time?"
Compared to what? Having those functions in different files is worse. It's easy to miss one.
Folks seem to tune software development for a desired output rate. That's a disaster. Here's why, what to do instead, and (at the end) a speculation about an unhelpful belief that might underlie this behavior.
I've been surprised to see smart folks unironically suggest that waterfall development is actually the best way to develop software--specify what you're going to develop, develop it, finis!
They then adapt "the system" (by which I mean the system of folks & machines that develop the software) to the desired output rate. We have XYZ on the roadmap, we have 6 people, how can they get XYZ done quickest/cheapest?
I got into a pissing match on LinkedIn (achievement unlocked):
Them: You cashed in on Extreme Programming with all those certification programs.
Me: Ha HA! There *are no* XP certification programs.
My bad. There *are* XP certification programs. Lots. WTAF?
I have called the Certificate-Industrial Complex "dishonest", "a pyramid scheme", & "cancer". Once more for the folks who just got here:
Certificates misalign incentives:
* Employers want skilled workers. Also efficient, industrialized hiring.
* Employees want genuine knowledge & skill. Also a fast track to a well-paid job.
* Certifiers want a thriving economy of skill. Also maximum revenue at minimum cost.
Ignorance-as-a-service. My team is experimenting with frequent pair switching. Was it wasteful to be explaining the same basics repeatedly? Seemed like no, but why?
Uninformed questions are most valuable when you're likely to get stuck in a local minima. "Ignorant" questions can get you unstuck.
When you aren't clear on what problem you're solving or how you're going to solve it, lack of knowledge is a precious resource.
I assigned @arlobelshee's Promiscuous Pairing paper user.it.uu.se/~carle/softcra…. Re-reading it I was struck by the team consciously letting go of Flow as the ideal state for programming and replacing it with constant Beginner's Mind.