The cheapest architecture decision

The easist thing to measure in business is how much something costs. This can be aggregated to true subscription or tooling costs or the hours put into implementation. What's harder to measure is everything that comes after.

It is more than what you see

When building products or tools, the approach I see most often used is "how do we get this thing right now". I'm not saying that this is never the right answer, but in my experience it almost always leads to problems down the road.

Callout · The thing that sticks with me

The cost of a tool is not its price. It is its price plus the cost of maintenance plus the cost of the users exerpience, internal or external.

Immediate gratification vs. longevity

When looking to build a new product or feature, there is a tough balance between getting that thing out as soon as possible versus getting it out in a state that is going to last. Often I will observe the prioritized objective to be to get it out as fast as possible. This could be to beat a competitor into the space or to meet an objective of n-number of new users. The latter is my least favorite reason to do something.

When I see these used as the driving force behind the effort, it usually comes along with taking shortcuts or making decisions that suit the immediate need but not something that will scale when needed.

I'm not saying that products and features can't be built quickly and I'm not saying that quickly made things can't scale. What I am saying is that pressure for delivery can have a direct impact on the products future success.

What is the true cost

Beyond the obviously identifiable hours worked and tool pricing, there is a cognitive cost to the end users and the team that supports them. There isn't a formula for figuring out a number for this and this isn't something that can usually be listed as a cost in a development plan. This doesn't, however, mean that these things shouldn't be taken into consideration. These invisible costs can often be the highest impact to the end product.

Callout · The eternal conflict

The debate I hear most often between a designer and a developer is this:

Designer: The product doesn't matter if it isn't clear how to use it. Developer: The product doesn't matter if it isn't functional.

They're both 100% right. Your product could be the most performant system in the world, but if the user can't figure out how to use it all of that performance is lost.

What I would tell someone making a plan

There will always be a give and take when balancing delivery speed and solution robust-ness. For me, speed for the sake of speed is the worst decision influencer.