« The 3 Levers and Code Design.

As your team and codebase grows, things can get hard to measure, feel like they are slowing down. the more work you put in the more it seems to get worse. I know I have been apart of codebases that fight you at every turn. this is a rough space and can be very disheartening.

You might wonder why is this? why have things gone so poorly? what did we do to get here and how can we get out? there are some important things that are good to understand when you evaluate questions like this. So let’s dive in.

The 3 levers of feature development.

There are always 3 levers you can pull on when planning and executing on projects. Time, Scope, and Quality. If, at any time, one of these levers gets pulled, the at least one of the others will be effected.

Here are the three examples:

1. if we want to add a feature to a project, we now have to choose whether we will bump the due date or the quality of the code will drop.

2. if we need to make sure a feature is really well tested and it cannot break and has to be flexible for the future, we need to drop the scope of the feature or push the due date.

3. finally if we need to bump up a deadline, code quality will drop or the scope will need to be changed.

We always want features faster, and the reasons for changing scope is always highly circumstantial, but there are some clear universal effects around changing code quality. So let’s talk about that for a sec.

What does mean “design” in context of programming?

We could spend endless time just on Object Oriented Design and Principles. But in summary at a high level I would say it is Modular Code VS Procedural Code. Code that is modular is broken up into small pieces that can be reused and replaced. Procedural code might look more like 1 long function that does all the work in the life cycle of rails request.

So what are the trade offs of design vs no design?

Initial cost of design can be heavy and not worth it if it costs your company too much time to launch.

The cost of feature development over time changes though, while the code base is small and only does basic things, there is a real benefit to skipping the design portion of writing code, but as the code base grows the cost of feature develop starts to grow exponentially.

How will you test? it can be extremely difficult to test code that has been tightly coupled without consideration for design. But test-ability becomes a lot easier the more modular the code is.

Another factor to consider is churn. Just how often does a file get touched/code changed? When there is no design, it becomes difficult to change existing code. But if you never the change those files, maybe there is no need to refactor.

Developer Happiness is a large thing to consider. If all your developers hate working on a rigid code base that is extremely difficult to change it can lead to burn out and eventually your team will move on. I like to think most (if not all) developers do like the challenge of refactoring and rebuilding pieces of the code base to be more modular, but they need be empowered to make things better.

In Closing.

When planning projects and changing things about them, these levers are getting pulled, we can either pull them ourselves fully aware of the trade offs we are making or we can let the levers get pulled around around us and never know why things are not going as planned.

These tools have always helped me consciously make a decisions about what trade offs I am making and how to prioritize what is best for the company.

If you enjoyed this, please let me know. Also if you have anything to add to the conversation please comment below! It is all about learning from each other.