DEV Community

Jules Roadknight
Jules Roadknight

Posted on

Technical Debt in TicTacToe (Estimating 1.5)

Game's working pretty well, you can play a 3x3 and win, just need to start abstracting this single class into a few and...ah. That's not good.

Following on from my previous post about estimating, a good early lesson to learn has come up, namely 'plan early, abstract early, refactor early'. Not exactly a catchy acronym, but I've discovered how long it takes to separate basic functionality in a small TicTacToe game.

Tests suddenly indicate nothing, so if you went for functionality now and abstraction later, you're almost back at square one as far as test-driving goes. Trying to refactor small so that it still works also means that meaningful change and better design are harder.

The whole game was set back hours as working solutions were torn apart to become new problems, and while they are problems that can be solved with time, time is always the issue.

Lesson for the Future

Like I said; plan early, abstract early, refactor early. That way, if big changes happen, there are at least fewer of them.

Discussion (0)