Lean and the Team

In my last post, I talked about comparative advantage and how it can aid you in developing your team and your members’ skills. Now, I’ll talk about another aspect that you need to consider in a lesson from Lean.

I have never described myself as a person who espouses any one single methodology for solving problems, so you won’t ever see me write about the one right way of doing things. Many processes and frameworks were originally designed for one thing, and I have had uneven results applying them to software development. One thing that I have found to be very helpful in developing a team is a specific subset of the Lean concept of muda, which I came to understand when reading the book The Goal.

The Goal, Eliyahu M. Goldratt
The Goal, by Eliyahu M. Goldratt

If you haven’t read this book, it’s highly regarded and a bestseller for making certain business concepts very accessible to the reader. I highly recommend it.

The book has two great takeaways – first is the answer to the question: What is the goal of a company? The answer: To Make Money. It’s a very handy thing to keep in mind.

The second takeaway is the Theory of Constraints. This is the idea that production bottlenecks can take an assembly line and slow it to the speed of its slowest machine. Continue reading “Lean and the Team”

A Quantum of Programming

As I’ve worked through almost two decades as a software developer, I’ve often wondered about the relationship between time and features. Basically, should the ‘explainability’ of a feature be proportional to its time to develop. I think it should. This can be generalized as: A small feature should take a small time to develop.

In physics, a quantum is the smallest divisible amount of energy that a thing can have. In software, I think that a ‘Quantum of Programming’ is the smallest unit of work that is actually a piece of usable software. Continue reading “A Quantum of Programming”