Tag: management

Posted on
by

When developing software, I want to build applications quickly. In my sometimes painful experience, low quality work gets in the way of this goal. There are a lot of problems with poor code quality, but I want to focus today on how code quality is directly tied to the amount of work in progress. Low quality code leads to large work in progress which in turn causes slow and uncertain delivery time of new features.

I tend to think of low quality code as any code that leads to defects that require rework, i.e. bugs. There is an inherent challenge in this definition because it’s hard to know what will cause a bug until the bug shows up. But from experience, I know there tend to be more bugs when I write the code quickly, working alone, and without writing or running tests. There are a lot of different ways to write bad code, but those are some of the common ways I do it : ).

The low quality code really starts to be a problem when I “finish” some features and move on to developing new features. The poorly written code is not really done. Most likely it still needs some rework to really function the way it is intended. So in reality, I have more work on my plate than I can handle efficiently. Major bugs crop up more frequently interrupting me and causing the time to finish any feature to increase.

It turns out that there is no way to get around the fact that more work in progress leads to longer delivery time; it’s Little’s Law. If you have a system with items coming in that have to wait in a queue before they can exit the system, then the number of items in the queue is directly proportional to how long, on average, that it takes to process a single item. This makes sense. Long lines mean long wait times. But when it comes to planning work, it is easy to think that I can get everything done at once.

To achieve a quicker cycle time, I need to insist on high quality work to avoid the pile of work in progress from unexpected bugs. A faster feedback cycle is super beneficial. With complex products each bit of work that we complete gives us new insight into the system, and ideally we would like to incorporate those learnings into deciding what to do next. The only way we can do that effectively is to have short delivery time of features.

This is my understanding of the connection between work in progress and delivery time related to my experience, but I learned about this connection first in Kanban: Successful Evolutionary Change for your Technology Business by David J Anderson and more recently in Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.

I hope to write upcoming posts about specific things that I have found helpful in my efforts to improve the quality of my code.

Posted on
by

I’ve been reading Turn the Ship Around! by L. David Marquet about his experience leading by giving up control and encouraging leadership throughout the organization. He experimented with this leader-leader model while commanding a US nuclear submarine, the USS Sunfish. The results were dramatic; the Sunfish went from the worst performing submarine to the highest performing boat in the Navy. His story inspires me.

I love this idea that each member of the organization has some control over how things get done. In my experience, that is when I have fun and get excited about my work.

It reminds me of a time in high school gym class playing ultimate frisbee. I was on a team with a mix of skill levels, with many new to frisbee. Somehow we all got excited about the game and managed to do really well against teams with more athletic players. The key was that we all handled the frisbee as we passed it back and forth. Each pass was a decision made, an act of leadership. I remember the joy of flowing down the field with my teammates, seeing them out of their comfort-zone but excited and enjoying themselves as they attempted to make passes and out-wit our opponents.

The opposite is soul sucking. Who enjoys getting micro-managed? Being told what to do, how to do it, and when it has to be done? And yet this is accepted. Companies try to control their employees through layers of management, procedures, and policies.

Maybe it is because the leader-leader model is hard to pull off when you don’t know what you are doing. David Marquet describes an initial failure with this approach where he didn’t support giving up control with the necessary tests for competence and the necessary organizational clarity. The result was chaotic.

I can’t wait to try some of the methods that David Marquet describes from his time on the USS Sunfish. At my work, and in my life, the challenges are too complex for a leader or a management team to solve alone. It is way too much work to try to keep everyone in line when they need to be told what to do. No, the challenge of the leader-leader model is worth it. Plus it seems like way more fun!