The point is that it solves the problem, and it solves it in a way that you believe to be the right/best/highest-quality way. It may be a spike, a prototype, or it may even it a finished product. Something that you believe is already the simplest solution. Not just any attempt it has to be a good attempt. Implement your first solution to the problem. Sure it is, but to do it systematically requires the following steps. Revisiting is going back over an implementation of a working feature in order to try to improve it. This concept may be blindingly obvious to you, but I’ve always found it helpful to be explicit about process details like this. The benefit of doing so is to make sure that we’re doing it properly, and to ensure that our teammates are all on the same page. The difference is that when we systematically revisit, just like when we systematically refactor, we break down an obvious idea into delicious, bitesize chunks of process.

It’s a little bit like when you’re taught at school to double-check your work, or read over your essay at least once before you hand it in.

You probably have a good idea of what revisiting means already. ‘Revisiting’, like refactoring, has a specific meaning and process behind it, which I’ll explain. That method is the simple act of revisiting your work. It works equally well for novices and for even the most experienced programmers. Want to write the better code? Here’s a simple technique that programmers of all levels can apply.

Code writing software