Do you know how much time your developers spend on defensive engineering-related tasks? The odds are it’s way higher than expected, and it’s only increasing as their stacks get more complicated. Most engineers spend more than half of their day preparing and scheduling data for analysis, writing defensive code, anticipating failures, retrying these failures, and monitoring what went wrong. Why you don’t need to be Nostradamus of code to solve negative engineering.
Negative engineering
At Prefect, we call these tasks negative engineering. Negative engineering is defined as the effort engineers spend on tasks that take away from their primary job functions. Anecdotally, engineers have told us they spend up to 90 percent of their time on negative engineering-related processes. By reducing that number by 10 percent, engineers can theoretically double productivity and spend more time on positive engineering — the tasks they are hired to do and those that have a clear business objective.
Looking across the data landscape specifically, there is hardly any acknowledgment of the negative engineering problem. Most organizations have internalized the idea that these issues – by their very nature – are far too specific to their unique business practices to be solved by the industry at large. Moreover, it’s considered overhead; just the cost of doing business. Unless we acknowledge that negative engineering is not inevitable but just another problem that can be improved through software, it will only get worse.
Identifying Building Blocks
The complex nature of the modern tech stack is the perfect breeding ground for negative engineering. Organizations are constantly adding new extensions and services to their stack to simplify processes. However, each addition to the stack introduces new challenges and potential points of failure that engineers must prepare for, predict and defend against.
All of the tooling required to defend, detect and predict these issues is when negative engineering begins to rear its head. Many developers have built or adopted homegrown workflow management systems to automate specific and initially simple tasks to address these problems. But no one can predict everything. How can you expect what you’ve never encountered? You would need to own a crystal ball or be some sort of Codestradamus.
Rather than attempting to predict the unpredictable, one of the ways to tackle negative engineering is through careful and curated automation. While these problems are not always universal, at its core negative engineering is an information gathering process. There is tremendous value in finding a way to automate at least a portion of this detecting and information gathering to reduce the time spent on predicting failure modes on tedious and repetitive tasks.
The Importance of Insurance for Code
Consequently, the repetitive nature of these tasks means they fall through the sieve used to identify significant issues. But like anything else, they can add up and have an extraordinary impact on productivity.
The good news is that many data applications have similar building blocks and can be decomposed into a simple vocabulary. Meaning developers can address them by adopting an open source framework that defines and executes workflows on an engineer’s behalf. By focusing on these basic building blocks, engineers can reduce negative engineering through automation without sacrificing the power or sophistication the modern tech stack demands. Not to mention it gives developers time back in their day to focus on the things they like to do: write code that achieves objectives. So much can be said to solve negative engineering.
Acting as insurance for code, proper workflow management systems automatically enable best practices even for data applications these systems have never seen before. This allows workflow management to be minimally invasive when systems work as expected, and maximally beneficial when they do not. It also frees engineers from time spent retroactively fixing issues across the stack and gives them more time to build and scale more complex code without the fear of spending hours looking for a break in the chain. And if they must search for a break in the chain, the system is able to detect something is wrong even if it cannot be pinpointed.
It’s impossible to predict what has not been encountered previously, but that does not mean eliminating negative engineering is hopeless. There are a number of simple and daily tasks that could benefit from automation, and more importantly, make engineers’ lives easier. It starts with adopting a framework that is specific enough to be useful but generalized enough to robustly handle the unknown. It’s not a major feat to solve negative engineering.
