I actually have customers on that product. But they're unfocused and unrelated. How do you add features when the customer needs aren't clear? You don't. You just kill it.
"Actual customers" is about as overloaded as "talking."
You need people you can connect with, provide value to, extract value from - and you have to make all that into a reproducible and reasonably predictable process given all of the constraints in play.
If you can do that, you're often well down the path towards a viable business. If not ...
This is why I made the point about killing my other "product". I had nowhere to go with it. Perhaps I didn't say it well enough, but my initial plan was to build something but the problem wasn't marketing, it was that nobody wanted it.
My book, however, people want. I looked for what developers need first and then built a product around that, rather than thinking of something that might be nice and try to get people to buy it (like my CMS hosting).
Less than an hour of billing and they've got new techniques and better understanding of application architecture. It's also the answer to life the universe and everything.
This is a really good question. I actually avoided recording this because I didn't want to depress myself during the writing. I spent a LOT of time on this.
It does, however, come from real-world work. My client projects have been successful from techniques in the book.
I'd need to split hairs to determine what time was spent where and in the end I just needed to write.
It's the same problem with choosing a ebook platform. No tool does you any good until you are actually using it. I'm currently writing in Apple's Pages app because it was the nearest and easiest way to just get started.
The benefit of a product is that it can become many things and the hours put into it can be easily won back with more sales.
Thanks for clarifying. I had most of it written before posting and had forgotten the code samples. My copy of Design Patterns is packed up for a move. I've update it to refer to C++.
Actually, people have visited, but few have stayed to read. My goal is to clarify the concept. I did plenty of research before writing this including asking Lieberman and others about it. I first wondered how everyone's notion could be wrong and doubted that my understanding was correct.
Clarifying the underlying concept is great. Self-style delegation gets to the heart of why "this" is dynamically bound in JavaScript, which is one of the language's most confusing features. Self-style delegation is also just generally cool and more people should know about it.
At the same time, getting hung up on terminology and trying to mandate a definition that goes against current usage just because it's older is a fool's errand and doesn't help.
Language is a social construct. It's very important for us to have consensus and agree on what words mean so that we can communicate efficiently. At the same time, there's nothing wrong about having definitions change over time.
"Car" used to mean a two-wheeled Celtic war chariot. It wouldn't be helpful to insist that it still mean that, and it's just mean to proclaim that everyone who uses "car" to mean "automobile" is wrong and doesn't understand the idea of war chariots.
If you agree with munificent, then perhaps you could soften your title and introduction to say that many people confuse what the GoF meant, not that the GoF are wrong.
