[gfodor]

The problem is it’s extremely hard or often impossible to know what are good choices before you’ve started building the product. This, combined with the fact that software is highly malleable, should lead one to highly prefer a bias towards action vs analysis. It’s not a hard rule, but it’s much more common for people to fail due to analysis paralysis than due to poor technology choices. If you are able to get any form of traction, opportunities open up to expand resources and time that will be needed to adjust technologies. It won’t necessarily be fun, but when going through such an experience I believe more often than not engineers have hindsight bias, not a true recognition that early choices were made objectively incorrect given the knowledge at the time.

[hinkley]

I’ve seen plenty of project grind to a halt from bad decisions and high pain thresholds. I think you’ll find and even mix in the overanalysis crowd of white tower thinkers and people exhibiting allergic reactions. If you are seeing more of the latter I have two theories. One, those people gatekeepe projects, so once bitten twice shy (ie they accumulate and add friction) or two, you are looking at more early phase startups than me. A seed phase startup locked in analysis never sees my resume, so I don’t see how often that happens.

But the trick is to start with the new Reversible decisions.

We don’t always know which are the reversible decisions, but many of the irreversible ones are obvious. For some reason developers always focus on the irreversible one. We reason that we have to get this right, because it’s very important. And if it’s important, we should do it first.

No. No. No.

If instead you start tackling all the reversible decisions first, you can make those choices quickly (because changing them is cheap, spending a lot of energy on making them is a waste of time and capital). Start building something. Get momentum. Get the team and ideas to gel.

When you start to know what you’re doing, then tackle the irreversible decisions one at a time.

But typically, everyone wants to Decide. And they want you to decide on short notice, right now, like some sort of used car salesman. If we don’t tolerate this from others, why do we tolerate it from our teammates?

Deciding for the sake of deciding is not productivity. It’s painting a floor when you haven’t identified a workable plan yet. There are always at least four corners, and rarely more than two doors. The odds are not in your favor.

[shantly]

I'm having a hard time following what you mean. Could you give some examples of an irreversible decision that can be deferred in favor of some other specific reversible one(s)?

[hinkley]

Interesting. You know, I would’ve sworn I had a pat answer to this question, but it turned out I had to think about a little bit.

They say that some of the most rewarding interactions for teachers are the ones where they learn something, not jus the student. Every once in a while I get an example of that in real life.

So what are some examples? Programming language is often difficult to change. This is sometimes listed as a pro for microservices. Because I get to change my mind for every new area of the app, which makes it cheaper to reverse directions.

The most obvious answers that I have are load balancers and external caches. I shouldn’t have a big knockdown drag out argument over haproxy vs nginx. Now, a load balancer is almost a given. It’s possible that someday in the future, someone will invent an SMP machine with 256 cores that gets some economy of scale by running a whole website on two machines. It’s easier to reduce the number of machines behind a load balancer than it is to add a load balancer to a mature product. So put one in, but don’t fight about which one. We don’t know if we need haproxy features, or if we want paid support from nginx now. Just flip a coin and move on.

Similarly, external caches are usually easier to turn off than internal ones. With internal caches, people start to pass around IDs instead of objects, assuming object lookup is “free”. It becomes integral to the information architecture. A rat’s nest of lazy and duplicate lookups. External caches are cheap but never free. Access tends to leave bigger footprints in the code. And there’s some small hope that you can get a direct lookup down to a small multiple of the cache lookup time if it really becomes necessary.

Database architecture is another big one, for certain dimensions. Going with Oracle is hard to take back. MySQL vs Postgres is smaller. KV store versus MVCC SQL database is also harder. For a prototype it might make sense to pick one that is obviously a placeholder, like SQLite, until you know what your customer’s needs really are. Do they need audit trails? Are they addicted to graphs? Multitenant security? On and on. You can stave off fights with SQLite because it’s effectively a promise to revisit this later.

[gfodor]

If you thread this up to the product-level, opportunities abound. For example, instead of storing data for a feature, see if you can get half the feature without the data storage. Or, if a certain feature is going to require a major shift in the way the UI looks or works, perhaps there's a way to blend in a v1 to the existing metaphors that can be replaced later. Etc

[taneq]

Exactly. You should aim to build fast, at least at first, but it needs to be understood by all that this is part of “build fast and iterate”. It’s not just “build fast and stop”.