If we go from Idea to Behavior change to new Idea…
how quickly we can do that depends on the structure. @kentbeck
If we go Idea to Behavior to Idea to Behavior
as fast as we can,
it’s gonna get slower and slower and then the developers will get frustrated and leave and the new developers will be even slower…
So sometimes, we make a structure change before the behavior change. @KentBeck
Try this: make your commits each a structure change or a behavior change, not both.
We work in an area of great uncertainty. What will our software need to do next??
Greater optionality leads to money, in the long term: we have access to different futures. But it can cost more now.
The counterbalancing force to discounting cash flows is optionality. @KentBeck
Coupling: when making a change in one place means ya gotta change other places too.
elements are coupled with respect to a certain change.
Change difficulty follows a power law distribution.
We live in a natural world in software
(a natural world we aren’t very aware of, but still) @kentbeck
Most of the cost of software is the cost of change.
Most of the cost of change is due to coupling.
So coupling costs money… but so does decoupling, that takes work.
This is our tradeoff
If you tell stakeholders, we’re gonna spend months refactoring the system.
“What are we gonna get after all that ‘refactoring’?” (little dance)
“The same system you have now”
… not relationship-building. @KentBeck
We all have the option of doing software design that enhances our relationship with ourselves, our peers, and people with different perspectives.
The more you can make your changes in small safe steps, the more you can preserve your relationships. @kentbeck
• • •
Missing some Tweet in this thread? You can try to
force a refresh
SREs in the audience? (Dozens of hands)
Experienced SREs? (Like 2.5 hands)
We @RedHat used to ship products. Build a thing, package it, send to customers. Then it was their problem. Customer hires a consultant or figures it out.
Now we mostly ship services. Now it’s our headache, reliability and uptime etc. It’s different
The team deserves someone
who wants to manage people.
who is not bitter about meetings
who is interested in sociotechnical systems and nurturing careers
whose technical skills are strong enough to evaluate their work.
We have known how to build software for a while now, and the question is,
Why don’t we? @bethcodes#Agile2022
I look at SAFe and I see us reinventing Taylorism from first principles. @bethcodes #Agile2022
The alternative typically presented is structurelessness.
Let every team do exactly what it wants, whoever keeps doing it longer without getting fired wins the argument.
People don’t feel safe without structure. @bethcodes