Abstract enough

Posted on Oct 6, 2015 in and tagged

Programmers tend to think there is something special about them.

However, a vast amount of IT jobs out there is mostly about business automation and solving auxiliary tasks, with client software being just a tool to help specialists do their real-world jobs—track the state of component research and development, automate status reporting, control the operating hardware mechanism. The so called "business logic" of your product is probably just a bloated mess on top of the huge state machine. If you ever put some "entities" in the database, then you are probably building a state machine, with the only varying parameter being its size and the number of moving parts.

But it seems that building "state machine"-ish entity manipulation applications (CRUD, anyone?) is kind of an already researched area with a long history. Of course every product is different, but what I’m trying to say here is that there is a high chance that you actually don’t need that many concepts and high-level abstractions to make your product happen.

What’s more likely is that you will face three types of challenges:

  • How can I make my data manipulation fit into the resource constraints, like time, storage, memory, latency, etc.?
  • How can I make the product to be easy to change and adapt to the new requirements? I’d say that the task of ensuring that newcomers can easily grab the project’s source code base and get familiar with it falls in this category as well, because if the code and architecture is easy to grasp, then there is a high chance that it will be easy to modify as well.
  • How can I achieve the highest possible correctness? I want the product to be stable and have no errors whatsoever.

The first point (resource constraints) doesn’t favor the high abstractions that much. Another level of indirection is probably going to add up some overhead on top of your existing resource consumption.

The second one also doesn’t play well. If your codebase is bursting with obscure category theory concepts or academic constructs, don’t expect the newcomers to get acquainted with your product internals fast enough. Even the functional programming, being all the hype for the last several years, is still unknown to the masses, despite what your Twitter feed tells you (remember, you choose what to read and who to follow, don’t make a mistake of assuming that everyone else out there is somehow similar).

That brings us to the latter point about correctness. Academic background keeps telling us that higher-level abstractions from category theory, type systems, language and computation research, and other fascinating CS branches, shall help us achieve the extraordinary correctness levels, but I’m not convinced yet. They are definitely helpful, to some extent, but I don’t sense any industry-level revolution out there. The basic functional(-ish) programming concepts we see finding its ways into the mainstream languages and platforms these days is a nice touch, but it hardly revolutionizes the quality of business products.

So do you actually need to care about your abstractness level? Should you study your profunctors and coalgebras to build a successful product? As with many other things, "abstract enough" is good to go. I’d say it’s important to remember that the fact that you can do something doesn’t necessarily mean you should do that. It’s always helpful to know what’s out there and what you can use when you find a specific task that your solution works best for. In the end of the day, your fellow colleague developer would likely appreciate a readable and understandable code much more than the "smart" one.

Your code sucks

Posted on Mar 17, 2014 in and tagged

So you are sitting at your desk wondering how come your beautifully- and carefully-thought abstractions have turned into an ugly monster, and why your precious codebase smells like a giant mess. You may be not the smartest guy around but you are not that stupid or unqualified after all.

Well, just accept that your code sucks and stop worrying about it. Even the most brilliant programmers I know come up with the messy code or leaky abstractions sometimes. To fail is human. The business requirements come and go, the product evolves, you are growing as a professional. Don’t be OK with it, just stop torturing yourself trying to find the 100% perfect solution. If it works for now and it looks easy enough to be changed later, then it’s probably fine. On a side note, I would rather wonder why you are OK with any code at all. If you can’t spot an issue here or there then you are probably just not skilled enough to see the defects.

I’m not talking about some ‘forget the code, WE ARE SHIPPING THE PRODUCT HERE, BEATCH!’ management bullshit. The beautiful code and design is what makes your product easy to maintain and improve in the long run. The more skilled and experienced you become, the more likely you are to fall into “disappointed in everything” mental trap. Try to think about it rationally – you’ve been around for quite some time, you’ve built some great stuff, your projects haven’t fallen apart due to awful technical decisions. And though your code sucks from your point of view, perhaps it’s not that bad on the absolute scale of code awesomeness.

What can we do make it less painful? Code review really helps a lot. Some developers complain about code review not being effective enough, i.e. it only helps you find the most basic formatting and code issues. I was a bit skeptical myself not so long time ago, but even if it helps to fix the formatting and minor code issues, than it’s a great improvement! I would say it’s a matter of trying and figuring out for yourself. From my experience, early code reviews help to avoid possible design pitfalls, for example when a developer have not thought about a specific usecase of the module he is working on. What’s even more important is knowledge sharing. Two heads holding the feature implementation details are definitely better than a single one (you never know, that lonely developer working on the sophisticated data processing logic may get hit by an asteroid the next day).

Try and fail, learn from your experience. Reading books on code quality doesn’t help. Unless you’ve suffered from the fucked up design or messed up code you won’t understand why it’s important to think about future-self supporting the codebase.

The code sucks. Repeating this statement makes no sense. What does matter is understanding why it sucks, accepting the tradeoffs and constantly thinking about the ways to improve it.