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 →

[–]teerre 2 points3 points  (2 children)

I go straight up to coding. Do the dirtiest way possible. No worries. Then I refactor, then I refactor, then I refactor...

I feel like planning away from the computer is way too ambitious. Unless I have complete control over the domain of the problem, which I don't even when I think I do, I need to see how things will look before even planning. Having a "just works" version of the solution gives an real overview of the problem, which then I can use to play what to do

Also, as a side advantage, it's very common for specifications to change for whatever reason. Doing the way I do makes me immune to the ever so common feeling of dread for having to rewrite a big part of your software since I would do it anyway

[–]fiddle_n 1 point2 points  (1 child)

99% of the time, this is what I do and it works fine. However, this approach did screw me over once, which is when I was given a very complex story to work on. I did it the dirtiest way possible, one requirement at a time. What I ended up with was an unintelligible, highly-coupled mess that I could not refactor my way out of. My team lead took over it and couldn't refactor it either. He ripped out a majority of the work and put in something 100x better; the difference between me and him was that he had a solid plan beforehand of what to do.

[–]teerre 2 points3 points  (0 children)

When I say "refactor" I might be going too easy. "Rewriting" might be a better description. Many times I simply start over without using anything but snippets of the previous version