The Efficiency-Destroying Magic of Tidying Up

From what I've seen, this may be true in some particular cases, but this is not a general pattern.

I've found that beauty, in software (as in art and design in general) very often has common elements. People certainly have different preferences in how the elements are put together, but I think many people can appreciate the underlying principles.

Here are some examples of the principles behind beauty in software:

* A component obeying the principle of least surprise

* A function having a clear purpose

* A function using a small (perhaps minimum) number of arguments for its purpose

* A codebase cleanly separating concerns

* A codebase reusing standard components

* A codebase having appropriate documentation suited to the team working with it

* A codebase having good testability

* An algorithm (e.g., one based on a published paper) solving a problem by doing less work

* A function having fewer lines of code

None of these are absolute. (For example, the last two may sometimes exist in tension with one other.) I see the concept of beauty as relative to a set of goals and values. Beauty almost always often involves a sense of balance and proportion: trading-off principles that are not perfectly orthogonal.

Of course, there are different perspectives on how to achieve a particular balance for a particular situation.

I'd like to add an unsupported claim (that I happen to believe, given a set of mostly rational people working together in a healthy work environment): If you get these people together and say "is codebase X beautiful for purpose Y?" I think you'll find a lot of consensus. In areas where they disagree, I think the resulting discussion will likely be constructive. I would bet that the discussion will lead to a better design in the end -- as perceived by the participants. This assumes that the people learn from each other; e.g. proponents who tend to favor one principle are willing to listen to proponents of other principles.

When I worked at Amazon, everyone worked out of the same repo(s), used the same build system (Brazil), deployment system (Apollo), deployed to the same place (EC2), most APIs were written using the same framework (Coral), etc. This is not that unlike the other large tech companies, and now that I'm back at a large non-tech company where everyone builds their own slightly-incompatible tools and deployment pipelines, I do miss that standardization.

Sure, some people chose to use different tools here and there, but most people wouldn't choose to reconstruct the universe just to stand up a microservice. It's not like all the "two-pizza teams" were all doing completely different things with incompatible tooling.

It's been a while since I worked there, so things might've changed completely since then. But as a shareholder, I hope not.

Because that's the time when you've learned to understand the problem, and you already have working code to move around.

To me it seems like a failure to take a look at the bigger picture. In the end it is all about the value provided. You are creating a start up that has 10 percent chance of succeeding and only if it gets to market fast.

Also it is never binary. It is always time invested vs quality of the code. It is a spectrum. From what point can you call code crap?

The closer you get to perfect code the more time it takes to get it better as you are closing near perfect.