@IndustrialLogic & @ModernAgile. Mentor, author, consultant, trainer, tech, blogger. Benevolent chaos-bringer. Husband of 1 wife. In sw dev since 1979.
Ragan Profile picture ptitnoel Profile picture Jonathan Escobar [EN profile] Profile picture Andrea Fabris 🇪🇺🇮🇹 Profile picture Mr BRD - Profile picture 11 added to My Authors
Oct 31 7 tweets 1 min read
I worked with a team for a few weeks.
People built using TDD or very tight test-after.
It was all trunk-based with continuous deployment.
They formed up squads/swarms/groups as needed to get work done.
They turned around improvements in a day usually.
1/
They had never worked together before.
They'd never worked in ensembles before.
They'd never done CD or CI or TDD or TBD.
A few were somewhat experienced, some had never built software before.
2/
Oct 4 8 tweets 2 min read
Naming is hard, so we should just use arbitrary names and try to keep them straight in our heads.

Custom types take effort so we should deeply nest native types and try to remember what each subscript means.

Code is hard, so transfer more burden to heads?

No thank you. This is an important point, not just Tim grousing.

"You should be smart enough to figure it out" takes the burden off the code to express itself, and onto the person to pay a lot of attention and maybe take notes.
Jul 25 8 tweets 2 min read
It was a lot, this #agile2022. There are people I would have liked to visit that I saw only in passing. I spent a lot of time in the company of people, and made new friends as well as hanging with long-established friends. Overall, it was more people than I'm used to. I was rather exhausted as I'm not used to maintaining my energy. Being an introvert in a huge crowd takes some opportunism.
Jul 7 7 tweets 2 min read
So "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."

So.... If you find a scrum team that isn't self-managing or self-organizing, I guess that the team is either still in the course of an ongoing transition or the SM is committing malpractice?
Jul 7 9 tweets 2 min read
Nobody knows the whole system, nobody knows the whole stack, nobody knows the entire standard library for each of their *favorite* languages, nor the whole product community.

You need some advantages here... When all you have is one head, you need to augment your intelligence as much as you can. Keep browsers open, sure, and look things up quickly, but also checkers, linters, security scanners, syntax highlighting, formatters all IN THE IDE so they're active WHILE YOU CODE!
May 18 4 tweets 1 min read
Divide And Conquer never (outside of certain software teams) meant “let’s split up and go it alone.’ That’s like a bad horror movie strategy.

You divide the enemy/problem into small parts that you can more easily defeat, not yourselves.

The force that is divided is conquered. This whole “let’s divide our forces so that we can be more easily defeated” idea is really quite daft. We don’t defeat the enemy by splitting up and going it alone.

If you have a big problem, divide the problem, not yourselves.
Your power is in combining your strengths.
May 17 7 tweets 2 min read
You have a program you have to use every day. It has 48 fields on one screen, and an "okay" button at the bottom.
What you get depends on which fields you fill in... 1/ If you fill in fields 1-4, 12, 32, and 48 (you may have to scroll a bit) then it will create a new account, but don't touch fields other than those or it will attempt to either update or delete the account listed in field 32. 2/
May 16 5 tweets 1 min read
I recall once when we built a huge distributed realtime system, and the client called in an analyst to perform a function point analysis.
The analyst said that there were only a dozen or so screens, & a handful of reports: the system should have taken a few weeks to build. Teammates said "dude! The screens and reports are the *least* part of what we've done. This isn't a store-and-report business system! It is a distributed control system!

The analyst wrote a one-sentence statement "this is a control system, so FP may not tell the whole story."
May 15 8 tweets 2 min read
So, what do you think? Image Scrum, Inc:
scruminc.com/velocity/ Image
May 11 12 tweets 3 min read
You have a bug!
You don't understand it or you wouldn't have created it!
Okay. That's a good place to start. Okay, we look at it real hard and think about it. If we realize what's wrong (for sure) then we can fix it. We need to be really sure.

Hmmm... if we are really sure, we could write a test that duplicates the error, and then fixing it should make the test pass.
May 11 4 tweets 1 min read
DO have better ideas, more ideas, worse ideas, different ideas.
DON’T build them because you thought of them. Check with the story sponsors.
Get their feedback
Let them tell you where/why your ideas are wrong or naive.
Let them congratulate you when your ideas are better.
Hold off on building just a bit...
May 9 4 tweets 1 min read
Did you know that every human being has blind spots in their vision?
It's true. You don't know it because your brain lies to you about what is there (assuming whatever it expects to be there, is).
But there are spots that don't respond to inputs. Where your optic nerve connects to the retina there are no light-sensitive cells. It's not even connected to a weird part of your eye that shouldn't normally see light (like just behind your eyebrow and down a bit).
May 6 5 tweets 1 min read
The standard tragedy that we keep trying to deny (because it's hard to comply):

* Capacity-to-do is finite: we can only do so much
* Time is finite: it runs out
* Opportunity is time-sensitive, and consumes capacity We keep looking for ways to beat this or cheat this, using techniques we have available to us. I don’t think we can beat or cheat. I think this is something we have to learn to roll with, gracefully.
May 5 4 tweets 1 min read
Code that keeps re-making the same decisions over and over in the same execution pass -- it's frustrating:

if x == 1: do this
... (next fn)
if x == 1: do this
... (next fn)
if x == 1: do this
... (next file)
if x == 1: do this

Waste, waste, waste, duplication, and cruft. This is true when there are flags instead of something like Strategy pattern, when using checks instead of polymorphism, when using a lot of feature flags, when ... well, whenever state or value affects execution and it's not encapsulated somehow.
Apr 22 6 tweets 1 min read
I want a better term than "bad code" because that sounds like an ethical/moral judgment on inanimate artifacts.

Some code works, but it's ... whatever "If it works, it's not bad" well, it's not bad IN THAT WAY. There are other things we consider.

I'm looking for something like "unprofitable"

The code requires a big (possibly ongoing) investment from me and does not return anything for my investment.
Mar 4 15 tweets 3 min read
What is "advanced" and when is something "advanced"?

Some people think that if you came upon something late in your career, it's more "advanced" than something you found earlier.

Or that recent language features are more "advanced" than earlier ones.

I disagree. There may be some language features or practices that are quite recent, but are simplifications of ways that we used to do things. That's not "advanced," just "new."

Is 'var' an "advanced" Java feature?
Feb 18 12 tweets 2 min read
"Ability To Do Work" is so ignored by many contemporaries. It's easier to assume that one person is pretty much the same as another, on average, and that work is done by individuals.
This way the math works out for linear gains from adding headcount. "Capacity" has become a euphemism for headcount.
The "on average, a programmer is a programmer, a QA is just another QA" is not only wrong about individuals, it's dreadfully wrong about teams.
Feb 15 4 tweets 1 min read
Don't say "capacity" when you mean "headcount"

A team's /capacity/ is how much they're capable of doing together.

Pretending they're equivalent is (foolishly) pretending that programming is mostly typing. Capacity is the right idea, though.
What can you do to increase the ability to do work other than bumping up the number of developers.
But likely you can improve skills and focus and tooling and raise capacity, remove waits and queues and returns.
Your capacity isn't headcount.
Feb 14 7 tweets 3 min read
@eikonne I also find the pair-programming he’s referring to to be suboptimal.
For me to type all day while you criticize, or for me to criticize all day while you type (worker/watcher or worker/critique) is indeed a very dull and wasteful thing.

Pair Programming, on the other hand… @eikonne … actual pair programming by co-creating code, switching roles frequently, switching partners a few times a day, is not only an excellent pedagogical tool but a great way to do work.
It also means you don’t break tasks down to individual skills, but work more whole features.
Feb 6 4 tweets 1 min read
If you were born into tech in a modern corporation, you might think that “agile” is an estimation technique based on repetition and practice, or perhaps a workforce performance management system based on constant checkpoints. Would they know it was about making software better?

Would they recognize the goals of healing the mgmt/dev divide, working within capacity, delivering early & often?

Would they recognize autonomous, cross-functional, self-managing teams as a bedrock concept?
Feb 4 4 tweets 1 min read
The most difficult of all simple ideas to internalize is probably this: To be done sooner, do less. This is true in the large and in the small.

Small: If I use the "rename" refactor, it changes all the references as I type the new name. If I don't, I have to carefully walk the code base, changing the name (spelling it correctly) every place.