Slashdot Mirror


Finding a Ready-Made Dev Team?

marshrew writes "We are a small startup just coming out of a period of R&D with IP and prototype code (containing open source, commercial & freelancer-built custom components) developed/integrated in-house by essentially one guy. We're at the point where we want to build out first commercial implementation which will require a handful of developers for at least six months. We really don't have time or funds to go through a developer recruiting cycle, create a practice, get the team "gelled" etc. What we'd really like to do is find a small pre-existing team which which we could form a relationship to get our product out the door and possibly continue working with. We don't mean a splinter group from a larger dev house, but an agile, self-contained team, who enjoy working together and have an existing practice. Geography is not a problem as we are used to working in a distributed manner." Does such an animal exist? What have other teams done in a situation like this?

14 of 294 comments (clear)

  1. Perhaps you could hire these guys by FidelCatsro · · Score: 5, Funny

    In 2005, a crack Hacker unit was sent to prison by an over-zealous RIAA for a crime they didn't commit(Theft , it should have been copyright infringement).

    These men promptly got released due to a technicality ,to the Los Angeles und3rgr0und!!!!. Today, still wanted by their Previous employers due to a contractual problem and for maintaining some perl code , they survive as Developers of FORTRAN.

    If you have a problem, if no one else can help, and if you can find them, maybe you can hire...the @-Team.

    --
    The only things certain in war are Propaganda and Death. You can never be sure which is which though
    1. Re:Perhaps you could hire these guys by NewmanBlur · · Score: 5, Funny

      "I gotta work with this crazy foo'!?!"

      --
      Per ardua ad astra.
  2. IBM Global Services by Anonymous Coward · · Score: 5, Informative

    That's who we used in 2001 when we needed a huge web-based Java system done. They brought in nine programmers with a top-notch project manager. It cost a lot, but it cost less than not doing it.

    1. Re:IBM Global Services by Anonymous Coward · · Score: 5, Interesting

      In the long run, you'd almost certainly be better off hiring developers of your own. Hiring developers from companies like IBM GSA, CSC, etc. is a recipe for disaster if you aren't very careful about the contracts and other legal niceties, they'll eat you for breakfast, and then go out for seconds.

      Another poster also comments on long term support and maintenance. Combine all these factors, and I would strongly recommend keeping it in house. Yes, it's a pain, but it'll be better in the long run.

      In any event, good luck.

  3. Dev Team hiring by Old+Wolf · · Score: 5, Informative

    Try www.rentacoder.com , or other such sites. Although most people on the site are private individuals, there are some organizations with dozens of programmers, that can be hired for any period of time or to accomplish any set goal. Plus there is the benefit of user feedback from others who have hired the same team in the past. You can browse the list of teams with the highest user feedback, and invite them to bid on your project.

    1. Re:Dev Team hiring by frenetic3 · · Score: 5, Insightful

      Yeah, you'll be able to find teams like this online. And they will have an appallingly wide variance in quality -- a friend of mine just finished getting out of a contract where he was paying $160/hr for expedited service but the consulting company either was completely incompetent or just too lazy to do the work (their spec was laughable, consisting of blurbs of text cut and pasted from open source components they were going to slough together to make the site).

      But (as a technical founder/co-CEO myself) let me tell you why even if you find a decent consulting shop that this is a bad idea.

      First, you're a startup. You're dreaming if you think your requirements aren't going to change as users start interacting with the site and you tweak your product idea and learn more about the market. This just doesn't jive with a consulting agreement, where clear expectations and well-defined specs are absolutely essential for success. Otherwise, you're asking for a world of hurt (time, money, stress) when you quickly realize that you and the consultant have a very different view of what constitutes "complete" in terms of quality and features. I guess if you have a great relationship with your consulting team, maybe they can be nimble for you. But you'll pay for it -- "Whoa whoa whoa -- you wanted to be able to SEARCH posts on your message board? That wasn't in the spec, it's going to be at least another week, and at x hours at $y per hour, plus overtime, that's..." And this is assuming, too, that you find a scrupulous dev shop -- I can only imagine the horrors of an unethical dev shop screwing over a technically unenlightened founder/CEO (I've seen it. It's not pretty.)

      Fundamentally, you and the dev shop just aren't on the same team (your "incentives aren't aligned.") Look at it from their perspective: they want to get your project done as soon as possible (so that they can start working, and making money on something else) and to do the least work possible that could pass as "complete" especially if you have a flat $x/milestone agreement. You want to make something your users will love, and you don't quite know what that "something" exactly is until a few iterations in. Think about it -- if you're a consultant, and you're trying to wrap up this damn project which is already running late (and it's your head under the guillotine for missing milestones), are you going to 1) complete the feature in the quickest way possible or 2) add a little extra to make something the end user will love... but not get compensated for it? Yes, maybe are consulting companies that will go the extra mile, but these aren't the ones bidding for the bottom of the barrel at rent-a-coder.

      You can maybe align things better with clever contingencies. You can negotiate a support contract or retainer (for bug fixes afterwards) or something with them. But after the project is delivered, you are in a _terrible_ negotiating position as you desperately NEED them for bug fixes and enhancements (i.e. your alternatives are terrible), and they can easily make you pay dearly. Plus, what if you're willing to spend the money but your former lead dev at the consulting shop gets staffed somewhere else? or leaves? etc.

      And all this even ignores the major point. Your product is your special sauce; the thing you do better than your competitors; the source of your sustainable competitive advantage. It's just suicide to try to contract that out to someone else. It's one thing (and highly recommended) to outsource ANCILLARY business functions (accounting, legal, etc.) that to you are basically a commodity. But not your crown jewels. Did Google, Microsoft, Yahoo, Amazon, or frankly ANY successful startup start by outsourcing/offshoring the development of their core IP? (There may be RARE exceptions, and I'd love to hear them, because I know of precisely zero successful companies that have done this)

      So I shudder when newbie founder/CEO or MBA/management major types say they'll get their first product done for $20k and in 3 weeks by shipping

      --
      "Where are we going, and why am I in this handbasket?"
  4. Sony contractors by LiquidCoooled · · Score: 5, Funny

    I hear there are a group of developers who are just being dropped by Song BMG, perhaps you could give them a call ;)

    --
    liqbase :: faster than paper
  5. power of 3 rule by timdaly · · Score: 5, Insightful

    This is optimistic at best. Remember the power of 3 rule:
    (where UOW=unit of work (man/month :-) )
        1 UOW = program for yourself
        3 UOW = give it to someone else
              (you install, you copy, etc)
        9 UOW = give it to local group
              (howto, platform change)
      27 UOW = shareware/open source
              (configure/make/make install)
      81 UOW = product
              (real docs, slick UI, support teams)
    243 UOW = business
              (lawyers, CEO, sales, marketing)

    you're looking at a lot more work than you're willing to
    admit. unless it is a trivial application you need to
    understand that writing the program in the first place
    is the easiest part of the whole problem. Teams which
    don't include the original developer are even harder.

    Tim Daly

  6. Correct approach? by Underholdning · · Score: 5, Insightful
    I would strongly advice against such an approach. Say you manage to get a team of super coders from India to China to the US. They create a product ready to ship in 6 months and then they dismantle, continuing on with other exciting projects.

    Now, what happens when the product is in need for support? Who are going to support code written by a team of super corders?

    What happens when there's a demand for extra functionality? Who's going to implement that?

    Who will maintain the code?

    Yes, you could try to reassemble the team, but developers hate support. And besides, the team will much rather start on a new project than supporting the old one.
    My suggestion is, that you take your time and hire people the old fashioned way. If you don't have enough time to do that, your project is doomed anyway.

  7. Funding is a problem and will remain a problem. by pelorus · · Score: 5, Interesting

    The way one local (and now powerful) company did it was by "hiring" people for pizza. If the product is cool, then you'll corral some college geeks to do the groundwork and free up your good coders for the cool work.

    This has been touched on recently in some blogs ( http://www.wilshipley.com/blog/ and http://www.drunkenblog.com/drunkenblog-archives/00 0713.html ) that college students, who were used and abused during the bubble, remain a good resource of, dare I say it, cheap labour. They like the prestige, need the experience, and are used to working in small project teams. And yeah, you can pay them peanuts.

    And no, they don't even need to be in college. Two of the most impressive code monkeys I know dropped out of High School.....

  8. How IBM Conned My Execs Out Of Millions by didiken · · Score: 5, Interesting

    Well, since you're posting as anonymous with high praise for IBM Global Service, let's see this counter argument from Kuro5hin: How IBM Conned My Execs Out Of Millions .



    This is a first-person account of how IBM was able to con my execs out of millions of dollars. Gullible management tries to swim with the shark and gets chewed to pieces. Witness the exec-level FUD sales techniques and the $325/hr subcontractor labor bait and switch....
    More...

    1. Re:How IBM Conned My Execs Out Of Millions by dekemoose · · Score: 5, Insightful

      Boo freakin' hoo. Sounds like a classic case of mis-management on the behalf of the defense vendor. Any consultant, IBM included, will eat your lunch if you don't stay on top of them. One of my promary job responsibilities is keeping consultants focused on the project scope. It is part of a consultants job to try to get a bigger piece of a project, and if they have all the project, make the project bigger.

            "Whenever management was trying to select a vendor, or even having second
              thoughts about a vendor, this consultant would offer senior management the
              solution to their problems. Management, in a hurry, would agree, happy to
              have the matter resolved. The questions of whether IBM could deliver on
              their promises or whether their bid was competitive went unasked."

      Okay, management couldn't get their head out of their arse so they made a snap decision based on questionable information. Nice.

            "Where was the technical staff during all of this? Staying out the way,
              mostly. They knew that IBM was selling solutions two levels over their head,
              and they didn't want any part of it."

      The techies saw an impending clusterf*ck and decided to do a duck and cover rather than trying to intervene. Can't blame them, management types probably wouldn't listen, but if you've got a highly paid consultant whispering in your exec's ear and no one tries to present a counter-arguement, what do you expect?

            "Upper management was very reluctant to move back the deadline because the project
              had a lot of visibility, and executive bonuses were dependent upon completing the
              project by the end of the year."

      Okay, management had their bonuses on the line, so they stopped making sane decisions and started spending the companies money to make their own.

      The story goes on much like this. Yeah, you got hosed. IBM saw, in military parlance, a target rich environment, and they were right. That sucks, the fact that those dollars come out of my pocket sucks(since they are a defense contractor all those dollars trace back to taxes). But don't play the part of the innocent bystander, management f*cked up. Period.

  9. My advice based on 20 years experience... by Wonderkid · · Score: 5, Insightful
    ...working with software (and hardware) engineers is this.

    a) Only work with people you know and trust. Until you're Microsoft, you cannot (CANNOT!) afford to make hiring mistakes, everyone in your team must be experienced and brilliant.

    b) Try to arrange for everyone to be in the same building or room, THE only way to brain storm is on an old fashioned whiteboard, not on a chat client, which is really only suited to quick questions and answers, not visual thinking. That's why companies still have physical offices, even in a world of broadband and video converencing.

    c) ONLY allow remote workers if you can be guaranteed they WILL be available online when YOU are online to ensure maximum productivity and real-time discussion of vital issues.

    d) Only farm out small modular tasks to remote workers, keep your core coders close to hand and reward them with ownership in the project.

    e) Have a well written contract and strict but fair code of conduct that should be signed by all parties on paper (not e-mail 'replies').

    f) If you lack the personality to be firm with those who let you down, or cannot hire someone to take on such a role, do not embark on your venture, else your ship will drift all over the place only to be washed up on the rocks.

    g) Else, go for it and if you need any more tips (or can provide any!), reply to this with posting.

    Good luck, and "May The Force be You!"

    --

    O'WONDERWe're working on it.

  10. Re:Why is this true with software?t by satherto · · Score: 5, Insightful

    It's hard to enforce this with programming.

    With construction you have set plans that don't change too drastically, with programming you'll find people changing their mind through out the build.

    Think of it as your building a 4 bedroom single family house and the developer is constantly making little(to him) changes to the plan, you know, add a new bathroom, change the den into a formal dinning room, oh, and the garage is actualy supposed to be part of the house, not a seperate building (didn't we mention that?), and yes it wasn't on the plans we signed off on originally, but those plans just don't work anymore.

    Now with 50% completion, the owners decide that what would work at this location, is actually a 4 family duplex.

    Now that the building is finished and awaiting final inspection, we need 1 really quick change, insteaad of regular telephone jacks wired to each room, we need Cat 6, as we will be doing IP phones, but thats a real easy change right, a couple of plates is all? Now that you've done that, we talked to the guy who bags our grocerys and he had a great idea, move the hoy water tank from the basement to the attic.

    Would you expect the contractors to just eat the difference, or not ask that the deadline change? You as a contractor would point out the changes are all going to cost time and money and aren't in the original thst you based you quote on, but the developer is convinced that it has to be done and pays the extra costs. of course once everything is finished, the developer will go on and on how expensive the project is, and how long it took, and how it still isn't exactly what he wanted (but is exactly what the plan and change orders asked for).

    And yes I've seen this, I've provided IT to costruction and HVAC companies for over 10 years and see this all the time. They complain about delays annd costs, and compare it to how they build projects.

    --
    ----