Things I, As a Developer, Wish More Entrepreneurs Knew(startupweekend.org)
startupweekend.org
Things I, As a Developer, Wish More Entrepreneurs Knew
http://startupweekend.org/2012/09/20/10-things-i-as-a-developer-wish-more-entrepreneurs-knew/
34 comments
Add the mythical man month to the list. SO many non-technical folks fall victim to the idea that by putting more people on a job you can get it done faster, when in reality as we all know, efficiency drops sharply after a point. It takes a woman 9 months to carry a pregnancy, 9 women can't do same the job in one month, and the same is true for solving any complex problem.
Except sometimes you CAN throw manpower at a problem and solve it more quickly. All projects are not the same, and all problems are not the same. It largely depends on how parallelizable the work is and how competent the overall system architecture is.
Point being: lets not turn platitudes into rules:)
Point being: lets not turn platitudes into rules:)
"when in reality as we all know, efficiency drops sharply after a point" <- this is simply a rule: every possible task has some granularity past which point it cannot be decomposed, and every network of dependent tasks has a critical path that determines its minimal time expenditure.
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.
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.
Exactly, 2x people != 2x productivity, it simply doesn't work that way.
My point isn't about throwing manpower at a problem, it's about diminishing returns. The notion that if you put two people on a problem they will be able to solve it twice as fast is a logical fallacy. That's a fact, not a platitude. That being said, if you put 100 people on the problem, you may be able to solve it quickly, but even then you will eventually reach a point where adding more people does not add any more benefit. That's what I wish more non-technical folks understood.
If you put two people on the exact same problem, sure. But, software systems are made up of LOTS of problems, a large amount of which can be solved in parallel.
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.
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.
[deleted](1)
Hey all. This is my first post to HN and also my first contribution to the Startup Weekend blog as an employee.
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 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 :)
Thanks for writing :)
I actually just forwarded it to one of my partners.
His reply: "Is that a hint? JK. Good read man."
I actually just forwarded it to one of my partners.
His reply: "Is that a hint? JK. Good read man."
I'm glad! I had to keep the list short for the blog, but I think this would be a great place to collect other ideas. What 10 points would you have written?
A main one for me is that 'Shortcuts don't pay off in the end'. It hurts when you, as a developer, pour your sole into your app only to have your partners take shortcuts and purchase 'likes', or otherwise 'stuff the ballot-box'. Take the time to help develop sincere social and ad strategies for your app, and your potential for a higher-quality yield increases.
I almost had that point in there, but cut it before publishing.
I also had a point about "your code generation tool isn't good enough."
I also had a point about "your code generation tool isn't good enough."
I'll be at the Startup Weekend event in NYC tonight/this weekend. First time with this hackathon, excited to see how it goes.
How exciting! Are you going to pitch an idea?
We'll see. I've got a few ideas, but more than open to joining better ones.
I would encourage you to pitch, It was a bit nervy for me, but pushing through those fears are what makes a good startup (not saying that you have those fears just that i did). Plus I had a great time. and who knows? maybe your idea will be one that wins!
As someone that is interested in possibly working with developers in the future but does not have a programming background. Can you elaborate on number 7. Would practicing on something like Codecademy help with this or are there better ways to improve your technical knowledge.
Great question, and I would invite any other developers in here to reply as well.
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.
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.
I appreciated the recommendation to learn how to read a balance sheet. I want to keep my expertise grounded in the technical side of things, but I know I will get a lot more done if I can speak eye-to-eye with the business folks.
Good list, and you could easily replace 'Entrepreneurs' with 'Project Managers.'
thanks a ton for posting this! as a semi new developer sometimes I run into questions like in my head like"is it ok for me to feel this way? should i just be coding faster?". Though it may be true in some scenarios, developing is one of the toughest problem solving skills to to learn. you are always facing something you have never done before.
Additional item:
The demo that was thrown together is not ready to release into production!
The demo that was thrown together is not ready to release into production!
But what about "release early, release often"?
Is there a difference between that and "release early, release often, release broken"?
Nope. Don't be afraid to release broken. As full quote goes: "Release early. Release often. And listen to your customers".
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?
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?
It depends. What sort of broken do you have? What is your business? What is your scale if this is additional feature on existing product.
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?
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?