Occam’s Crypto Corollary: “For every posited blockchain use case, there is a solution that doesn’t use blockchain that is both simpler and less expensive.”
You shouldn’t start with the Spotify model. Spotify didn’t start with the Spotify model.
You shouldn’t start with Scrum. Scrum didn’t start with Scrum.
You should start by identifying what you want to improve, and introduce constraints that force the improvement.
The best programmer I know doesn’t have a CS degree. The other best programmer I know does. What they have in common is an insatiable curiosity and the belief they can convince a computer to do anything. Plus a healthy disregard for language and tool zealotry.
Hot take:
#Kubernetes
is just
#EJB
for the cloud generation. An over-engineered, vendor-controlled, "open", catch-all solution to a problem no one has, which conveniently ignores the hard problems of release engineering, provenance, and observability. Or is it just me?
“We were doing something unethical with your personal data which has now been made illegal. We have shifted our position slightly so we are just unethical again.
“Please click this link, ignore the text and tap the ‘Whatever’ button so we can continue to abuse you. Thank you.”
If you call the person who has to interact with your software a “user”, you haven’t figured out what they are trying to get done.
What are they trying to do? Name them after that. Then think about how to get your software out of their way.
No one wants to just /use/ software.
So I did it. Here are my detailed thoughts on the content of the
@McKinsey
developer productivity article. I wrote it as though they asked me for a technical review. I hope you (and they!) find it useful.
Ok I'm going to do it. I am going to refute the
@McKinsey
developer productivity article _by its content_ rather than just saying it is clearly a crock of nonsense.
(Spoiler: it is.)
I have plenty of notes from the article, I just need to make sense of them now.
regretrospective (n): Recurring agile meeting in which the team complains about things, no one takes accountability, and nothing gets done. Mature agile teams often have Edith Piaf playing to set the tone.
See also: Stand-off meeting (n).
[Thread] What do I mean by “the best programmer I know”? Let’s start with the assumption I think I’m a decent programmer. Here are some examples:
1. He sees what is really there. I see what I am conditioned to see. Once he points it out, it was obvious all along.
We need to talk about testing.
It has taken me a long time to write this — and to get round to writing it — because it is a meaty topic and because I procrastinate. I hope you like it.
Ok so I took Uncle Bob on holiday with me. Or rather, I decided to finally read Clean Code cover to cover, and wow, I have opinions. I mean, even as a technical book reviewer, I would really struggle. A handful of gems buried amid a vast amount of content that has aged like milk.
How to institutionalise and further entrench the insanity that is feature branches (or anything other than trunk-based development: ).
Friends don’t let friends use feature branches or GitFlow. Friends keep all their code on master and use feature toggles.
Wow another excellent post, I was struggle about how I should organize my branches, so this post is my question asked.
#git
"How to organize your git branches" by
@hardkoded
#DEVcommunity
Hey, here's a thing. "The Business" doesn't "own the money", and your software team doesn't just have to do what it is told. Those are wooden dollars. You all work for the same company and you all want the company to succeed, so why not collaborate on driving it forward together?
Certifiction (n): the belief that a two-day residential class with a multiple choice quiz at the end qualifies you for anything other than a couple of days of training credits.
See also: Scrumduggery (n): the act of perpetuating the myth that such classes have value.
@johncutlefish
Agile was invented by programmers. It was repurposed, via Scrum, by project managers. The technical rigour baby got thrown out with the XP bathwater, leaving just the planning and rituals, which themselves were repurposed into serial status updates.
#TrueStory
Your periodic reminder:
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” -
@martinfowler
The difference between a "lean backlog" and an "agile backlog" is that neither of them exist. "Backlog" is a term specific to one agile methodology, namely Scrum. Outside of that context it is meaningless. Thanks for coming, please collect your certification on your way out.
Banks refusing to work with crypto are like banks refusing to work with scammers. The crypto Ponzi schemes haven’t collapsed yet, only because they are still in the “some of the people all of the time” stage. I’m with the banks on this one, and I don’t often say that.
1/n tl;dr:
Sometimes you have to work like a dog to get to a place where you no longer have to work like a dog. Claiming otherwise is privilege.
I'm a financially stable 50-something. I grew up poor (by Western standards) in a single (alcoholic) parent household.
I'll say it again.
#k8s
is just J2EE for the cloud generation: over-engineered, overly complex for 99% of use cases, but ubiquitous and mandated as a solution before we have even looked at the problem.
People selling complexity-as-a-service will always make money.
It's only 10am and I've already bumped into three Kubernetes-based dev platforms via email and Twitter! 🏗️
The good news is that they are all pitching a high-level value prop and (to a large degree) a complete/end-to-end solution.
This is an interesting battle space for 2023 🥊
Thinking of developing my own software product development methodology called Tragile. It won't ever ship anything but it will use all the right words.
It may help to think of ChatGPT as bullshitting-as-a-service. So if your job involves bullshitting—political scriptwriters, enterprise software marketing copywriters—then GPT is coming for you!
Wow, clinging to PRs as a quality totem is the new clinging to feature branches. It's almost as though trunk-based development didn't have a ton of academically defensible research behind it.
And this is why
#ITIL4
is set to fail from the outset. These two objectives are not "in competition". Doing
#2
well gives you
#1
for free. The limiting belief that they are in conflict is what leads directly to ITIL-style control theatre.
If you have to estimate story size, your stories are too big. All stories are size 1 if you make them small and consistent. There, that’s the estimation done.
If I'm hiring mid- to senior-level developers, I think their ability to regurgitate algorithms, whether on a whiteboard or elsewhere, is one of the least interesting avenues to explore with them.
As a consultant or as a permie, I have never understood the attraction of this.
Oh
@LinkedIn
, your email telling me I have a message without telling me the message never gets any less irritating. It doesn’t increase “engagement”, just resentment.
@lissijean
The way I’ve been describing it is:
1. The goal of the system is rapid and sustainable flow of value.
2. Delivery teams should understand value and obsess about flow.
3. Product managers should understand flow and obsess about value.
I wonder if the Agile Manifessto would have been misinterpreted less if it had had the form:
- Processes and tools matter; people matter more.
- Commitments matter; collaboration matters more.
- Documentation matters; a working product matters more.
etc. Or maybe not.
Trolling Wave Planning (n): an agile technique of regularly telling the team they aren't going as fast as they committed to (sorry, forecast) and that they are letting themselves down, the programme down, the whole company down.
See also: Ganttlog.
- “What was that first
#GDPR
morning like Daddy?”
- “It was as if millions of voices suddenly cried out in terror, and were suddenly silenced. I fear something wonderful has happened.”
Ok I'm going to do it. I am going to refute the
@McKinsey
developer productivity article _by its content_ rather than just saying it is clearly a crock of nonsense.
(Spoiler: it is.)
I have plenty of notes from the article, I just need to make sense of them now.
What do I mean by principles?
1. Obsess about lead time
2. Obsess about feedback
3. For software, obsess about engineering principles. XP matters
4. Obsess about collaboration
5. All specialist roles act as coaches: Product Managers, Testers, SMEs, etc.
Stuff like that.
/end
I wouldn’t even qualify this to scaled agile systems. In any process, obsessing about the wait times will yield greater improvements than practically anything else, for longer than you might think. Automation, simplification, etc. are implementation details of that obsession.
"In scaled Agile systems, where dependencies and delays are the majority of feature delivery lead-time, you are better off estimating the wait time rather than feature size. The development time of small, medium or large are insignificant in these systems." -
@t_magennis
Narrator: They still had their meetings, they just didn't put them in a calendar or tell faddish managers about them. Because hard problems require collaboration.
Here's a crazy idea, teach people to have effective meetings, don't push meetings underground.
Meetings are a bug. Today, we shipped a fix to this bug at
@Shopify
.
To start 2023, we're cancelling all Shopify meetings with more than two people. Let's give people back their maker time. Companies are for builders. Not managers.
I call this pattern Never The Expert, based on
@PapaChrisMatts
’ ideas around Skills Liquidity. Where you have an illiquid (hard to obtain/grow) skill, like expertise in a legacy system, the only person _not_ allowed to work on it is the expert. They can advise but not touch.
Let the beginner drive.
Let the beginner drive.
Let the beginner drive.
It feels like it will be slower. It will very quickly become as fast and then faster.
Travel at the speed of learning.
When you're teaching new developers, PLEASE make sure you tell them what keyboard commands you're using, what IDE plugins you've added, and WHY you're doing things!
These are small things more advanced developers forget but make a big difference to new devs.
React is over-engineered for practically any context, including Facebook.
Focus on the hypermedia, see eg.
@htmx_org
.
“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” - Peter Drucker, 1963
Still looking for a single valid use case for blockchain. Extra credit if you can’t do it using signed git commits.
For me blockchain is the epitome of what
@JerryWeinberg
calls “solutioneerihg”.
I actually wouldn't mind hearing from companies with an email like this:
"Hi, you don't need to do anything. We just wanted to let you know we are already
#GDPR
compliant because we don't do anything bad with your data. Thanks!"
@eduardsi
> chasing the same small sub-group of female speakers
I think I’ve found your problem. If you subscribe to the misogynist and hugely misguided view that there is a mythical “small sub-group of female speakers” that all these conferences are “chasing” then you’ve already failed.
Junior dev: "why isn't this working?"
Senior dev: "oh, you just need to do X, Y, and Z"
Junior dev: (wow they're so smart)
Senior dev: (wow I made that mistake so many times)
[thread]
tl;dr:
1. Estimates are not necessarily waste.
2. Feature/story level estimation is almost always unnecessary.
3. You’re probably doing estimation wrong anyway.
For 1 we’re going to need a brief intro to Throughput Accounting (don’t worry) and what is and isn’t waste.
Now I want to suggest that estimates are /always/ waste. They are not product (I hope) so they are automatically waste. We should want to get rid of them on those grounds.
/2
Squee! 2019 remix.
#Refactoring
was one of the most impactful books on my career and thinking. Thanks again
@martinfowler
for the gift that keeps on giving.
And excellent use of inside front and back covers, as ever.
Man, writing
@github
Actions, where I have to commit to check every tiny change, is like going back to the Dark Ages. Why can't I test changes locally? Why can't it just use my Makefile? (No, Act isn't working, sorry.)
Ok billionaires, let's play a Nash game. You can either keep hold of all your money and watch it become worthless over the coming months, or you can spend a tiny proportion of it and help stabilise things and keep people safe. Your move.
Somewhere out there is the corresponding tweet that starts:
"I had a dull and predictably condescending conversation with a man programmer some years ago..."
Hooray! Let’s hijack
#kanban
and turn that into a recurring-revenue gravy train too! Thanks,
#Scrum
oligarchs, for gutting the agility out of the Agile movement.
Now I can be a warm body at a different two day class and get a different annually-expiring certificate. Brilliant.
Big news announced at
#leanagileus
.
@Scrumdotorg
is launching a
#Kanban
course for
#scrum
teams. I have seen many scrum people attending my Kanban training, so it feels like a natural step for this to happen.
Product Moaner (n): Former Business Analyst who went on a two-day residential class and can’t understand why the team won’t just bloody well do what they’re told, like they used to.
See also: Scrum Maester (n): Former Project Manager with Game of Thrones power fixation.
Feature branching at work is as harmful as it is ubiquitous.
“… what works for the open-source community, where a core team maintains a system and accepts contributions from the outside, does not necessarily work very well for a co-located team in a corporate environment.”
Lean: the entire school of thinking and management around human-centred, flow-based value creation.
Flow: the goal of any lean system. Specifically: sustainable, rapid, frequent flow of measurable customer impact.
ToC: a set of techniques for achieving flow in a lean context.
Pro
@LinkedIn
tip: if you describe yourself as a “Thought Leader” in your profile, chances are
a) You’re not.
b) I’m not going to accept your LinkedIn invitation.
“Let’s get rid of all the X” is often “I don’t understand what X does, so I am going to assume that what they do doesn’t have any value.”
Chesterton’s Fence: Don’t remove something until you have invested the time to find out why it is there. The answer may surprise you.