DEV Community

Discussion on: Don't be a Shotgun Coder

Collapse
 
joshcheek profile image
Josh Cheek • Edited

Both approaches have merit, choosing the wrong one is painful in either direction.

Would you rather take two weeks designing something, and a week to build it, OR would you want to immediately start building it, only to realize you didn't understand the big picture, all the features, or exactly what the end goal was?

Understanding the big picture is very important. But that's not a programming activity, that's learning what your stakeholders care about. It's not even requirements gathering, requirements are implementation details that exist because someone thinks it will achieve a goal. Knowing the goal is important, creating a plan to achieve the goal can be useful, but can also be counterproductive.

I've seen many many times that planning takes overwhelmingly longer than jumping in because you don't know what's best until you get there. In its most malignant form, you don't solve the problem, but you commit to a bunch of decisions. Then, when you get there, the pieces aren't fitting, your understanding of the problem has changed. And as you look at the plan you made for the future, it's going full tilt into the problems instead of adjusting course.

It's generally better to invest in low coupling, low commitment, fast iteration time. Write your code so it's easy to change and so you can delete with as much ease as you can add. Hell, you could even spend that first week implementing shitty prototypes and then spend that second week planning based on what you learned in the first week. I'd expect that to be much more effective.

Anyway, planning is right for some problems, so it's good to have that in your tool chest, but it's an absolute mistake to apply that tool to every problem you have. Especially within the domain of programming where planning and its cronies have such a consistently bad track record that manifestos are written to defang it.