

Things I, As a Developer, Wish More Entrepreneurs Knew - d_p
http://startupweekend.org/2012/09/20/10-things-i-as-a-developer-wish-more-entrepreneurs-knew/

======
thesash
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.

~~~
enjo
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:)

~~~
saurik
"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.

~~~
thesash
Exactly, 2x people != 2x productivity, it simply doesn't work that way.

------
d_p
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 :)

~~~
kefs
Thanks for writing :)

I actually just forwarded it to one of my partners.

His reply: "Is that a hint? JK. Good read man."

~~~
d_p
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?

~~~
kefs
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.

~~~
d_p
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."

------
trey851
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.

~~~
d_p
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.

------
japhyr
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.

------
mgcross
Good list, and you could easily replace 'Entrepreneurs' with 'Project
Managers.'

~~~
d_p
I was actually a PM before I became a developer. Do you think there is
anything missing?

~~~
mgcross
Not off the top of my head, but give me time - I have only recently started
working under a non-technical PM! The synopsis ('code monkeys') nails it from
my experience (ad agency).

------
koryteg
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.

------
superasn
Would be great to read another list for: 10 Things I, As a Entrepreneur, Wish
More Developers Knew

~~~
d_p
I'll definitely suggest that to somebody in the office :)

Thank you for your comment.

------
josephlord
Additional item:

The demo that was thrown together is not ready to release into production!

~~~
naww
But what about "release early, release often"?

~~~
d_p
Is there a difference between that and "release early, release often, release
broken"?

~~~
naww
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?

~~~
josephlord
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?

