I'll 3rd on documentation... even if you do it yourself.
Startups like to cut corners because they don't have any money. No matter
what you do make sure they take the time to document (George Toft said it
perfectly). I've yet to regret spending a day creating a 200 page document
outlining all of the steps it took to create something and why it was
created that way.
I've had to completely re-implement things because whoever did them the
first time didn't document what they did.
Most IT professionals with real companies behind them cost $75-$150/hr.
You might be able to get a lower rate with longer terms (guaranteed
hours). Keep in mind that the better job you do in specifying the
requirements the more accurate that person's estimate of time will be. If
your spec only has general terms figure on doubling the initial estimate of
time. I won't even give estimates for vague projects anymore because I
know that whatever educated guess I make will be wrong.
You won't have a lot of luck getting most people to work for equity... I
did that BS when I was young and have nothing to show for it. Most people
are wise to it now. The problem is that there is no guarantee that the
startup will be successful but there is a guarantee that that person will
have to do the work. 80% of nothing is still nothing. Somewhere I still
have a piece of paper that says I have 8500 'participation units' for a
project I worked on... it's worth as much as the paper it's written on is.
Unless the concept is extremely strong and it passes the BS test for 'how
will this make money' AND 'who exactly will pay that money' you'll have
Zero luck getting anyone to work for equity. More likely you can get them
to lower their hourly rate in exchange for equity. Unless they can
specifically answer who will buy it RUN.
Unless they have a very specific spec you probably can't split it into
multiple deliverables; the more you know the easier it gets.
For #5 - it is plausible whoever does it will spend WAY more time than you
expect trying to get it to work. Spending a week on something that other
people will use in a professional product is nothing. Take whatever your
initial guess is and triple it.
My personal advice is for you is
1. Get everything in writing. No contract... No Deal. Make sure the
contract says they can't take your rough draft and use it unless they pay
for ownership of what you do. Eg: Until they compensate you YOU OWN IT.
2. Demand some kind of collateral if their project doesn't work out. No
matter what YOU DON'T WORK FOR FREE. Let everyone else be the low price
leader. Get paid enough to make it worth your time.
3. Unless this is a personal friend (you know their mother) do it on
your own hardware/etc first. When you have it working, get paid, and then
give it to them.
4. Don't even start until can put it in a work breakdown structure. It
should be 100% clear on what is required, what all the parts are, and who
will do them (even if it's some un-named entity you'll hire). Vague
projects never finish and instead scope creep to death. Put a box around
what you're going to do. If they come back and want more make they also
pay more.
Good luck!
-- JD Austin
Voice: 480.269.4335 (480 2MY Geek)
jd@twingeckos.com
On Mon, Mar 24, 2014 at 5:20 AM, Stephen Partington <
cryptworks@gmail.com>wrote:
> I will second the documentation comments here. At the office we dealt with
> a bunch of programmers that were given their head and there is such a black
> hole of knowledge about what is doing what. Not that the relationship ended
> the code is ours but the leftover kludge is takeoff more time to decipher
> than patch.
>
> And we actually have one of their better programmers working for us on
> contract after he was let go from the dev house we used.
>
> Anyhow it is a mess.
>
>
> On Sunday, March 23, 2014, George Toft <george@georgetoft.com> wrote:
>
>> I've been involved in two startups, and I won't "say" run away, but you
>> know I'm thinking it.
>>
>> First startup had a great product - a virtual mall coded in flash
>> designed for dial-up modems (33kbps!) and looked fantastic. Problem was it
>> was written by a couple 18-year-old whiz kids who didn't know how to
>> document anything, and when the inevitable labor dispute came up, they
>> walked and the entrepreneur was left with undocumented, unfinished code.
>> The moral of the story is you must include time (and time is money) for
>> documentation. Pound this into their head. Document requirements.
>> Document test cases. Document architectural decisions. Document
>> engineering decisions. Document process flows and data flows. Make this a
>> brain dump. BTW - this will easily take as long as the coding, but if you
>> don't, when it breaks and you're not around, they're screwed.
>>
>> Extreme case #1: I set up a Linux box as a samba server, NFS server, and
>> DNS server. It has a custom backup script that backs up to a remote
>> server. My documentation is 40 pages.
>>
>> Extreme case #2: I set up Symantec ScanEngine on a three Linux boxen
>> behind a load balancer. Custom script to convert Symantec logs to plain
>> text. 130 pages of documentation.
>>
>> Extreme case #3: I set up 3 VMware heads with a NAS backend and a back up
>> server; three VPN servers; DNS and mail relay. 86 pages of documentation.
>>
>> Guess what? I never forget anything about these systems and whoever
>> takes over for me will know everything I do about them as well. It also
>> serves as proof of testing and if anyone ever says I didn't do anything,
>> the proof is in the documentation that I did what I claimed. Also, it's
>> fun to do destructive testing and put screenshots in the docs.
>>
>> Regards,
>>
>> George Toft
>>
>> On 3/23/2014 9:38 PM, David Schwartz wrote:
>>
>>> I have some general questions relating to a programming project for a
>>> startup, and someone suggested this might be a good place to post them.
>>>
>>> A guy I know is involved with a start-up and they need to have a
>>> commercial router reprogrammed for their specific needs. (I can't address
>>> the why's or wherefore's about this. That's all they've told me thus far.)
>>>
>>> Since this list probably has a fairly wide range of people on it, I
>>> figured a few of you might know something about taking on projects for
>>> startups, and also maybe even programming routers.
>>>
>>> I found the product page for the router they're interested in using, and
>>> it has a link to download the GNU-licensed source code that they're
>>> obligated to distribute. It's a tarball that contains a customized version
>>> of OpenWrt, an embedded Linux distro designed mainly for use inside of
>>> routers and similar equipment.
>>>
>>> (see http://openwrt.org for more info)
>>>
>>> I've looked over the OpenWrt site, and it uses Packages to allow you to
>>> add your apps into a virtual file system. Since the router's logic, as a
>>> Package, wouldn't be part of the distro, it's probably not included in the
>>> tarball. But the configuration screens may be.
>>>
>>> Anyway, this guy wants me to talk with their tech dude about
>>> implementing custom firmware for these devices.
>>>
>>> I've never programmed routers before, but it seems like little more than
>>> taking data packets from one port, filtering them, maybe translating and/or
>>> transforming them, and sending them out of another port. I don't know
>>> exactly what they want done yet, so I don't know why they need customized
>>> firmware.
>>>
>>> Ignoring all of the specific, and keeping in mind that they're a
>>> start-up and are probably under-capitalized, I have the following
>>>
>>> QUESTIONS
>>>
>>> 1) Generally speaking, how easy is it to find someone who has experience
>>> doing this kind of work? (embedded Linux for equipment, including routers)
>>>
>>> 2) What would they normally charge? (ie., is it a super-specialty kind
>>> of thing that would command a really high rate? Or would $50/hr be
>>> considered reasonable?)
>>>
>>> 3) If they want to pay mostly or entirely in equity, how would you
>>> arrive at a fair compensation rate? How much harder would that make it to
>>> find someone to do the work?
>>>
>>> 4) I could probably learn what's needed and do this for them, but it
>>> wouldn't be as fast as someone who's programmed routers before. I'm trying
>>> to decide if I'd be better off saying I'll do the programming and
>>> everything myself, or take this on as a kind of Project Manager and do what
>>> I can while finding someone else to do the coding. They'd still be paid in
>>> stock, I'd imagine.
>>>
>>> 5) Assuming they have some kind of a spec, how much work would be
>>> involved before you'd start coding? IOW, how much prep work would be needed
>>> before you're ready to code this? What I'm getting at here is this: is
>>> there a good chance there's 40-50 hours (eg., a full week) of prep work,
>>> like rebuilding and tweaking the OS, verifying it can be loaded onto the
>>> device, figuring out how to debug it live, and so forth? Or is this
>>> something that would take a day or so?
>>>
>>> 6) How could I split this into some smaller deliverables for project
>>> management purposes? (I'm just not familiar enough with embedded projects
>>> like this to guess what kinds of milestones someone might set.)
>>>
>>> Keep in mind this is a commercial product that they want to reprogram.
>>> The vendor is going to be of little or no use in helping with anything. So
>>> we'd be hacking this thing all the way.
>>>
>>> I'm curious what your opinions are. Please refrain from things like,
>>> "turn and run away as fast as you can!" I get that some folks won't go
>>> near startups. That's fine. It doesn't alter the fact that these guys are
>>> looking for someone, and they'll find them sooner or later. I'm just trying
>>> to get a sense of how to negotiate with them and if it's worth my while to
>>> consider taking it on it myself.
>>>
>>> Thanks!
>>>
>>> -David
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
>
> --
> A mouse trap, placed on top of your alarm clock, will prevent you from
> rolling over and going back to sleep after you hit the snooze button.
>
> Stephen
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)