Subj : Re: How much should I charge for fixed-price software contract? To : comp.programming,comp.lang.java.programmer,comp.lang.lisp From : Phlip Date : Fri Aug 12 2005 07:07 am Robert Maas, see http://tinyurl.com/uh3t" wrote in message > So if I can't brag about my abilities (because I'm not the braggart > type)... I'm not sure how you are taking my posts here, because they might sound like cheap shots. They are not. Please understand what I mean when I point out you are _very_ good at bragging about what a bad time you are having. Done right, that's called The Blues. Just keep it short! Now, about setting yourself up for impossible expectations... > OK, let's work on on a single example: I'd like to work for Sun > Microsystems, implementing some new ideas in Java. What the hell does working in Java have to do with working for Sun? Do you really expect them to drop what they are doing and declare a permanent corporate holiday on the day you arrive and announce you want to experiment with their toy language?? If you _really_ believed in this new idea, you would write it up, give it away for free on the Java communities, and generate some buzz. Never think for a minute that getting money has anything to do with preserving your intellectual property. That ways lies madness. > ...But so-far that has been a dead-end because he hasn't > gotten any contract to do the CGI stuff so doesn't yet have any money > or need for my services, and he doesn't know anyone else to refer me > to. One more thing. If you ever get near the negotiating step again, offer to pay per "story point". (Look it up.) That means the customer requests a line-item for a feature ("put a button here that..."), and you estimate in hours how long it will take. Then you charge to the estimate, not the actual. Demand the _smallest_ possible line items - 2 to 9 hours each - to make them easy to estimate. This technique simplifies the hell out of client negotiations and discussions. If the cost is high, the client redacts line-items from a feature. If the estimate is low, you learn something and coast for a while. If the estimate is low, you spend time cleaning up the codebase. So you and the client have a compelling motivation to efficiently converge on the minimum feature set that maximizes value. The reticence at the "now I need funds to put you on this job" step is because so many of your peers have destroyed your potential customers' faith in programmers. Yes, they would rather hire an idiot freshly graduated to use the latest buzzword-compliant crap, rather than a senior who knows how to prevent bugs and stabilize development. Then they must have a huge cash reserve to retain this idiot, because they never know which feature request will cause long expensive bug hunts. Charging per estimate flattens all that overhead and puts you in front of the whole bad scene. > It doesn't seem to be available here on FreeBSD Unix, unless there's > some other name it's called here, do you know the correct filename to > look for on Unix? Anyway, AFAIK I've never had access to any system > that supported Ruby, so I'm jealous of your situation of getting a > chance to try it. What the hell? You have no Win32? The Ruby distro on RubyForge has a standard installer, easier than falling off a log! You really need to work on the positive thinking angle!!! > The whole point of open source is that nobody is getting paid one dime > for all their work, and the work will be given to the world at large > absolutely for free, right? No. It's to get them hooked and then charge for the upgrades. Nobody said you couldn't start charging if someone starts using your code, then needs a new feature. Do you think the GNU license prevents you from charging for that? -- Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!! .