I love the Harry Potter books. I thought they were well-written and cohesive. You may have read them too, and felt something similar. What you may not have done – and you can skip to the end otherwise – is read them back-to-back in a short timespan.
I’ve read all the books multiple times, and every time I’ve picked up something new. That’s a win, by any reasonable standard. After book seven came out and I read it, I decided to read all the books in a single extended session. The results were, frankly, remarkable. Plot lines and plot points made more sense and there was a complete feeling of a story that required seven books to cover as opposed to seven related books. The difference, when you’ve experienced it, is significant.
This is the point where I attempt to weave a personal life experience into general software engineering. Since this was a click event in my life, hopefully I can expand on it thoughtfully in such a way that allows me to cash in on it mercilessly.
Point the first: We have an idea and sketch out functionality and an API
Point the second: We expand that idea, and the API, in accordance with the improvements of point one.
Generally, in my experience, the next bit is where things really go to shit.
Point the third: We add more functionality, refactor the API completely (and rationally, according to the changes) and add things which we think are needed instead of what is wanted. We put perceived wants in place of planned needs.
And right there, things go wrong. If you have an idea, then not evolving it is a mistake. If you have evolved it, then pause a while. Let it stabilise. Change is good, but if you want to build a following – particularly one which requires a stable API – change must proceed according to what you want to achieve. Once you’re stabilised and are ready to expand your capabilities again, notify your consumers in ample time and go for it.
If you’re familiar with the the Potter books, you may see a similarity here. For example, book five got lambasted just because the principle characters were acting as they should have been at the age they were. Which is ridiculous, because otherwise they wouldn’t have been acting realistically. Just because they’re teenage witches and wizards doesn’t mean they’re not teenagers – they’re just teenagers who are witches and wizards. Comme çi, comme ça.
The point is, if you’re still reading at this point, is that J. K. Rowling clearly has a view on where she was going, and didn’t fuck up her API. She wrote according to her plan, and took the criticism as it came. The result speaks for itself.
If you want to create something, that’s amazing. If you want it to be useful, you have to listen to your users. But if you only listen to your users and forget what you wanted to do in the first place, then you’re designing by committee – and that’s guaranteed to give you the worst set of compromises you can imagine. If you’re going to build something, build it with an eye to making it useful – but keep your vision for it true.
Software people continually try to apply their practices to the general world, but it works both ways. In this case, not compromising worked for J. K. Rowling, and it’s a damn good lesson.