A recent comment on the blog had me start to implement a Formatter for the Android HackerNews app.
I did work on it and realized quickly that I had no idea what I was doing. Not that I can't code (ehhhh...); I had no requirements driving it.
I was putting in a pattern for the sake of using a pattern. This emphasized to me the need to have a requirement driving the design.
This is the XP practice of EmergentDesign/EvolutionaryArchitecture. I've just found this true for personal/research projects as well. Which I knew; but it's nice to have these kinda things reinforced.
It's a wonderful result from working on a post.
I'm doing these posts to learn. A negative result is a result you can learn from; I've learned; it's a success.
This negative result is showing the struggle that exists when trying to implement functionality/behavior without having a requirement that's going to be using the implementation. I have no requirement showing why I need to refactor from the current implementation.
If I pushed forward and did an implementation; I could cinsider it a fantastic implementation. A master piece of Object Oriented Design to amaze for ages!!!
But... I don't know if it will work for what I need when I actually know what is needed.
Which means it's a crappy implementation.
You can't have a fantastic implementation that doesn't fit the requirements. With no requirements; there are only bad implementations. It's instantly crap code.
This is a strong argument, to me, for waiting until the Last Responsible Moment for implementing. At that point you'll have the most information available and can produce the best implementation... for the current requirements.
Anyway - Have a short out of cycle post. :)