A lot of startups are afraid to tell you what they're doing. They're afraid someone'll steal their idea if it's good, they're afraid others'll criticize it if it's bad. Then they do it and you ask them about it. There they won't shut up about how they did it - geeking out on the asker with technical details: kernels, packets, bytes and pixels - things no one really cares about.
No one cares how you did it, but why did you do it? Why the hell did you spend so much time and effort to do such a thing? That's the problem.
Because they were worried about someone stealing their idea, they decided to keep it to themselves, shielding themselves from IP theft and more importantly, from someone asking them "why?" They only thought of the how. Some people love solving puzzles and when presented with the idea, they did not think "Why would anyone want this?" but instantly tried to solve the puzzle.
They did not empathize with the end-user, the customer - they do not see themselves as the customer, only as the puzzle-solver.
They believe in TDD, test-driven development, rather than dog-fooding, because the former is seen as a set of rules for solving the puzzle, making it more of a challenge, while the latter is making you use your own product - eating your own dog-food, which is not fun at all, considering how bad the product is.
There is this strange belief, as if a well-designed, well-architected, well-built and well-tested product that just happens to be useless is fundamentally better than a great product that happens to be average internally. One of these unnamed individuals criticized a very popular game because "it's written in Java" as opposed to C++. Who cares? You don't see the code when you play, now do you?
Some friends of mine worked in a startup that split into two. They are literally two companies now and they do not talk to each other, which is strange since they were friends once. If you ask them now why they split, they'll tell you that they had different visions for the company, one side preferring software, the other hardware. That is historical revisionism, since the hardware guys only went hardware recently.
The original split was scripts and open source vs software and developing everything from scratch. Team OSS+Scripts wanted to get things done and get them done fast, team in-house wanted them "done right." Team OSS+Scripts were accused of taking shortcuts and taking the easy way while they countered that with "you're over-complicating and over-engineering things." Team OSS+Scripts said "They care more about how it's done that what is being done. They want to show the world not 'look what we're doing' but 'look what we can do.'"
There was a lot of harsh words said, including some funny ones like "technical masturbation," The split was painful and permanent.
They are two companies now, and the OSS+Scripters are the bigger, more successful company and are more of a hardware company now somehow. No, not somehow. They were pragmatic and quickly identified a way to do things, whether it included scripts or hardware. The software company got bogged down in the details.
While the "script" side were drinking champagne, the software side was analyzing memory leaks, thread leaks and core dumps. While the software side was trying to clean up their giant mountains of code and add new features, the "script" side was using their money to buy hardware so that they don't worry about "mountains of code."
One side won and the other lost, but the one could easily learn the wrong lesson - the triumph of one technology over the other, one development methodology over another or one system of management even. These are all wrong lessons.
As an outside observer that did not take sides, the lesson is this - they both asked "What do we want to do?" and wanted to do the same idea. "How do we want to do it?" was obviously the next question. One side found an easy way of doing it and the other found a complex way of doing it. "Why? Why would you want to do this in the hardest, most complex way possible?"
One side asked "Why?" and accused the other of using the project to show off their development skills and add points to their CVs.
I did not partake in the war, but I learned a lot of lessons myself. Ask yourself "Why?" everyday. Why are you making this and why you're making it in this way. If you don't have an answer, maybe you should stop and think about what you're doing.
areudirty
prguitarman
discoholicmusic
stormborns
ellievsbear
gamechangershow
2087