Software Development: Sprint vs. Marathon Mindsets

Two mindsets.

Sprint Mindset. Ship it! Go for speed! SPRINT!

Marathon Mindset. Clean Architecture and Code results in lasting quality and speed of development, but may take longer in the short term.

Sprint Mindset. Focused on Time To Market (TTM)

The Agile proponents take it as a given that we should be optimizing for Time To Market (TTM). “The Fast Way is the Right Way” are a few words I have heard to describe this mindset. Now don’t get me wrong, there are times when shipping software fast is the only thing that matters.

Short runway, company is going to die if the product isn’t launched within 2 months? Build it quick and dirty!

Need to hack together a script to do a customer-specific one-off migration? Go for it. As long as it gets the job done right.

Prototyping something to see if focus groups respond well?

I get it. There are plenty of times it makes sense to go the fast route.

But what happens when organizations continually make the short-term expediency choice time and time again?

Well in fitting together each feature in a “build the thing as quick as possible” kind of way, we are left continuing to build a taller tower on an unsound foundation and rickety support beams.

I have witnessed larger organizations fail to remain relevant as smaller organizations out-maneuvered them. Where had their speed gone?

“If I change this, it will impact these 4 other things.”

These are thoughts that slow a developer down immensely. Now the choice is: change the 4 other things (start by seeing what impact that might have) or put in another hacky, band-aid solution. So let’s play Choose Your Own Adventure…

Hack it = Technical Debt

Another band-aid solution it is.

This added technical debt is frequently brought on by rushing an implementation. Developers code towards features rather than capabilities. Feature-based development often results in tightly-coupled code. It bakes in assumptions. You know, the things that are difficult and costly to change.

Now we are living in a codebase that is a nightmare to work in. Making changes is like solving a sudoku puzzle of logic balancing.

For some reason, things have started to slow down. So you crack the executive whip harder… Maybe that will work?

Refactor = Artificial Risk and Cost

Duct-tape solutions won’t work. Let’s refactor.

Perhaps you’d prefer to go the change the four other places in code (and the cascading changes those may require). Or perhaps you’re breaking the habit of making the short term choice again and again, and now is the time to do some refactoring.

Well refactoring artificially induces risk. I’m not saying don’t refactor. By all means, it may be time to pay the piper.

But perhaps this path was more avoidable than we had previously thought. Which brings us to… The Marathon Mindset.

Marathon Mindset. Focused on Total Cost of Ownership (TCO)

What we might instead consider is to focus on Total Cost of Ownership (TCO).

When we focus on TCO, we will build systems with capabilities and not features. Features will only come out of our capabilities. There will be a clean separation of concerns which will allow development teams to grow and still remain fast.

In many options we may rely on distributed or even cloud native systems. If we are working with distributed systems, we will prioritize testability. We need to focus on proper granularity of services so that we can have a simple system of where new functionality should belong. If it needs to be in a new service: where should that service belong and is it the Stripe service or the Payment Service?

Whenever we are working on a product of any respectable size, we will can reduce the project duration and cost by thinking ahead and building a cohesive system. Measure twice, cut once.

Remember: capabilities, not features.

Balance

However, there is always a balance to be had. At the extreme end of optimizing for Time to Market, we wind up with spaghetti code and worse- a spaghetti architecture.

At the extreme of optimizing for Total Cost of Ownership, we have overengineering and diminishing returns for time invested.

So, balance.

Which way to lean?

When do we want to have more importance on TCO? Given that the bulk of work is spent maintaining software and not just building it, optimizing for TCO is ideal for situations where we want to keep moving fast.

And when do we want to put more importance on TTM? Prototypes, true one-offs, and for startups without runway. These cases may demand a priority put on TTM.

Wrapup

So which problem is your organization facing?

All too often I see companies that cannot move quickly anymore and it can be costly. They are encumbered by system design quality and code quality from choosing the short term path each time.

Or there are organizations that use heavyweight processes. A barrage of meetings, stakeholder approvals, specs, heavyweight analyses. I will talk about this in a future article.

There are even organizations that are simultaneously encumbered by both!

Is your organization encumbered? I help organizations move fast again. Get in contact with me.

See the original post at johnbindel.com.