133 likes
·
1.1K reads
9 comments
I too know of people who love to just dive straight into writing code, but I completely agree that at least some form of planning upfront is worth it.
It’s very much like writing unit tests: by writing them, it makes us think in different ways that the system could operate. As a result, we might include additional handling for different use cases that we may not have otherwise thought of. The same is true with a project plan too.
When it comes to system design, I also think it’s helpful to draw up some diagrams. Architectural diagrams help with design and modularisation, and sequence diagrams can show how the systems will communicate with each other.
Once we have those, we have a clear direction and (as mentioned in the article) can move much faster as a result.
I too know of people who love to just dive straight into writing code, but I completely agree that at least some form of planning upfront is worth it.
Definitely agree planning is needed. I love technical plans. Even for solo projects, I forget most of what I was doing, so to be able to read through them and get an understanding of the solution and design is invaluable for my future self :)
For me, I must admit that the fine balance is how much is too much or too little.
Too much planning can be costly because you can spend so much time planning, only to realise the plan is too rigid and you have to deviate from it. So I totally agree, focusing on the problem first and then overall design helps to prevent going into the implementation too much beyond the architecture.
Too little planning has been so costly, especially with a team - it's hard for everyone to move forward at pace with no vision to follow. 100 agree.
So I love planning up front, but I've learned I need to not go too far with it. I should incorporate more sequence diagrams into my plans though.
Gemma Black Yes, you're right. Much like everything else in software development, how much to plan is a delicate balancing act.
It's a bit like writing tests. Too little and making changes becomes scary as there's no safety net; too much and it takes too long and makes requirements changes painful.
I think the more we collectively do, the better we are to judge where the optimum point is.
Great post! As developers, we tend to miss this part because of time constraints. But I think it helps to slow down a little bit and do the tech planning first.
Thanks for writing this.
As a developer, I always thought that planning before executing is not worth of time- this always happened to me whenever I tried to go for implementation, and the results were always negative. Reading this blog changed my thinking pattern and helped in getting good output as success.
I used to think so too. I now think of it like this: a project will take a certain amount of time, e.g. 1 week. I can either:
- Spend a day upfront doing some planning, and then four days of implementing, or
- Jump straight in and start implementing. I'll finish in 3, but then spend a 2 or more days rearchitecting the solution, or rebuilding it because of misunderstandings in the original design and/or requirements.
It is a very important subject indeed, touching on this subject is essential especially for developers who work directly on highly complex products, planning will always be essential.
What planning tool do you prefer the most for mid level software projects? Clickup, Jira or Trello
I don't have a specific project management software I prefer. I've used many at various sized organizations, Asana, Jira, Trello, Linear, Bugzilla. My advice is to go with whatever works for your company (it might be what you already use), and don't fight against the way the tool wants to be used.