DRY, WET, AHA, and Doing Things That Don't Scale

If you have been building software for a while, you've undoubtedly heard "Don't Repeat Yourself", commonly shortened to DRY.

The phrase suggests that you should write your code in a way that you only have logic for any given functionality in one place, never repeated. If your code has all the logic written out for functionality such as "get all the orders and count how many of them had a discount applied" in more than one spot, the maxim says you should condense that down into one place - say, a function or module that can be called.

It's a good maxim, and like all maxims it should be applied with an amount of prudence. Google recently posted Don't DRY Your Code Prematurely on the Google Testing Blog, showing how that too much DRY can be a bad thing.

You may have also heard of WET (Write Everything Twice) as a counter to DRY. WET advocates for making sure you actually have the same code twice before you start writing a bunch of abstractions that you may or may not need. AHA (Avoid Hasty Abstractions) basically says the same thing.

Of course, software engineers aren't the only ones guilty of these premature, hasty abstractions.

I've seen spreadsheets that are way too complicated, in anticipation of future needs that may or may not come about.

Sales orgs end up investing in a ton of tooling, inevitably complicating their processes in pursuit of perfection.

Even operations departments can be guilty of over-proceduralizing things in preparation for massive scale that might never come, or for growth that will go in a different direction than expected initially.

Paul Graham advocated for doing things that don't scale in one of his most well-known essays. Some of the specific examples he gave include:

• The Stripe founders would get somebody to agree to try Stripe, and rather than sending a signup link they would simply ask for their laptop and get them set up on the spot.
• The AirBnB founders went and took photos of the first listings on the site, once they realized that this was one of the gaps that was keeping the site from gaining traction.
• Ben Silbermann of Pinterest fame noticed that a lot of the early Pinterest user base were designers - so he went to design blogger conferences to recruit more users.

The point isn't to ignore scalability, nor is it to get sucked into needing to do a lot of heavy lifting for every user or AirBnB listing you add. The point is to defer thinking about massive scalability until you need it.

The AirBnB founders travelled around taking pictures of listings (almost the exact opposite of DRY), then they paid for local photographers to take pictures of your listing, and then when high-quality photos were understood to be table stakes for the site property owners made sure they had good photos all on their own.

To get their initial growth the founders needed to get high-quality listings up on the site immediately, so they did the unscalable thing that needed to be done. If they had focussed on building tutorials on how to shoot great property photos, or on figuring out how to financially incentivize professional photography, they never would have hit critical mass to where scale actually mattered.

Your little startup isn't going to have "infinitely scalable" growth capabilities. You won't have hundreds of millions of dollars to spend on marketing, and you won't have a team of hundreds of people to cold-call all your potential customers. You might need to spend a lot of time cold-calling on your own, attending conferences, and sending emails one-by-one before you have the traction and name-recognition for a huge ad campaign to give you the results you need.

Keep an eye to the future as you build and grow, but sometimes you gotta just do the grunt work and push through until you have the resources and can justify the more scalable approach to your problems.

Do things that don't scale, and feel free to repeat yourself. Once you need scale, you will know exactly what you are scaling and how to do it.