Florida and Minnesota each developed their Statewide Automated Child Welfare Information System (SACWIS). In Florida, system development started in 1990 and was estimated to take 8 years and cost $32 million. As Johnson spoke in 2002, Florida had spent $170 million and the system was estimated to be completed in 2005 at the cost of $230 million. Meanwhile, Minnesota began developing essentially the same system in 1999 and completed it in early 2000 at the cost of $1.1 million. That’s a productivity difference of over 200:1. Johnson credited Minnesota’s success to a standardized infrastructure, minimized requirements, and a team of eight capable people. - (Poppendieck, 2003)
When I started as a web developer I was obsessed with productivity. When I read the Toyota Way by Jefferey Liker it changed my understanding of productivity. Toyota was founded in 1933 by a family-owned, textile manufacturing company that transformed itself into a world-leading automaker. The collection of principles and practices that led to their success is known as the Toyota Production System or Lean and is so effective that they have been copied by its competitors.
Software developers and automakers share a similar problem - when we develop products for our customers we make complex design decisions that balance variation, costs and time.
Mary and Tom Poppendieck translate Lean principles to agile practices in their excellent book - Lean Software Development.
This is a summary of their ideas.
- Stop waste
Waste is anything that does not add value to a product, where value is perceived by the customer. There are two questions here - who is the customer and what is valuable? This is the most important and the hardest part of lean because an organization or team has to agree on the answer.
For example, the customer of the Infrastructure team is the Development team, the customer for marketing could be the sales team etc.
Hot tip: A frequent, large waste in software development is waiting for things to happen.
- Amplifying learning
Our customers come to us with unique problems which we often know little about. We have to explore different solutions, measure the impact and learn from them. This way, we iterate to more optimal solutions. But does it scale? Scaling is another set of challenges and the same mindset should apply - plan, do, learn, repeat.
Hot tip: Write code in a way that is easy to change. For example, abstractions, DRY principles, feature flags, configurable behaviour etc.
- Decide as late as possible
Plans are worthless but planning is everything
-- D. Eisenhower
This is the hardest lesson for me - I'm constantly reading crystal balls, they're so shiny! 🔮👀
When project managers, sales teams and clients want costs and time estimates to fill up their timesheets, it's hard to say, "It will be OK, I haven't made up my mind yet about that". 😬
The idea here is that change is inevitable so delaying commitments allows us to make decisions when we have the most information. For example, how much RAM will this API need? Any estimate will change based on actual usage metrics.
Hot tip: The best ideas often occur towards the end of a project because that's when we know the most.
- Deliver as fast as possible
As an industry, this is where most of our productivity dollars are spent. Every new framework has to have a benchmark with it at the top to have clout. 📈 But we should consider softer issues like faster decision making, access to information etc. Toyota is famously slow to adopt new technologies because they want to avoid optimising some production steps at the cost of the whole system. Don't take risks to speed ahead, just to get stuck at a traffic light. 🚦
Hot tip: Speed is measured by the time it takes for the customer to receive the value.
- Empower the team
There is an amusing story about a pig and chicken wanting to open a Bed and Breakfast restaurant. They argued over the menu design when the chicken suggested "Bacon and eggs". Who should decide? The pig should decide since the decision would impact them more.
Hot tip: Treat work colleagues like volunteers. Trust and respect are vital.
- Build integrity in
As software developers, we have to make trade-offs between competing goals. Business realities, competing standards, and deadlines leave their mark on the product. These compromises can leak into the customer experience in the form of performance issues (slow network requests, API quotas, large file sizes etc.), uninformed designs (missing localisation, clunky legally required information etc.) and other questionable choices.
It would be much better if we can build products with a single vision. Domain-driven design can help us get on the same page as our customers.
Hot tip: Get close to the customer and focus on what matters to them.
- See the whole
This is why I became a full-stack developer. My personal preference is to be able to understand problems from start to finish and use that information when writing software. Our industry has chosen particular knowledge boundaries like "Front-end", "Backend", "Site Reliability" and others.
Optimisations in one step of a product can make it harder to be productive in others. For example, front-end frameworks can hurt user experience through large file sizes and heavy workloads. Serverless solutions have to contend with cold starts. Database choice can limit the type of application features like region distribution, data governance etc.
Hot tip: Be careful how we measure success and set rewards. We win when we all win.
That's it - only 7 things 😂. Please let me know what you think.
And some parting words that keep me humble -
If today’s problems come from yesterday’s solutions, then tomorrow’s problems will come from today’s solutions. Avoid creating a pendulum that swings from high ceremony to low ceremony and back; look for the balance point of the lean principles.