Software Prototypes into Finished Products? 55
blastedtokyo asks: "With all the talk of offshoring and outsourcing, it seems that taking an entrepreneurial route is a great way to take your life out of the hands of overpaid goons and put it squarely in the hands of an underpaid one. Without an organized team of coders, testers, and designers it seems very tough for a single person to get started in anything other than consulting, or selling stuff on eBay. With my background in product design, and my knowledge that my coding skills aren't the greatest, I'd like to find a vendor or team to help develop some software ideas that I've been stewing over for a while. In other words, I've got the business plan, some credit-cards ready to be maxed out, the bitmap-demo and the specs for a few possible projects, but would like to get a team to code up a working prototype suitable to get some initial customer evaluations. Does anyone have experience sourcing such a vendor? How would you interview a firm to know that their staff is easy to work with and competent? Is it possible to do something like this without delays, excessive mis-communications and cost overruns, or is it better to just start hiring contractors, one at a time?"
Get some legal advice first. (Score:5, Insightful)
First Find A Great Project Manager (Score:5, Insightful)
The only way to handle consultants is to have your own very knowledgeable and forceful project manager to drive the consultants. This person needs to know enough about coding so that they cannot be BSed, or needs to have a trusted resource that will keep an eye on things.
I've yet to hear of even a single offshore success story; all of the ones I've heard end with "we were already way past the deadline, and we had to start rewriting from scratch!". Managing a project in your own office is very difficult. Managing one half-way around the globe staffed by people with different language and culture... forget it.
Good luck!
Why are you looking for a firm? (Score:5, Insightful)
Why would you want to (essentially) outsource development of your idea? You may not be the greatest coder in the world, but you should be able to put together something by yourself. If it's a large enough project that it might take 2-3 additional people plus you a number of months to complete, then start your company, find those people, sell them on the idea, and get them to come work for you in a startup capacity - reduced or no salary, stock or option grants, etc. in return for shared responsibility in creating the company.
Face it - a consultant or contractor is only obligated to give you what you've contracted for, and is probably going to be more than happy to eat up your cash reserves by working extra hours to fix bugs, meet demo deadlines, etc. His/her reward is relatively small, and effort is commensurate. Someone sharing responsibility with you for putting out the product will be a lot more motivated (by a greater reward, and a greater risk) to provide whatever effort is needed to get the product out and get money rolling in ASAP - presumably your desire as well.
Re:a different business model? (Score:4, Insightful)
Re:XP (Score:4, Insightful)
But....
As a customer, I wouldn't hire a firm/team based on their methodology talk, whether they're talking XP or RUP or whatever. I'd hire them based on their demonstrated ability to get useful software out the door, then hope they keep doing whatever they'be been doing.
That said, as a customer I'd want frequent delivery of working code, regardless of the specific process the team will be using to delivery it.
Re:XP (Score:3, Insightful)
without a detailed plan you are going to loose control over the things
That's not my experience of XP.
What you need to have is the ability not just to plan, but to re-plan, over and over. I forget exactly how Barry Boehm phrased it, but his pithy summary was that traditional methods (like the waterfall) were plan-driven, whereas agile methods like XP are planning-driven.
I've done a couple of substantial XP projects that basically started with just an idea. By sketching on whiteboards or in HTML, we produced mock-ups as a way to discuss what we were up to. As soon as we identified something that we were pretty sure we wanted to build, we spent that week building it.
Because we were good guessers, generally what we built was the right thing. But sometimes when we saw it in action, we'd realize that we guessed wrong and go back to the drawing board. That might seem wasteful, but there were a number of features that we killed after a week's work that non-Agile teams would have built out to completion.
It's sort of like driving somewhere. Nobody sane plans out every twist of the wheel and touch of the pedals in advance. At most, you'd get some directions to give you an idea how to get there, and often people just get a rough idea where something is and hop in the car. To make that work, you have to steer continously, keeping your eye on the road and keeping your goal in mind.
Espeically for long trips over unknown territory, your initial plan is almost guaranteed to be wrong; to get where you want to go, you have to be prepared to adapt.
Why XP is bogus (Score:3, Insightful)
E.g., the fact that the poster child for XP, the C3 project, was a project with fixed requirements, _not_ something requiring constant change. And it just burned money for many years in a row, didn't deliver even a fraction of what it had to do, until it was considered a miserable failure by the customer. Incidentally, it also gave the "on-site customer" stress-related health problems.
Yes, contrary to what the sacred XP scriptures claimed, that project was _not_ a success. The whole XP myth is based on repeating a lie over and over, until enough idiots start believing it. And God knows there's one born every minute.
But let's get back to XP zealots' trolling. Sorry, claims like basically "only XP gives you bug free code, while the rest of the world leaves bugs in", are bogus and it's just trolling. No programmer willingly leaves bugs in _release_ code. XP or no XP.
What XP does is redefine what bug means, so, blimey, under our double-speak standard we didn't have bugs. Well, gee, ain't it the easy way out...
Straight off the sacred books of XP: if the customer didn't explicitly give you an automated test-case that fails, then you don't have a bug. No, I'm serious.
If the customer's automated test case inputs the number 10, then presses button A, and then button B, that's the only "bug" you can possibly have. If inputting 15 and pressing directly button B causes the program to crash and burn, or even to garble the database, hey, it's not a bug because it wasn't in the automated test case.
Worse yet, if inputting a 65000 character string instead of a number there causes a buffer overflow and allows someone to take control of your machine, it's still not the developpers' problem under XP. If the user didn't explicitly give you a test case with a 65000 character string as input, it's not your problem. Yes, all the buffer overflows we moan and bitch about in Windows and IE would count as "delivering code without bugs" under the XP standard.
(Incidentally they also fit another XP koan: writing the simplest thing that can possibly work. Making the extra effort to write a buffer class with checked bounds, or an URL validator class, so such bugs don't happen... well, that's "wasting time with flowery design and frameworks.")
What's your recourse as a customer then? Well, hey, it was _your_ fault that you didn't give them the right test cases. But don't worry. You'll give them the new test cases, write it as a change request, and pay them another cycle to fix it. That's the XP way.
That's just one of the many lies and double-speak that XP is _based_ on. On one hand accuse everyone else of shipping buggy stuff, on the other hand conveniently redefine the _exact_ _same_ stuff as "without known bugs" for yourself.
But, as I've said, that's just one of many.