The 3 Topics Business Doesn’t Care About But You Should As A Software Engineer And How To Create Time For Healthy Code

Stop making excuses for these 3 topics and start creating the time to achieve healthy code.

I heard this sentence so many times.

As software engineers, we always run against time constraints. We need to deliver new features while fixing those nasty bugs in production. We always feel the pressure from the business.

Working in a startup makes the pressure even worse.

Startups need to prove their idea. So, founders, most of the time, take shortcuts to implement an MVP and test it with users. This approach is correct.

As a startup founder, you need to test your idea as quickly as possible.

The result of it, sometimes, is a ball of mud. There are no design patterns and no modularity. It's just some code glued together and very hard to change.

But it works, and you can test it with real users.

Investors might become interested in your project. So you can raise capital to start your company. It is now time to create an engineering team.

When engineers get hired in a new company, it begins:

1. Testing

Testing is the number one issue engineers don’t have time for.

The business doesn’t want tested code. They want working code with no bugs. They need new features as fast as possible, and testing sounds like unnecessary code.

We, as engineers, want tests.

Tests are a necessary tool to ensure our code works as expected. When changing the implementation of a well-tested function, we have the test ensure that its behavior remains the same. We can also use tests as a tool to write better code.

So, how can we write tests if the business doesn’t give us the time to do that?

2. Software Updates

Node 16 is not maintained anymore, and we need to update it!

The business doesn’t want updated dependencies. They want working code with no bugs and no vulnerabilities. They need new features as fast as possible, and updating code that is already working sounds like a waste of time.

We, as engineers, want our dependencies to be up-to-date.

We know that updating dependencies is a crucial part of our job. Security should not be left behind; it is a high-priority issue. We also know that the more we wait to update our code, the harder it becomes.

So, how can we update our code if the business doesn’t give us the time to do that?

3. Refactoring

Refactoring is probably the hardest thing to explain to the business.

They don’t want well-structured and readable code. They want working and code with no bugs and no vulnerabilities, and that is easy to change in the future. Why should you change working code without adding new functionalities to it?

We, as engineers, want our code to be healthy.

We know how hard it is to work on a legacy codebase. Adding a label might take two days because the code is hard to read and change. Taking shortcuts could be a good idea initially, but it might become a source of problems in the future.

So, how can we write healthy code and refactor the old one if the business doesn’t give us the time to do that?

The Engineering Team's Responsibilities

Testing, software updates, and refactoring are the engineering team’s responsibilities.

The business has other responsibilities. They don’t come to the engineers asking for time to change something in their process. But, as part of the company, I expect the company to have enough money to pay my salary.

We don’t have time for sales this month, so no salary.

Can you imagine that?

Every part of a company has its duties. Engineers should take their responsibilities like any other part of the organization. It is our duty, as engineers, to write tests and keep our product free from vulnerabilities.

So, if it is engineering’s responsibility, how can we find time for engineering stuff?

1. Testing: Definition of Done

Establish a clear Definition of Done for your stories and share it with the business.

A DoD is a checklist containing all the steps required for a story to be considered completed. The story cannot be marked as completed if the functionality doesn't satisfy all the requirements. Add testing to your DoD.

Adding tests must be a requirement to consider a story completed.

2. Software Updates: Schedule Updates

Some software updates can be scheduled in advance.

Node, for example, has a page with its releases, and you can plan the update months before it is necessary. Explain it to the business and prepare a plan for updates together. Ensure that you do not skip it when the time comes.

When new vulnerabilities are discovered, update with the highest priority.

You, as engineers, are in charge of doing that and explaining the necessity to the business. Explain the risks clearly. Execute what is necessary immediately, then return to the planned work.

Update your dependencies regularly and include the business in the decision.

3. Refactoring: Estimation

When estimating work, consider the code status and change your estimates accordingly.

If you establish you need to refactor a module before you can implement a new functionality, include that refactoring in the estimate. Sometimes, we, as engineers, estimate the implementation of the functionality and give expectations to the business we can’t respect. Please, don’t do that.

If you have unknowns, tell them.

Discovery is part of the work. You don’t know what you don’t know, so clarify that you need to investigate before giving a proper estimation. If you discover bad code, increase your estimates.

Raise your hand as soon as possible if you find your estimation wasn’t correct.

---

Read Next: