Write Simple Code

And it will solve 95% of a typical startup's problems. Somehow, across the former Soviet space and beyond, companies hire people in their twenties with a grand total of three years of experience — and these people immediately start building ideal architectures. Yes, every single one of you: as soon as you get even the smallest bit of responsibility, you remember all the books you've read (and haven't read) and start crafting your unique architecture, unlike anything that exists.

That's right — unlike anything that exists, packed with errors arising from misinterpretations of concepts or simple lack of experience. I won't give specific examples in this article — they've been discussed here plenty of times. Instead I'll approach it from a different angle.

Every time you look for a solution to a problem, ask yourself one question: CAN I DO THIS SIMPLER, WITHOUT LOSING TIME OR PERFORMANCE? If your answer is "YES," then take another look at what you've cobbled together and delete 90% of your unnecessary class factories, adapters, redundant services, and all the rest of the fluff.

YOU ARE WRITING COMPLEX CODE. Not because nobody can understand it (including yourself), but because that code is simply monstrous overhead in resources and development time. In the average startup written by young developers, you can quietly delete 50% of the code and the servers will heave a sigh of relief, fans whirring. And half the team could be let go, because there'd be no need to spend time maintaining clever constructions that nobody uses.

LESS CODE — FEWER BUGS. Large projects can be roughly estimated just by looking at the average number of errors per thousand lines of code. If you have, say, 2 bugs per 1,000 lines and the project has 1,000,000 lines — you probably have 2,000 bugs. Get it? Now look at your own code. You most likely have 10 errors per 100 lines. Your over-engineered code only adds bugs and makes debugging even harder.

DON'T SOLVE PROBLEMS THAT DON'T EXIST! You don't need to build out polymorphism scaffolding "just in case" or "it might come in handy someday." You don't need to immediately embed a microservice/service/or-whatever-other-trendy architecture just because maybe in five years you'll have a million users online. You have no idea how long your application will live. It might die in three months — precisely because of all this architecture. Because you'd have to hire a whole battalion of DevOps engineers to configure it all, and there simply won't be enough money. Or in a month it might turn out that the services were SUDDENLY split up wrong.

Remember this: WHEN THE TIME COMES, DOING IT DIFFERENTLY WILL BE IMPOSSIBLE. It may sound dumb, but that's the truth. Whoever actually needs to make your code more complex will do it — maybe that'll even be you. But for now, your job is to write your piece so it can be read, understood, and modified in five minutes. If you can't fix a simple three-line change in five minutes, you've clearly taken a wrong turn somewhere.

You'll get coated in code stylers, hang a bunch of hooks on everything — and then spend an entire day fixing three lines. There has to be some sensible limit. In that time you could have done something genuinely useful. Have you ever stopped to wonder:

• Will your code styler, and the 500 GitHub webhooks that have to pass, bring a single new user to the app? Or increase its value?
• No.

I've also started hearing the phrase: "I don't know." What is that? Production is down for two hours — "I don't know what happened, I looked around, couldn't find anything..." Sure, complex bugs happen — memory leaks, bugs that need 500 steps to reproduce, typos with global variables. Those are bad, but at least it's understandable why they're hard to track down. But if you yourself wrote some half-blog, half-social-network, your own beloved crypto exchange or whatever else — and you can't figure out which part of the code could take down half of your own application, then I'm sorry... sit in the corner and think about what you've done. And you know why? Because again: 500 different patterns, 20 layers of abstraction, DI on top of DI, a factory of factories, and some kind of ManagerManager. That doesn't help. It's like an obnoxious high-frequency background hum — annoying, distracting, preventing all work.

It's understandable that everyone wants to be an experimenter and do better than everyone else. Especially when there's no punishment for it and the money keeps coming in as before. You can endlessly test various "hypotheses" and invent "ideal architectures" in apps with a couple of pages. The money will be there for it. It's a stalemate situation. You can't blame the clients who commissioned the development — they're not technically competent enough to identify the problem if you don't explicitly tell them about it. You can't blame the developers either, because they themselves don't know what they're doing, but they mean well.

But there's one thing: self-respect. You don't want to walk into a clinic and have the doctor use you as a test subject for different medications, do you? Or have a taxi driver take you home not by the straight road but through some forest, charging ten times the price? Or maybe, so the pilots don't get bored, they start doing barrel rolls at altitude — just for fun?

Understand, friend: the point isn't your beautiful architecture or what the correct approach is supposed to be. The point is whether this brings any actual value right now. Much of what's written online is intended for hyper-performant systems or comes from very large companies whose applications run in their own data centers. Your application will most likely never come anywhere near that scale. So unless you're inventing a new video compression algorithm, streaming video to the entire world, or building a new operating system — don't make life harder for yourself and everyone else.