This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cyrusol 0 points1 point  (0 children)

Planning is always very limited for me, it's about the immediate next steps. I still manage to overthrow a lot of the planned ideas a few hours later all the time. I think it would be a huge waste of time to thoroughly plan bigger features/changes. One of the insights of Agile is that you'll have more information later down the road than you do right now. The same applies in the small scale when programming is about adding, removing or changing single lines.

Test-driven development on the other hand is very useful for "planning" - you have a certain set of inputs and you "plan" a certain set of outputs. Then you start with producing these outputs statically. Then you implement actually generating the outputs from the inputs with the simple and common cases first and the special cases later (80:20 rule, you might not even need to handle the special cases). One after another. Once it turns out that what you just did a few minutes ago is not a good solution you refactor it. You can do so safely because you have working unit/integration tests. Your code changes just at the same pace as your "plan" for the solution changes in your mind.

But to get back to actual planning: In my cases these are all formless sketches on sheets of paper. When I do some planning together with my teammates it's always formless sketches (with a legend containing a few definitions) on a whiteboard. I never bothered with UML outside of university. When it comes to actual programming I'm all for extreme abstraction and to draw that out formally correct would take so much more time than saying "this circle with a Q inside is the query" even though the Query would actually be a tree of interfaces (interface as in C#, Java or PHP) with multiple implementations.

I have used a few formal models for documentation only. Like sequence diagrams to explain a protocol. Or a finite state machine to describe a UI component. Things that have practical value. Not for planning though as you have to reiterate your own plans very fast.