With my current mindset that things are broken, I dive into my current readings including The Goal and The Toyota Way.
The Goal: A Process of Ongoing Improvement
I read The Goal back in my business graduate school days (about 5 years ago), but now its reading has a whole new impact. I am seeing more into the book after 5 years of working in software than I did as a fresh college graduate. Some of the mental exercises the protagonist in the book is going through I am going through as well. As he wrestles answering questions concerning his factory, I am wrestling with the questions concerning my software projects.
The first exercise is to define ‘the goal’ for his company and all companies. Of course the protagonist takes a long time to come to the logical conclusion that it’s to make money.
Every company’s goal is to make money.
As a software consulting company, how do we make money?
We make money by winning a bid for a project and then performing the work to complete the project within budget.
That seems pretty simple. Nothing about data access technologies, TDD, user stories, or any sort of architecture or design pattern.
If you need X done and will pay $Y then we should do X for less than $Y.
Why is it so hard to deliver on that?
- Define X
- Estimate Y
- …something
- Profit!
If we scope a project then we need to know what X is. Simple to say, but man is it difficult to capture!
X is always in motion, a moving target. The client changes their mind, we have scope creep, and what appears simple always ends up being more complex. We all know this! Its the one constant with software development. Things are going to change.
From my perspective, SOLID and design patterns focus on writing code that is more adaptive to change.
SOLID and design patterns in of themselves do NOT move us towards our goal by reducing the cost of writing software.
SOLID and design patterns move us towards our goal when our software has to change because the cost of the change has been reduced.
The principles and patterns also provide a common language for developers. That common language moves us closer to the goal because current and new developers can grok more of the design in less time. And time = money.
Where does testing fit into all this?
Testing allows us to keep track of the quality of our production. Or.. does it? After some re-examination I want to say testing adds no quality. That will have to be another post.
Testing provides a way to measure our progress towards X. We know we are moving towards X because we can have tests that verify we are delivering towards our promise. When I mention testing I am using a broad definition and including all sorts of tests from UAT testers to automated unit tests.
So what does Test Driven Development (TDD) provide? TDD focuses every bit of code towards satisfying a test. If every test is relevant towards progress towards X, then TDD focuses our development towards productive work. Logically any work not moving us towards delivering X to our clients is unproductive work.
What conclusions have I come to?
The goal of a software consulting company is to make money. We make money by completing X under $Y. One of the important steps is to then define what X is. We know X will change so we should write code that is adaptive to change, but we need to balance that with only writing code that moves us towards delivering X.
- We achieve more flexible and understandable code by using SOLID and design patterns.
- We measure our progress towards X by passing tests.
- TDD focuses our coding towards productive work.
I started to write about estimation in this section but have decided to move it to another post.
After thinking about estimation, it has nothing to do with knowing what X is. Estimation has to do with what we think $Y is. X is what X is regardless if it takes you 3 hours or 3 months to deliver.