8 questions to ask yourself before diving into a new task

Most of the researches regarding the cost of software errors, show that there is an order of magnitude difference between the stages, where the error is found. That’s why it’s essential to take your time during the planning and prepare a detailed implementation plan for the more complex tasks. I created a personal checklist, which I use before starting a new task. Some of the steps may seem rather obvious, but it’s always worth to keep them in mind. Let’s grab a cup of coffee and enjoy the lecture :).

1. Do you really understand the problem?

First, check if you really understand what’s the task is about. I find it more efficient to try to explain it to somebody else, as it lets me immediately find most of the inconsistencies as I follow along. Try to shift perspectives a few times and check if it makes sense not only from the business point of view but also the users’. What about performance? Maybe you can come up with something more suited?

2. What are the possible side effects?

Before making any changes to the current code base, check in what other parts of the system the feature you’re working on is used. In a highly coupled legacy code, you can be almost certain that making a small change on the one side will resonate to the other, making a picturesque example of the butterfly effect. The more tightly coupled the system is, the bigger the impact it’s going to have on the estimate.

3. Isn’t it opposed to some already existing business logic?

Before starting implementation, it’s worth asking if the business rules included in the topic don’t contradict what’s already defined in the system. I agree this should be checked by the product owner, however often it turns out that actually, developers know more about the business logic than managers or analysts. In the end, it’s devs who dive into the design and check the functionality’s interiors.

4. Was it solved by anyone already?

In atomic team infrastructure, it might happen that the problem you’re trying to solve was solved already. It’s always worth asking for guidance. Especially, when the codebase is several million lines long, and nobody is really aware of what’s under the hood of the steaming engine.

5. Is there a standardized open source solution?

Chances are that if you’re not Linus Torvalds, an open source library will be more reliable than anything you can come up within a few days. Many developers tend to fixate trying to have “full control” of the application and reject any external dependencies, but not only a library can save time on development, but it can also cut the cost of maintenance. Just delegate any bugs you find to the library maintainer. Profit. If the open source project is no longer maintained, you probably shouldn’t use it.

6. What are the three ways to achieve it?

Think of three methods using which the task can be achieved and about their bright and dark sides. Try thinking about a temporary dirty solution, a one with good architecture and maybe a totally different approach like moving some of the logic to the DB procedures or utilizing external services. This way you’ll be able to provide different estimates, prove you understand the logic pretty well and can be flexible in delivering the result.

7. Is it unit tested?

In case you’re dealing with a bug, check if there are any unit/integration tests written for it. It makes things a lot easier as you can use them as a reference to see if your changes didn’t break anything. On the other hand, in case your changes will modify the logic, probably you’ll need to update some of them. Include that in your estimate. 

8. Can you make it on time?

Lastly, chances are that answering above questions impacted your estimate. Judge if you can make on time, including some tests and discuss it with your lead. Maybe it turns out it’s worth to split it into smaller tasks.