Photo by Maxwell Nelson on Unsplash

A helpful guide on project planning in software development

Let’s say you’re working at a company. You just started there or you are a long time employee. You get assigned a new ticket or a project to work on.

What now? What are the next steps?

Probably like most people getting assigned a project or a ticket who are unfamiliar with project planning and the importance of it. You want to immediately dive into the code, because you’ve already thought of the perfect solution in your head.

Well… hold on a second and let’s give it some more thought.

I can’t blame you, It’s exactly how I first responded to new ideas or tickets. You just can’t wait to dive into the good stuff. But in this article I will explain why that’s probably not the best way to go and how you should approach a new project or ticket!

What are we going to talk about today?

  1. The why. Why is it important to carefully plan a project
  2. Should and should nots
  3. Get your plan reviewed
  4. Helpful techniques I use

1) Why is it important to carefully plan a project

Let me give you an example first:

Jimmy is working at a company and he gets assigned a project to work on. Jimmy starts reading the description of the project and the problem he needs to solve.

Jimmy is starting to think of a solution as he is reading the description of the project. When finished reading he can’t wait to start implementing the solution and immediately opens his IDE to start coding.

A couple of hours later Jimmy has implemented his solution and is ready to push the code and open a Pull Request to let it be reviewed by his fellow engineers.

When the engineers review his solution Jimmy gets asked a lot of questions.

  • Did he think of several edge cases?
  • Why did we go with this solution? Are there any other solutions?
  • What are the disadvantages of going with this solution?
  • What are the benefits of going with this solution?

Jimmy doesn’t really have the answers to these questions, because he did not really plan his solution that he just implemented.

Even worse would be if these “Edge cases” are not found in the code review and get pushed to production. Which can cause bugs which could’ve easily been avoided if we planned the project more carefully.

  • We can discover and catch certain edge cases in a potential solution.
  • We can discuss and discover different approaches / solutions to the same problem
  • We can discuss the pros and cons of each solution

In addition to the points above. We also win time in the engineering team and avoid unnecessary communication about things that can already be thought of and discussed before we start the project.

2) Should and Should nots

We have already touched on this subject a little bit in the last point. But what you should avoid is immediately jumping into your IDE to start coding.

Another thing to keep in mind when planning your project before implementing it, is the solution / solutions you think of.

It’s often tempting to make the first solution you think of the solution you also want to implement. However before doing so, stop yourself and ask yourself the question:

Are there any other ways I can solve this problem which differ from this one?

Often times you can come up with 1 or 2 different solutions to the same problem!

Keep in mind to not build your second solution around the first solution. It’s tempting to look at your first solution and think “What is a different way I can implement this solution?” But what you are essentially doing here is not thinking of a second solution, but more a second version of your first solution. And we don’t want that.

Make sure to look at your problem and really find different viewpoints / solutions framed around the problem and not the first solution.

Why is it useful to do this?

By challenging yourself to take different viewpoints against the problem you are trying to solve you can also discover easier or more simplistic ways of solving the problem.

Which in turn causes the code-base to be more simplistic, readable and scalable.

3) Get your plan reviewed

After you have carefully constructed your plan on how you want to approach the problem, the goal of the problem and the context around the problem.
It’s a good practice to let this plan first be reviewed by your fellow engineers to see if they have any feedback points or think of certain points differently.

Make sure before presenting your plan to your teammates to include different options / solutions to an approach you considered and the pros and cons of those solutions.

it’s helpful for your the engineers to see what your thought process was and why you went ahead with a certain solution to prevent duplicate options to be presented.

4) Helpful techniques I use

What do I do when I get assigned a new project?

I start by reading and understanding the project description and the outline of the problem I need to solve.

I do this by writing a couple thing down in my notebook with pen and paper:

  • Context of the project and problem
  • Potential first approach
  • Edge cases

After I did this I might have stumbled upon some questions I would like the answers from to continue with my plan. So I ask the questions to the person who is most relevant for this project.

When I have all the answers on my questions and everything is written down in my notebook, I create a well structured PDF file that outlines the goal of the project, the context of the project, the steps of implementation and the approach with different options and their pros and cons.

Once this plan is created according to the points I mentioned earlier in the article. I ask my fellow engineers to review the plan to see if they can find anything I missed or perhaps have a different way of solving this problem.

When I have a complete project plan and added the feedback points my teammates suggested. I break down the project into smaller, more manageable tickets to work on.

Why do I do this?

By breaking the project down into smaller tickets you create a better overview for yourself, and you make the Pull Requests your teammates have to review easier to review.

You also reduce the chance of unforeseen bugs getting merged to production. And even if they do get merged it’s easier to revert a small Pull Request than to revert a huge one.

Conclusion:

Look at project planning for a software project as making blueprints and plans to build a house. We need a good foundation and plan as to how to build the house to also discover where certain walls need to placed and where not.

If we start building the house before planning it, and we discover that a wall needs to be broken down when it’s already there. It takes much more time, effort and money to do this…

So remember. The next time you get assigned a project. Stop for a minute, think it through, create a plan and then start building.

Tech enthusiast working in the Back-end (Node.js) most of the time. Life long learner and eager to share knowledge I obtain!