by Thierry de Pauw on
Lean Code, Kevlin Henney @KevlinHenney
I want to talk about Lean from the point of the developer.
It's there for nearly 20 years
Dates back to "Lean Software Development", Poppendieck, 2002
Which dates back to the paper "Lean Programming", Mary Poppendieck, 2001
Recent work in Agile Methodologies, Adaptive Software Development, and Extreme Programming
have in effect applied the simple rules of Lean Manufacturing to Software development.
The results, which we call Lean Programming, are as dramatic as the improvements in manufacturing brought on by the Just-in-Time and Total Quality Management movement of the 1980's.
Applying manufacturing principles to software programming is dangerous! Software engineering is not an assembly line except for the deployment pipeline. @KevlinHenney
=> defined 7 principles (see the book)
they are more like directives, not so much principles
What is value?
Yes, the planet got destroyed, but for a beautiful moment in time, we created a lot of value for shareholders.
value is more complex than that
Your customers do not buy your software by the line, David Evans
=> the value of your code decreases with the lines of code
It solves a problem. It has a utility. It has a job to do. It is useful.
=> it is not just verbose code
=> I'm going to turn a simple idea and turning it into something complex
Deleting dead code is not a technical problem; it is a problem of mindset and culture. @KevlinHenney, Dead code must be removed
Dead code has a value and it is negative, @KevlinHenney
TCP packets have TTL
Credit Cards have an expiry date
we (IT industry) are very bad at that
=> code and features need to expire
We keep talking a lot of incremental development, we need to talk more about decremental development, @KevlinHenney
If a codebase has unmanaged technical debt, there are a number of things that are likely to be harder than necessary:
• Staff retention
• Tracking changing markets, requirements, technologies, etc.
Remember that there is no code faster than no code.
-- Taligent's Guide to Designing Programs
=> problem with performance improvements => it adds complexity and exceptional cases
There is no code more secure than no code.
There is no code easier to maintain than no code.
Myth: the 10x developer
To be a 10x developer, be a good developer who can help 10 other developers to get good, ...
=> communication creates knowledge
communicate: Latin communicare - to share amongst many
Encapsulation is important, but the reason why it is important is more important.
Encapsulation helps us reason about our code.
=> it helps create knowledge and pass knowledge
In the long run every program becomes rococo -- then rubble., Alan Perlis
We have this wrong idea that everything we do is fixed.
Unless you have the perfect specification, that contains every piece of knowledge you need and it will never change.
And yet, there is still change. You, your knowledge. You learned about the domain and how to build it.
Even if you change all sources of change, there is still change, your knowledge.
Problem is: when you say to people it might change, they say: oh, yes, it needs to be configurable.
We propose ... that one begins with a list of difficult design decisions or design decisions which are likely to change.
Each module is then designed to hide such a decision from the others.
-- David Parnas, On the Criteria to be Used in Decomposing Systems into Modules
This idea is deep. It is in all levels of your architecture.
It requires a lot of effort. It requires slowing down.
Sustainable development is development that meets the needs of the present without compromising the ability of future generations to meet their own needs.
-- The Report of the Brundtland Commission
projects vs products
What about all the shortcuts, the technical debt?
and now we payback.
But customers don't want to pay for that?
Never assume what customers want unless they say it directly to you.
Product development and most code fall inside that, the goal of the game is to keep playing the game.
Move fast and break things
-- dates back to the 1950's
You'd better do the opposite:
Move slow and mend things.
We have this obsession with speed
What you really want:
Deliver sooner, not faster.
Seek velocity, not speed.
Speed is a magnitude. Are you going into the right direction? I don't know but I go really fast.
Velocity includes direction.
Teams have this one-directional view on moving forward.
Plan - Do - Check (Study) - Act
I prefer Study: it takes time, it takes a deliberate effort, it is slow
How to think about the test-first cycle in TDD:
• What does success look like?
• What is the simplest thing that could possibly work?
• Taking a step back, are there any gaps, repetitions, inconsistencies, trends or questions?
• How would you address them?
TDD is fun! It's like a game where you navigate a maze of technical decisions that lead to highly robust software while avoiding the quagmire of long debug sessions. With each test there is a renewed sense of accomplishment and clear progess toward the goal. Automated tests record assumption, capture decisions, and free the mind focus on the next challenge.
James Grenning, TDD for Embedded C
Habitability is the characteristics of source code that ... makes a place livable, like home.
-- Patterns of Software
Point of architecture is not to introduce structure, it is to allow people to work inside it.
There's little correlation between a group's collective intelligence and the IQ's of its individual members.
But if a group includes women, the collective intelligence increases.
Diverse teams are more likely to constantly reexamine facts and remain objective.
-- Why diverse Teams are Smarter
One of my most controversial software opinions is that our sleep quality and stress level matter far, far more than the languages you use or the practices you follow.
Nothing else comes close: not type systems, not TDD, ...
-- Hillel Wayn