# Why Many Business Applications Need Fewer High-Level Abstractions

DevFeed: [Why Many Business Applications Need Fewer High-Level Abstractions](<https://devfeed.tech/articles/abstract-enough-38423.md>)

Original publisher: [Read original article](<https://khmylov.com/2015/10/abstract-enough/>)

Author: Andrew Khmylov

Published: 2015-10-06T00:00:00Z

Content type: opinion

Language: en

Sources: [Despite the odds](<https://devfeed.tech/sources/despite-the-odds.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [business logic](<https://devfeed.tech/topics/business-logic.md>), [CRUD](<https://devfeed.tech/topics/crud.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software](<https://devfeed.tech/topics/software.md>), [Database](<https://devfeed.tech/topics/database.md>), [Functional programming](<https://devfeed.tech/topics/functional-programming.md>), [Category Theory](<https://devfeed.tech/topics/category-theory.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [automation](<https://devfeed.tech/tags/automation.md>), [business-logic](<https://devfeed.tech/tags/business-logic.md>), [category-theory](<https://devfeed.tech/tags/category-theory.md>), [code](<https://devfeed.tech/tags/code.md>), [crud](<https://devfeed.tech/tags/crud.md>), [data](<https://devfeed.tech/tags/data.md>), [development](<https://devfeed.tech/tags/development.md>), [functional](<https://devfeed.tech/tags/functional.md>)

## AI overview

The article argues that many IT products are primarily business automation systems built around stateful data manipulation. It suggests that developers should focus on resource constraints, maintainability, and correctness instead of adding unnecessary high-level abstractions.

## Source excerpt

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