Posted by popmechanic on April 24, 2011 at 9:09am
Regarding this job posting, I don't believe that it's in either party's best interest to execute Drupal development contracts under these terms:
- "Reasonably priced by project, not per hour"
- "Not juggle clients - you work on one client's project at a time until that project is completed"
The first stipulation leads to outmoded, unhealthy waterfall-style development methodologies. The second is something a client should be able to dictate only if they are also offering health and unemployment insurance.
Contracting is often the best way to execute complex projects but I believe that we as a community need to make it clear that there are certain best-practice business standards that we must insist upon.
Thoughts?
Comments
Fully agree!
also, I do not trust job listings by companies who cannot identify themselves. This is a rampant problem on craigslist and now it seems to be happening more and more on drupal.org :(
Dan Hall / portland drupal developer
Drupalicon in ascii .(8)
If you don't need work and
If you don't need work and don't qualify, you don't have to reply. I am happy to provide full disclosure and discuss all with whoever is interested in doing work.
I am happy for you if, when you need to have your house painted, you don't mind having the contractor work per hour and whenever they can get around to it. Most people don't, however, and won't hire such a contractor. Thankfully, most contractors understand this.
I realize that no one has to
I realize that no one has to reply. In my experience most experienced software developers will not issue flat bids for complex software projects. Every contract must find a way to equitably distribute inherent project risk across both parties and the only way to reduce the contractor's risk to an amenable level would be to create a software specification that is so ridiculously verbose and explicit that, a) if the client had time enough and knew enough about the technology to create the spec they wouldn't need a contractor, and b) that's just not a very good (or enjoyable) way for two parties to create usable software together. The specification always proves to be more of a map than a blueprint. Always.
I don't mean to be rude, I just wanted to share my thoughts with the rest of this community about the business terms that you're insisting upon. I don't think it's the best way to promote healthy working relationships with your contractors, or to create the best product.
recommend: find contractors you trust
this tells me all I need to know:
Herodotus
History
Organizer of groups
0
Primary profile:
Profile on http://drupal.org/
Member for
1 day 22 hours
Dan Hall / portland drupal developer
Drupalicon in ascii .(8)
Thanks, everyone. I'm just a
Thanks, everyone. I'm just a non-developer who would like to get a small website worked on. Anyone who's interested in doing so can discuss and define the scope with me. In the meantime, perhaps you can discuss all these ideas elsewhere?
This is a good place to discuss these points
This is a good place to discuss these points as it provides for sharing wants and needs within the open Drupal community. This job listing was posted publicly with many unique requirements that are relevant to the topic of "building developer/client relationships".
Drupal
what advice can we give people hiring Drupal contractors?
What are the best practice business standards we want to insist on? What guides could help someone write a better RFP (especially for smaller projects, where the person requesting help probably doesn't know where to begin)? Does anyone know of a helpful guide that we could hand to someone before they write a fuzzy contract/job post? I found a very broad guide: http://drupal.org/node/51169 that I think would overwhelm a lot of the nonprofits I've worked with. Here's my first crack at a fast guide for someone with a small budget trying to get their website built. Would love feedback/co-creation:
• If you want good programmers on a fair budget, come clean: provide as much information as you can, let potential contractors know if this is a 30 hour project or 300, if your budget is $1k or $50k. It doesn't save you anything to keep secrets, to think you'll get someone better for less by not sharing your budget. If you have a deadline, put it in the first proposal. Answering proposals takes time; you can immediately filter out every good programmer by asking them to waste their time asking obvious follow-up questions. List the company name/mission, lots of programmers are trying to do good work for good companies, lots may want to work repeatedly in a specific field (and are faster at building sites similar to the one's they've already done).
• What kind of expert are you looking for:
⁃ Do you see your site requiring detailed development by a programmer, or using off-the-shelf modules only?
⁃ Do you see your site needing an artist, or using off-the-shelf theming?
⁃ Do you want a developer who will look at a difficult requirement and say "I'm a tech ninja and can program that for you the way you asked" or someone with a management approach who'd say "there might be a way to meet your goals in a more affordable way" or "you wanted low budget, that's out of my league." PS -- No really, did you want it low budget, or do you want everything?
• Agile programming for non-developers in one short paragraph: a good developer can build a much better website in less time if you explain your goals, and then have regular back-and-forth discussions, making adjustments. Clients often try to get a fixed project done on a fixed budget, but this almost never works well -- from the developer's perspective, the clients rarely communicate exactly what they want, and they always change their minds. Fixed budgets where you pretend it won't happen this way just postpone the adjustments and increase the pain. If you can't flex your budget, then flex your priorities, doing the most important and easiest parts first and seeing how much you can done. If your budget is absolutely fixed, describe what can flex.
• Be careful to get someone who has Drupal-specific experience. Drupal has a long learning curve, so sometimes a very experienced programmer can be overconfident that they can learn it quickly. Many technologies can be picked up quickly by someone with programming experience; Drupal is just too big.
• In an interview, ask a developer to show a Drupal site. Then ask them how the backup system works for that site, and what they did to make sure the site could be maintained over the long run if they quit. Any semi-coherent answer is a good sign. These questions show a developer that's paying attention to what clients really need that the client may not recognize (though some clients refuse to budget for these vital steps even when told the importance.)
Your comments are good but ...
The one problem I see with your list is that someone new to drupal will not know if they need "Off the shelf modules" or custom coding. That may be true of new people on d.o who are looking for drupal experts for help. This is especially a problem with over 7000 "Off the shelf modules".
Paul Chernick
CEO
Chernick Consulting
(310) 569-2517
Let's keep Drupal a friendly
Let's keep Drupal a friendly & welcoming community for both users with thousands of posts as well as those with 0. People new to the community may not know certain implicit practices that we take for granted, so let's be friendly about communicating them. There's not reason to single someone out because they have a new D.O. account.
Agreed. I also believe that
Agreed. I also believe that new members should know that this is a community, not just a job posting board. People should certainly bring contract and employment opportunities here. But each of them is subject to discussion by the community. And personally I feel that it's healthy for us to insist upon certain standards of engagement.
Employee or contractor?
As someone that has both worked as an independent contractor and hired them for years, I fully understand the desire to control costs and to make sure that your contractor is not overbooked (or can at least deliver what they say they will do).
Now I do take on project-based contracts occasionally, but only if well defined in scope and limited to small tasks. Years ago, I actually worked on bids for multimillion dollar, multi-year contracts for the Fortune 100, and even then the express language in the contract was that the money bought X hours of dev time, and tasks were estimated in reasonable ranges of time (and honestly, those contracts were fat enough to allow for overrun).
But the biggest issue here is the second stipulation about "juggling clients". This is a big red flag, not only to me, but to the government, that the desire is to have the benefits of an employee without the cost. From the IRS website:
Software is not house painting.
After reading the listing, I would guess that someone has been burned by scope creep and missed deadlines before. However, estimation of work in software is not like estimation of work in any other field. It just doesn't work the same. A house can be measured, with square footage of walls and such. Software estimation is much more difficult.
I can't tell you have many lines of code it will take for a given feature or module. Your desired feature may require a certain amount of research time. Often times, clients ask for changes after work has started, something a house painter (having purchased materials such as paint) would balk at without significant extra payment. Software is more agile and flexible, allowing for such changes, but this makes payment on a per-project basis problematic. Such schemes are too inflexible and thus, most developers use hourly billing.
Anyway, my point is that your house painting argument is comparing apples and oranges and doesn't hold water.
Best of luck with your project, though.
Might want to check with legal
I'm not a lawyer, however when you dictate HOW (as in hours per week, how they manage their clients and subcontractors) work is to be completed you are in employee territory, not contractor territory. Contractors are generally free to get the job done as they see fit to meet your requirements. Be careful, because you could end up with nasty tax implications otherwise.
Agreed re dictating how a person works
The terms of the contract in the original post definitely veer into employee (as opposed to contractor) territory.
Also, an additional thing re the original post - it says: "Not juggle clients - you work on one client's project at a time until that project is completed" - this isn't how a lot of talented people work, and there are a lot of benefits of not working like that.
One of the benefits of working on multiple projects at once is that you learn new things and approaches from the individual projects that increase the quality of all the work.
@herodotus - it sounds like there are some specific things you want to ensure happen when you begin to create a working relationship with your contractor. I'd recommend being up front with the outcomes you want, as opposed to trying to shape the working environment of your contractors.
FunnyMonkey
I'm so broke....
I will screw up any project you have for a lot less than the other guy ;)