I’ve read many books and articles and watched videos over the last 14 years that informed and shaped my thinking. I’ve put these into the order that I came across them and added some comments.
Note: I moved this section out of my 2020 article “Time is valuable, Project to Product, reducing waste and Software Development Process“
Thank you to my University of Minnesota, Morris professors for teaching this approach and unit testing!
An earlier book, before DevOps and deploying more often was a normal thing, on setting up tools to integrate code continuously. He also showed how you can continuously deliver changes to test and production.
Building software is not like building physical buildings, it’s like gardening.
I read this in the DNC magazines (I miss getting the MSDN magazine mailed to me… I can’t remember if DNC was in paper for awhile now.)
These videos from 2017, continued to open my eyes to what a development culture and process could be. Feature Teams, feature flags and releasing on a normal schedule. These are still well worth the time to watch.
Gene Kim shares a story of a company going from bad culture, releases going wrong and payroll not working. The “guru” or “Yoda” shows up and shares the 4 types of work and three ways. A lot is focused on lean manufacturing, identifying the constraints and making work visible.
After I read the Phoenix Project, I wondered, “how can we actually do this?”. The DevOps Handbook provided learnings from others and topics to dig into.
The research and statistics show that the software systems we build and how we do them affect employees lives (measured by eNPS). There are direct correlations to higher performing teams and automated testing, continuous integration and continuous delivery.
Experiment, measure and pivot. Learn from Lean Manufacturing. Define your users with customer archetypes and use that for a guide.
Architecture should allow easier changes and adapting. take into account cohesion and coupling. The business rules should be a the core. As developers we should fight for time to fix technical debt and improve architecture. Architecture isn’t something that can be all planned up front (building software is not the same as construction) and evolves based on trade-offs. John and I gave a presentation at SD Code Camp and Omnitech’s book study write up.
Gene Kim shares a newer story, closely following the heroine Maxine as she navigates getting a build to run to joining the “rebellion” to actually create value for the company. Companies can win in the marketplace and create value when the focus on creating value instead of cutting costs.
Mr. Kim introduces “The Five Ideals” as guiding principles:
This was a free book on Kindle for awhile. He had some great insights and ideas. I’ve been meaning to write a full article about it, but this section will have to suffice.
Did you know that no one really has a handle on what “value” is for the business? We expect product owners to know, but even they are guessing. Often those we are building the software for don’t completely know what they need either. It’s also hard to measure it before we start. There are many metrics that people use, but none cover everything.
Value is different for profit, non-profits and government. Even bureaucracy rules can have value.
How do we measure Value?
We need to spend time and experiment to learn what value is for our businesses. Value could be features, technical debt reduction, learning, business does not always mean customers, agility.
He promotes experimenting, feature teams, Lean Startup ideas, Agile, DevOps, incremental learning and adding business people to tech or tech to business (think Google/Facebook/Microsoft that have CEOs that are also engineers).
This podcast has been very helpful for development tips, to approaching problems and process. Start at the beginning and listen through.
Ok, I haven’t gotten very far in this book. Ubiquitous language (same terminology in code as the business) and Bounded contexts stuck in my mind. We can use ideas from this book to mimic real life in code and discover how things should work. We need to work directly with people in the business to learn together.
At the end of Domain Driven Design: The Good Parts - Jimmy Bogard, he says to skip the DDD book (or focus on Bounded contexts) and get the Building Microservices by Sam Newman.
See my resources page for more links.
Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!