Part 1: Development Overhead

Writing code is just a small part of what an engineer does on a day-to-day basis. However, all of the other activities an engineer does are really the cost of doing business when working on engineering projects. Aside from writing (and debugging) code there are obvious communication requirements such as calls and emails that are needed, at the minimum, in order to discuss project requirements and expectations. More often than not project management rituals are involved (Agile), or some sort of ticketing system like JIRA.

The less time engineers need to spend on communication the more they can, well, engineer. But communication is not the only other activity that slows the pace of feature development and absorbs value development hours. Testing, architecture, documentation and code reviews could all be considered secondary activities that require engineering time. These are all done under the assumption and presupposition of a positive ROI on these activities. These common practices, in theory, increase the code quality and reliability of a project, enough to warrant the extra investment.

The purpose of this article is to dive a little deeper into the common 'secondary' practices of software engineering, and propose ways to optimize these practices in order to maximize writing code, which should be the primary measure businesses use to gauge how effectively engineers are being managed.

A good analogy to keep in mind during this series is billing and administration in the healthcare industry. If doctors had to manage all of the billing, scheduling and other work that administrators and nurses do then they'd have very little time to see actual patients, which is what they are actually trained for and are experts in. Delegating these other tasks to staff members frees up the doctors time to focus on the most important stuff. The same approach should be taken with engineers, as they have highly specialized skills that are typically expensive to hire for, and a lot of the other tasks they are typically given can be handled more efficiently by others.

Communication

Communication can be tough. Communication of highly complex and abstract ideas across technical and non-technical disciplines can be really tough. Add a second language or a challenging personality and now it's easy to understand why in tech so many projects suffer from miscommunication. Companies spend significant time and energy trying to streamline communication with significant documentation and business processes, or invest in software to fill the gap or automate this communication.

Regardless of the solution the goal remains the same; the business side needs to be able to communicate with the tech side, and vice-versa. Engineers need to understand the business, its goals and their role, but also need to be able to communicate with stakeholders in a relatable way. The business needs to be able to refine its long-term goals and visions into hyper-focused, 1-2 week goals, but are also reliant on engineers to accurately scope and estimate the work.

The question, however, is how to strike the balance between complete chaos and bloated, corporate red tape? Too much process and you spend significant resources talking about and describing work rather than doing it, and not enough and you end up with an unplanned mess of work that doesn't accomplish business goals efficiently.

So how to balance the two? There's no simple answer, but it ultimately requires judgment rather than best practices. Too often teams buy into agile too soon or when it's not needed, potentially adding unnecessary overhead to the team. What's worse is when a team is missing some of the key pieces of agile but are still limping along with it anyway.

When agile works well it can work really well, and that's typically for large, well-established companies that are designed to move slowly and preserve market share. The single biggest advantage startups have over their biggest competitors, however, is the ability to move quickly and adapt, largely due to the bureaucratic red tape a large corporation is strategically handcuffed by.

The business stakeholders of a startup really need to understand the hidden costs of their engineering departments, some caused by the business side and some self-inflicted, in order to maintain true agility and adaptability, which is their single biggest advantage over the competition. In a nutshell, if an engineer isn't writing or debugging code then it's probably slowing innovation while still costing you money.

Technical

Aside from communication, engineers spend a great deal of their time, potentially even more time than they spend writing code, on testing, architecture, technical documentation and discussion. These are all valuable activities that help teams to be more effective. It's like being an athlete and eating a healthy diet. Sure, if you're talented enough and work out hard enough you can still be elite, but eating healthy can get you to that level easier and also raise your ceiling of potential.

The point remains the same, however, that all of these activities are done with the intent that over the long term they provide more value than the upfront cost. Whether that is true or not really depends on the project, team and decisions that were made. For example, a high priority of code coverage may be ambitious and admirable BUT what if it's at the expense of architecture, and the code being tested was not written well in the first place, so you're in effect just testing bad code? Or what if your business identifies a new business opportunity that requires a massive rewrite of large portions of the code? Now you lose a significant amount of those tests in addition to the code, and then need to write the new features as well as the new tests, doubling the entire effort.

The point is not to say these activities are bad or that you shouldn't do them, it's more to bring to light the fact that these are assumed in a lot of tech teams to be what you're supposed to do, without any thought or consideration to whether it is appropriate based on the business goals. More often than not testing, documentation and architecture are all important, but how much or how little and when is the question, especially when resources are limited.

The rest of this series goes into depth on identifying the cost & benefit of the different types of testing in the software world, and a recommended approach for dealing with testing, architecture and process in a startup.