Why doesn’t anyone care how long this takes?

I’m an odd duck. At least, that’s how it seems when I join a new development team. I have different habits, notice different things, and generally hold strange viewpoints relative to most software developers. It took me far too long to understand that these differences were merely a matter of my experiences and approach to development.

As an example, I was starting out with a new team and working on my first small bug fix. It was a very small issue and an existing team member helped me find the appropriate code and work through the fix with me. The process was roughly:

1. Get my local environment set up for development and run the app through the scenario to confirm the bug as expected (15 min)

2. Make the hopeful code change (5 min)

3. Run the app through the same scenario to verify the bug was resolved (5 min)

4. Run through some more scenarios to double check nothing silly was broken due to the change (10 min)

5. Push the code change to the hosted repo

6. Wait for the automated tests (CI build) to complete (15 min)

7. Loop

   1. Wait for a 3rd developer to review the changes

   2. Handle the review comments (loop through steps 2 through 6. 30 mins each time)

8. After approval merge the change

The entire process took 3 days, primarily due to the code review feedback/change cycle. This is a pretty typical workflow for many dev teams. As I asked around a bit about how this process was working for people it seemed everyone was pretty happy with how everything worked.

My feeling on the whole thing was that there was a lot of waste happening and I wasn’t at all confident that the change I’d made wouldn’t cause other issues. Like I said, this is pretty typical of many teams’ workflows and processes. I’ve seen it in nearly every place I’ve worked. Why doesn’t anyone care how long this takes?!

Recently, Beth Andres-Beck and Kent Beck suggested the metaphor of the Forest and the Desert and I find it provides a good explanation for what I’ve seen over the years. Take a minute and read through it. Once you’ve worked in the Forest, software development will look different to you.

Here’s what I experienced while I was working on that first bug:

1. Wow, this is a lot of steps. It sure takes a while to get to a fresh state.

2. Ok, not surprised there’s a bug in this long function.

3. Typical, manual testing. At least I’m learning a small piece of the software.

4. Do we have to do this? I haven’t seen any automated tests yet so I definitely don’t feel confident. Best to test as many scenarios as we can.

5. Standard process

6. Oh, there are automated tests, wonder why we didn’t run them locally before we pushed them up. Maybe because it takes 15 minutes to run them!

7. Typical review/change loop. Yuck.

Now, there’s a lot of good stuff going on here and this was a very talented technical team. There were indeed automated tests and they are run on every change during the CI build. The environment setup documents were quite thorough and easy enough to follow. From many perspectives this was a very good workflow. The issue is that I’ve seen what is possible and this is far from it. And so begins my typical mission to help the team learn the values and techniques of a Forest team. It may seem like a dream but it’s possible and once you’ve been there it’s hard not to want to get there again.