Things I, As a Developer, Wish More Entrepreneurs Knew(startupweekend.org) |
Things I, As a Developer, Wish More Entrepreneurs Knew(startupweekend.org) |
Point being: lets not turn platitudes into rules:)
Exactly where the "point" at which efficiency drops sharply is certainly project-dependent, but thesash didn't claim that it was not: only that people make the mistake of not realizing that this is even a problem worth understanding and taking into consideration, much less a fundamental one that will likely affect their project.
I think the subject matter would be interesting here and would love to hear if there is anything you think I missed. Startup Weekend gets to be in a cool place to lead among tech entrepreneurs and I'm always to happy to advocate for those in our field.
Thanks for reading :)
I actually just forwarded it to one of my partners.
His reply: "Is that a hint? JK. Good read man."
Where to start...having open conversations with your developers is a great place to start. It turns out we love studying and talking about our field.
If you don't have ready access to developers, you can try reading through "Coders at Work" that I linked to at the bottom of my post. Another great idea is to just go to Wikipedia with any of the terms you don't know.
Codecademy or things like it might teach you a little more about a specific language, but these are general principles that are not dependent on a given programming language. This is more about software engineering as a discipline.
You might also try "The Agile Samurai" by Jonathan Rasmusson. I've never personally read it, but it's in our office and I didn't hate what I saw in the table of contents.
Thank you for your comment.
The demo that was thrown together is not ready to release into production!
That's why it's a platitude. It gets bantered about by developers as an explanation about why we just can't go any faster (hiring people is a lot of work after all), but in reality they CAN go faster with more people working on the various problems that make up the system.
Of course there is a point of diminishing return. The management costs come into play. The communication inefficiencies. The process issues. Those can be largely solved with good leadership, however.
It's a rule that is only true when it's true, which doesn't make it that useful to me. I've grown teams on multiple occasions from one or two developers to much larger numbers. While productivity may not have increased linearly, it sure made the projects go much faster. Hell I'd argue that doubling a two person team more than doubled productivity just because the external drags tends to be more distributed which reduces the context switching developers are having to do.
I think there are many more shades of grey that inexperienced founders just don't recognize when they're bound to that idea.
Trying to perfect a product by your self is hard and other people always find a genuine way to broke it. I believe that it is more important to be first out, first with samples and first with some kind of a product to sell that improves with time.
Thoughts?
Usability? How broken?
Performance? Might be ok if you have no initial customers.
Dataloss risk? Depends on the business.
Security problems? What is the worst case - personal photos (whose), medical data. Legal risks?
I also had a point about "your code generation tool isn't good enough."