Software development is not about coding. Code is only the way we communicate our intentions to the scrap box under our desk. Software development is about thinking and finding simple solutions to complex problems. We all know this. But also very often we forget it.
The wrongest thing you can do is to start coding right after you got a task. It is scary how many people do precisely that. Of course, I don’t mean simple tasks like adding an extra field to a form.
In this article, I will share with you how I approach and plan my development tasks.
Software development and critical thinking
Before going into any technicalities, you should analyze customer specifications in great detail. Don’t just read what it says. Try to see if does it make sense (many times does not). Does it contradict itself? Is it logically complete?
Often there are gaps that developers and business people see only after the implementation is in the advanced stage. Try to catch these gaps.
You should always apply critical thinking. Don’t be only a reader; be a critic. Focus not only on what is written but also what is missing.
Software development and walking
After I have understood the idea behind the requirements, I try to visualize what I have to do. I still don’t write any code.
Often I walk in a circle and think (I am using a wheelchair, so my walking is like NASCAR, but… slow 😊). Yeah, just like a crazy guy walking and talking to himself.
Also, I am taking notes. I don’t structure them in a specific way. I am just writing down things that I should have in mind during development.
It is essential not to accept the first solution that comes to your mind. Try to find a better one, or even several solutions. Examine them through the prism of your requirements and only after then choose the most fitting one.
Many developers jump right to coding after finding a way to implement their tasks. That is wrong. Extremely rarely, the first solution that comes to mind is the best and most optimal one.
Pen and paper
After I have got the big picture and a working solution (in my head), I sit and write down an execution plan. I try to split my work into several logical parts. For each part, I have a single A4 size sheet. On the sheet, I write a list of things I should implement.
For example:
Sheet 1:
Implement the integration service with APP X (Part 1)
- Implement remote API access configuration;
- Implement required DTOs need for communication;
- Implement an API wrapper;
- Create database tables for the extracted data;
- Implement a specific repository for persisting the extracted data;
- Write unit tests;
- Test manually;
- …
Sheet 2:
Implement the usage of extracted data in documents (Part 2)
- Add method X to repository Y to extract the needed data;
- Add method Z to repository T to extract the other needed data;
- Change the current model for the desired documents;
- Implement a service to handle the new business logic;
- …
- Test the full implementation;
- …
Most of the time, I end up in up to 3-4 sheets with technical tasks.
I also put aside another clean sheet if anything unpredicted occurs (to write it down and later discuss it with the business people.)
If I am not much into programming that day (yeah, there are such days), my first tasks are very simple. Like “Create new branch”, “Delete already not needed code”, etc. The idea behind starting with such tasks is to gain momentum.
Of course, you always start with sheet one, and when you have all the items strikethrough, you continue with the next one.
Rationalization
As I said earlier, that approach is total overkill for a simple task. But if you have a bigger one, this is something that can help you tremendously.
We all know the saying, “How do you eat a whale? Bite by bite”.
Why do I use a pen and paper?
I love the feeling when I strikethrough the items. It gives me a great sense of progression.
