The two terms are often used interchangeably but are actually very different in an extremely important way: one is about resources, but the other is about speed. As a tech lead or manager, knowing this distinction can really help make the right decision for your projects in certain situations.Read More
If you are an engineer or product manager or a manager of any kind and have not read Henry Ford's autobiography, My Life and Work, then I strongly suggest that you do. It is a wealth of insights and a glimpse into the mind of a man whose genius wasn't merely "invention, assembly lines, and operations" as is commonly taught in schools. The truth is, Ford had an eye for simplicity.
Ford understood that to succeed in democratizing the automobile, he had to simplify the car, which was a grossly wasteful machine in his day. His aim was to achieve fewer moving parts, lighter materials, and fewer irrelevant options, which led to a lean, mean, and (most importantly) cheap machine. His strategy, you should note, did NOT include financial gimmickry or ways to squeeze workers' wages; in fact, he did the opposite, seeking opportunities to improve their effectiveness and then pay them more.
He took it a step further, however, than just simplifying the product: he also relentlessly simplified the machine that made the machine: the Ford Company itself and its factories. This was a very deliberate effort on his part. To do it, he empowered all of his employees, ranging from executives down to factory technicians, to take that mission into their own hands.
The results are astonishing. In 1908, a Model T cost $850. The average worker earned about $500 per year at this time. By 1925, he had gotten it down to under $300.
TLDR: read this book. Think like Ford. If you think you need a new bit of infrastructure or component, just buy it or build it. If someone on your team groans about a chore, push them to solve it once and for all. You'll go faster, not slower. You'll deliver cheaper, sooner, and better. Otherwise, you'll find that you've paid for it and don't have it.
At some point in your life, you probably realize: everything in the world is broken and sucks.
There are two ways you can react to this truth:
1. Go into a deep depression, adopt complete cynicism, and protect yourself.
2. Put a smile on your face and relish in the opportunity to improve it, give, and bring joy to others.
These days a lot of people talk about the magical wonderfulness of “minimalism” and living “simply” and take cute pictures of themselves meditating with a cup of matcha in their spartan apartments and post them on Pinterest or Instasnap or whatever. So pretty and aesthetic.
Screw that. This post isn’t about that. I care a lot more about what things COST. Real time, real dollars, real opportunities missed.
After you read this post today, I want you to just remember this one simple thing the next time you think about introducing anything new into your life or software:
It seems small and trivial today, but in the long run, it is massively expensive to add something.
Here are some examples:
A single checkbox.
It seems so innocent. Let’s JUST add it, right? How bad could it be! It’s so little and it’ll solve everything!
Hold up. Consider all the implications for the days or years to come:
- You can't easily take it away. If you do want to remove it, you’ll have to send emails, warn customers, deprecate it, gradually wean them off of it onto a new solution, then phase it out. This is a lot of work, so you usually end up just dragging it into the future with you.
- Reorganization of the interface must carefully consider it. You can’t just dump it anywhere. When you have N features on a product, your designers need to carefully evaluate the N * N relationships and come up with something balanced and beautiful. Adding one more thing makes it that much harder. The result is that design not only takes longer but also starts to lose cohesion.
- Code must be maintained to support it and at times must be refactored and reviewed, slowing new development.
- Automated tests must be written and maintained to ensure it works.
- QA must test it and its side effects. A single checkbox effectively DOUBLES your testable state space. To add salt to the wound: they’ll need to do this every single time you even touch anything near this thing.
- New engineers and new customer support staff will need to be trained in it, adding yet another thing to the long list of things they are required to know, slowing onboarding.
- Bugs can and will emerge around it and some customers will be someday burned by it. When it happens, engineers will need to divert precious time from important projects to fix it.
- Worst of all: a year later, you have some great new idea that may not conceptually jive with this checkbox and you will be constrained by it.
A side table in your living room.
It's only a hundred bucks. No problem, right? You fall in love with it. Impulsively buying it is quick, easy, and feels awesome. It looks SO spiffy in the corner next to your shelf of smart books. But then:
You now need to dust it once in awhile.
If you care for your wooden furniture and want to ensure they’re long-lasting, you must also continually purchase proper wood cleaning / polish products.
If you pay a person to clean your home, it will take up some of their precious time. Given enough items like this taking up 1% of their time, we’re talking a serious amount of effort every week of every year.
Next time you move apartments, you need to pack it or wrap it and pay movers to ship it. Or you can move it in a rented truck, which must now be a bit bigger to accommodate and reserve for even more time.
When you buy renters insurance, you must account for this side table in your possessions and pay a slightly bigger premium. Given enough items like this, you’ll be paying significantly more and at the end of the day basically insured a stupid side table you gave only 10 minutes of thought to buying.
Just the mere PRESENCE of a new surface invites you to add more shit on top or inside it with ALL THE ABOVE PROBLEMS.
Rinse, repeat, die by a thousand papercuts.
If you’d rather avoid all of the above bullshit and would prefer to actually live your life and/or solve real problems for your customers, just cut the crap. Make the burden of proof for adding things really, really high. Create a culture of restraint. You’ll thank yourself later.
A lesson I learned long ago, from a wise teacher of martial arts, still resonates with me today. He said to me:
"Don't worry about hitting fast yet. First focus on your form. If you don't have good form, you'll never be able to strike swiftly. You'll have too much wasted movement."
"Don't worry about hitting hard. After you have perfect form, focus on speed. Hit your targets quickly and efficiently. Power comes from two things: velocity and mass behind it. If you're not fast, you'll never be powerful."
"Finally, deliver with force. Use your entire body. When you've mastered all else, you can hit harder than someone twice your size."
Don't try to jump ahead, or you'll never achieve your goal. Always train yourself in the proper order: first form, then speed, and finally power.
Optimistic Concurrency Control = stop signs.
Pessimistic Concurrency control = traffic lights.
Stop signs assume low contention over a resource (the intersection) and tend to yield higher throughput if that is true. Average latency does tend to suffer a bit from the overhead, however, as every single car needs to slow down a bit to check that it's not about to slam into an oncoming car or pedestrian.
Traffic lights are very explicit locks over a resource (the intersection). Traffic lights assume that there is going to be high contention. Worst-case latency can be very good since you fly through a green light at top speed, but you now have a strict lower bound on the minimum latency (the time for the green light to switch on for your direction).
When there is low contention over an intersection (e.g. very late at night) you should really convert the signal into an optimistic lock.
I've observed that a large class of meetings are about bringing verifiers to bear upon solutions.
Typically, one individual has done the NP-Hard work of finding several solutions to a problem and asks for several others to bring their verifiers to bear on the solutions and identify the best one, or offer suggestions on how to tweak the solutions to move closer to an optimal solution.
Meetings cannot, however, find truly novel solutions. That's left up to the individual.
A few weeks ago I wrote up a review of Fred Brooks' great book, The Design of Design and felt inspired to create this poster to summarize my favorite chapter on "Technical Aesthetics". Take a look! If you're interested in a printed copy, shoot me a message.
For my ally is the Internet, and a powerful ally it is.
Bandwidth creates it, makes it grow. Its energy surrounds us and binds us. Luminous beings are we, not this crude matter. You must feel the Internet around you; here, between you, me, the desk, the router, everywhere, yes...
Even between the browser and the server.
Unless your system is explicitly designed to perform well at unbounded scale, impose a limit. Do not allow the system to simply degrade in performance at "unlikely" scales.
Users can and will abuse the amount of things they can cram into any opening you provide.