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?
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
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.
Underholdning.info
The question very much reminds me of what I guy I know said when his 15 people ICT security company were looking for a new guy: "All the good people already work for us, or we know who they work for. Now we're looking for the person nobody else has found yet". This will be the same with the ready made development team. They have a job somewhere, so unless they are a small contracting team that just happens to have an open spot in their schedule you're more or less doomed.
Managing this group is even tougher. The way you describe your company is that it is small, tightly knit, build around one person. Now you need to get new people to work with your group, to smoothen out differences in development philosophy, to get the leader to let go of parts of his baby etc etc.
Tough job ahead of you. Good luck.
Use Adsense for Charity
You could try and partner up with an IT firm.
We currently are partned with three startups; our company provides the IT knowledge for a seriously reduced fee in exchange for a partial ownership in the product that is being build.
Basically we're investing (the reduced fee is still very much required, so that there is an incentive to actually finish the product). However you still need to convince the IT firm why it should invest.
Tbee (or not?)
...and how did the project turn out!?
India (Bangladesh)??? :)
India and Bangladesh are 2 separate sovereign countries. India hasn't quite annexed Bangladesh (yet!) and I don't think they want to either
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.
A bunch of coders with nothing to code was waiting for us in India (Bangladesh).
I assume you mean Bangalore. Bangladesh is a separate country.
Not only that, we still had coders working days in the US, plus the devs working in India, so we were coding over 16 hours a day.
Does this matter? Two people working in the US and two in India should be no better than four working in the US. In fact, they should be slower, as there are all sorts of communications hassles.
The "16 hour day" rubbish works well with call-centers, where you want people available 24/7, but with coding, there is no advantage to shift-work.
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?"
IBM milks its clients for the maximum money it can get. I've seen it myself, we would ask for a 1 line change in the code, even show them how to do it and they would milk it for 4 months of team money.
5 years to make a website? No problem, IBM can drag it out that long.
10 years to make a database, yaking so long that the hardware goes out of date before it's complete? RAF can tell you about that one.
OK fair enough that you can't afford to do the recruiting cycle for a whole team, but I would go through the effort to hire someone you trust to find and manage the right team for you. Whether these are student "code-monkeys", international cheap-labour, or the IBM-team from hell, all that doesn't matter if you have someone that works close to you and knows how to find and utilise these resources to their fullest potential.
In the long run, you'd almost certainly be better off hiring developers of your own.
In the 34 years I've worked in IT in this area, I haven't found a single person that programmed for a living locally as good as the worst of those IBM nine programmers. I've had seven that have worked for me the past year alone that haven't worked-out. If I could find a good programmer, I'd hire them and keep them. It's easy to say hire local, but when you put an ad in several papers in the area and get zero resumes from experienced people, you just can't.
The closest technical universities to us are GA Tech and Clemson. Their Comp Sci majors can't program worth a damn. Their EE majors are typically very good programmers (even if they don't like it) and I've worked with about three dozen of them over the years, but they're expensive to hire and they tend to not want to just program. I've had what I'd consider three world-class programmers work for me and none of the three were programmers. They were EE grads from Clemson that worked on hardware, well were hired to work on hardware. They were great at dividing the system up into modules and loosely coupling the components. The problem is that they all want jobs where they'll also do some hardware work.
Just keep in mind that if you make a development team completely out of inexperienced/little-experience programmers you'll end up paying for it over and over again.
Programmers which are inexperience or have little experience, are cheap because they make lots of mistakes (after all they're still learning). Even then most gifted ones are unaware of how, in the middle/long term, an application evolves in a real-life environment.
Expect hard to change applications, strange bugs, costly to bugfix applications, essential knowledge about the implementation that leaves when the developer leaves and fastly increasing in entropy in the code base(*) (and thus fastly increasing maintenance costs and number of bugs). Expect to have to rewrite the application from scratch after a couple of years.
My recomendation: Get at least one very experience designer/developer (possibly even a technical architect) and give that person technical lead. This person will then set and enforce technical standaards, work environment standaards and documentation standaards; do the technical analysis of the requirements; create the top level design and make or approve lower level designs; act as a coach to the less experienced developers; estimate man-hour costs for implementations.
(*)Increased entropy in the code base: if the application's design is not well ballanced and/or not properly maintained or documented, each bugfix/extension is basically a hack. As time goes by and more hacks pile on top of each other the code becomes more and more complex (known in the trade as spaghetti code), prone to break in unexpected places when small changes are done to it and to randomly exhibit more and more strange bugs. This means increasing costs associated with maintenance and extension of the application. Eventually it becomes cheaper to just scrap it and start anew.
As a software developer of 11 years, and as a recently graduated MBA, I can definitely say you are bang on. Not all MBA's would agree about Mumbai though. Cost is not everything. It may be for publicly owned companies that are mandated by law to make the best profit possible, but for startups, no.
You are absolutely correct about the special sauce. A startup MUST protect their competitive advantage at all costs. When you get bigger, and have larger cash flows, you can afford to lose a bit of your secrecy, since you'll be more able to have (and afford to have) more than one project to diversify your risk. But as a startup, unless you have a really rich uncle who is completely enamoured with your concept (or the VC equivalent) your special sauce is your life.
Do it in house. Hire a few developers, get them invested in the project. Grow out your product and get your cashflows growing. Hire more developers. You'll need them. The parent is correct, once the baby hits the market, the product will change to meet their needs, not your perception of their needs. That will take talent that can quickly implement your changes and that are invested in your success. Best of luck on your new venture!
This whole thing smells of BS. I don't know if this is an ad for IBM or what. Georgia Tech CS majors can't program? Their EE majors can program much better? Ya, that must be because the EE curriculum has sooo many more programming courses than the CS one. Just as you'd expect, right?
You get zero resumes from experienced programmers. You hired and let go seven programmers this year. You had 3 EE grads that weren't even programmers, yet they were "world-class programmers". Hmm. Maybe you don't know what a "world-class programmer" is. There's a bit more to it than just dividing the system up into modules and loosely coupling the components. Why aren't you asking yourself why no one who has a choice wants to work for you/your company? It sounds like you're only getting takers who are CS flunkies or frustrated EE folk who can't find hardware jobs.
Attention zealots and haters: 00100 00100
Relax -- the guy just doesn't know how to hire. Good people *are* hard to find, and they tend to prefer working for people who share their view of how work ought to be done. But, the fact that he hasn't seen any of them probably says more about the work-environment than about anything else.
I used to work in residential construction, where through the contracting of a house only the very largest companies actually do the whole process in house.
We had a small crew who did framing and all the odd jobs to glue all the pieces together. But painting, trimming, electric, HVAC, plumbing, and architectural design all got handed off to a specialist who was paid by the job, and didn't get hired again if he did a crappy job. After a while it became very apparent which guys in town were worth hiring, and they're the ones who got all the jobs on the next projects.
Sure there were problems, but none of this "oh you wanted the walls actually painted? I thought you just wanted a primer" BS that I seem to hear all the time out of computer consulting services.
And, for the most part, people stand by their work. All work is pretty much guaranteed for a year - if it was their crap that broke, they'll fix it free. Only time you have to pay them for extra work is if it's something in their expertise who breakage wasn't their fault.
And when people did screw up horribly (like ending up with two different shades of paint in the same room) they worked overtime for the rest of the week to fix it so we could make our schedule or they didn't get paid for the lousy work! Why doesn't anyone enforce this sort of thing in the CS environment?
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.
I had a bad experience and then a very good one with rentacoder.com - basically I had this pain in the ass problem to do with VOIP and I couldn't get to the bottom of it so at the end of my tether I thought - what the hell - I'll drop 100 USD on rentacoder to see if there's someone who wants to take up the challenge. Anyway, I got a couple of bids and eventually I gave the problem to this chap who seemed to know what he was doing. FOUR WEEKS LATER he's only logged into the box once - so I didn't feel that bad when I asked the rentacoder arbitrators to review the 2 week overdue project (or has he put it "ratted me out"). So my options were then either to get the refund from the escrow account ( they do this to prove that you have the funds - but they won't release it until you're 100% happy) or try again - ah what the hell, why not eh? ... sooo I put the project up again and this new chap offers to fix it within 24 hours - I immediately accept his bid ( can't be bothered waiting till the end of the "auction") and send him the IP and login details (this is at about 11pm). By 10am the next day, the dude has fixed exactly what I needed fixing and come up with a number of suggestions about other improvements I could make. Additionally, I've now put approx 800 USD worth of other coding + configuration stuff his way since then.
:
My advice
Start with something small - i.e. around the 100 USD mark. By all means say that it's part of a larger project soon to be up for bidding, but make sure the project tests several areas in which you need experience and expertise, but is relatively straightforward and simple for people who actually know what they're doing. This will hopefully attract the attention of the coders you want and hopefully make it easy for you to weed out the wannabes.
Two wrongs may not make a right, but three
Having worked as part of the IBM Global Services' top-notch team in Europe, I wouldn't recommend this course: expensive, slow and paranoid, paranoid, paranoid. Met many excellent programmers there but at least twice as many people whose main skills were buck-passing and ass-covering. Staff rarely had up-to-date, or even relevant, skills (everyone being a resource and interchangeable) and managers were frequently the least competent members of a team (typical big organisation stuff). I don't know how many conversations I overheard there about "whose fault" something was and experienced this from outside, too: I recall an incident when working with another company where IBM swore blind that we had brought down a server (they had to shut up when we pointed out to the customer that none of us had been allowed the credentials to access it in the first place).
.... then you had a serious problem at the analysis phase of your project, and thus deserve to fail.
IANAL but write like a drunk one.
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.
----
A few points:
1. The client was a defense contractor. defense contractors are some of the most absolutely incompetent companies I've ever worked with. Just as bad as telecom (old at&t) and government.
2. The client apparently went with a waterfall project plan, in which there were few if any milestones. And surprise, they discover at the very end that there are problems. Duh.
3. According to the poster, the client wasn't capable of simple math: didn't know that the contracting run rate would consume their budget before the project was complete. Again, duh.
4. According to the poster, IBM was charging $325 for everyone. That doesn't sound accurate in my experience with IBM (and other large consulting companies) - in which a couple of top people would be at $325, and the shock troops anywhere from $150-$225.
5. Also, the customer hired programmers for a small project from a large system integrator. That's never a good way to save money, it's a good way to assemble a team overnight.
6. The poster doesn't really understand knowledge management, business intelligence, or customer relationship marketing. By simply dismissing these domains as over-hyped, he's just revealing ignorance. This isn't to say that everyone needs everything that all vendors claim they can deliver, but these are huge domains full of history and detail. And can deliver a lot *if* you understand them and their best practices. If you don't, then you're probably buying/building the wrong solution anyway.
On the flip side, I do agree that IBM has a hard time holding onto top talent. They don't pay enough, and their bureacracy can be a pain in the butt. When you get a team you should absolutely interview every member, and put milestones in the project where you can jettison the team if they suck. But, this isn't an IBM-thing, it's something you should do for whatever team you work with.
You know what the real difference is? In home building the design is probably 10 or 15% of the total cost (pulled that out of my butt), but in software, the design is 98% of the total cost. When you finish the design (the code), you're essentially done.
When you're designing a $250,000 house, and you're half done the design and the future owner wants to move everything around, then it might become a $260,000 or $275,000 house cost and the owner sees a small percentage change because design is a small percentage of price. When you're designing a $250,000 software program which is 98% design cost, and the customer wants to make major changes half way through and you tell him the price is now $350,000 or more, they complain big time.
To fix this you need to break the software project up into pre-design and regular design stages. In the pre-design stage you need a mock-up of the application that you use can see and touch and feel, like the blueprints of a house, and let them change their mind then (i.e. rapid prototyping). The problem of course is that user interface design sometimes takes more than 10 to 15% of the total software time, so it's probably impossible, but something to think about.
"I have never let my schooling interfere with my education." - Mark Twain
Most startup owners don't have the skills of a specialist programmer or engineer, or the skills to provide detailed technical guidance to such a person. They need to trustworthy technical people, who can fill the gaps in their own knowledge.
Good engineers and programmers are hard to find. If they were easy to find ' marshrew' could have just placed a job ad in the local classifies. Instead he/she has to resort to posting on Slashdot.