I have come to a realisation as I hire programmers: when I pay them for each hour worked, their self-interest is exactly the opposite of MY self-interest.
For a programmer paid hourly , he:
- Writes code slowly so he gets to work more hours and make more money
- Puts errors in the code so he gets more follow up work fixing those errors
- Writes brand new components instead of reusing old components so he spends more time and he gets richer
- Makes the code as obscure as possible, so you cannot hire someone else to continue his work
- Uses your time to learn new technologies – you pay for his training
On the other hand, programmers paid on a project basis have a strong interest in:
- Getting the project completed as quickly as possible
- Making the software as error-free as possible, so they can move on to the next project and do not have to always support old projects
- Reusing as much code as they possibly can, so the project gets done quickly
- Stick within their expertise area, so they can accurately gauge quoted project price
A programmer working on time basis has no motivation to get your project done as quickly as possible. Every one of his motivations is exactly the opposite of what you as the project owner wants. It makes very little sense to hire programmers on an hourly basis – try to always hire them on a project basis. Their work will be far more honest.
If you're interested in technology & startups, then follow me on my low volume twitter account
This only works if you really can produce a 100% complete and correct specification. If not, then the programmers incentives might surprise you: he wants to fulfill your spec as fast as possible, but he has no interest in pointing out possible flaws or improvements for your product. In the worst case, you'll end up with a finished product that is next to useless.
@Björn – he does not have an interest in pointing out flaws and improvements for the current version – but he has an interest in pointing out flaws and improvements for the next iteration of the software
unfortunately it's never that easy. clients always change their minds about something. Charging by the hour lets clients make these changes while ensuring that they really want or can justify them.
What this article completely ignores is the fact that most programmers have (or should have) a reputation to uphold. Do you really think that a programmer would be able to continue doing this for very long before word got around about his practices?
The issue with this article is that you're saying if someone does want to charge by the hour, people might assume that they're not a good programmer or that they're going to con you out of lots of money. These don't necessarily follow each other.
Disclaimer: i'm a programmer
Nice disclaimer.
Ok, so a programmer working for *you*, Max, should have a motivation to work honestly on a project basis, and to point out opportunities for making the software better and grow the company.
Unfortunately, many people hiring programmers are not good at specifying what they want; nor at recognizing and acknowledging when they are demanding that more work be added to the “same” project. When working for these “scope creep” people, a programmer has some difficult choices to make just to keep from getting heavily taken advantage of.
With this kind of employer, even if the programmer tries to sit down with the employer and work out a clear and specific specification of what the project really is, many employers don’t want to pay to do this specification work. Some employers will take the specification (that they don’t want to pay for) and use it to hire someone who, because the specification is already written, can make a lower bid on the job.
Max, if you aren’t getting taken advantage of by programmers who you hire by the job, it’s probably partly because when you hand them a good, clear, sufficiently specific specification, that helps high-quality experienced programmers to recognize that you are a high quality client who solves problems instead of creating them!
I think this can be mitigated by having that programmer be managed by someone with minor technical ability/experience who would probably catch those kinds of behaviors. The manager may not realize the programmer is doing it on purpose, and may ascribe it to incompetence, but the end result should be similar.
When a programmer works on a project basis, it is in his best interest to spend as little time as possible on the project, because that means a bigger reward on time spent. That means that he will also take shortcuts in a lot of cases, which he would not do if he is paid on an hourly basis. It means the resulting code will be created in a shorter time, but will be of a lesser quality.
It also means there will be more discussions about which things should be considered in scope of the project, or which things should be considered as extra requests that surfaced during development. (Customer will claim it was mentioned in the initial specification, programmer will claim this was not clear from the specification and was only fully specified later on.)
If you are working with an experienced programmer that takes some pride in his work, i think you are better of with working on an hourly basis.
I honestly don't know any serious programmer who is gonna write code slowly on purpose, or who's gonna introduce errors on purpose. The latter would even be more likely for a fixed price project, since it would result in support at a later point which would not be included in the fixed price.
Additionally, I would claim that if you are working with a serious programmer, it is more likely that the code will be obscure when he is working on a project basis. On a project basis, the programmer is under a constant time pressure, so there is no time for writing decent comments, and shortcuts in code become so much more tempting. If he is paid hourly, he has more time to improve the quality of the code, which also automatically results in more maintainable code.
In short… your conclusions are right if you are looking short-term and want a program that runs and that (seems to) work(s) as fast as possible, and as cheaply as possible. This also means you don't care at all about the underlying code because "as cheap as possible" and "maintainable code" don't go together. If you want stable, maintainable code and you are looking long-term, then i think your conclusions are wrong, and you are better of with paying a highly skilled programmer on an hourly basis.
I second Ruben. I am a lazy programmer, so I'll reuse his comment.
+1 for Ruben. Your comment is actually better and compliments the article.
I agree with some of the comments that paying hourly is more often better for the business requiring work than paying by project. The main reason is because by paying hourly, the risks of a project (e.g. running over, scope changes, etc) are taken on by the business. Well run projects manage these risks effectively and prevent overages (on average). When a developer is contracted by project, he has to first estimate his hours for the project and multiply it by his hourly rate. However, he then needs to add more hours to account for most of the risks previously mentioned because he is the one taking on responsibility for them. Further, one of the risks is scope change, which the developer does not need to account for in his project price, but because a change in scope requires additional overhead to manage by both the business and the developer in a pay-by-project model, guess who ends up paying for that overhead?
I think if you’ve had problems with an hourly model before, switching to a project basis with the same developers is not going to help. Bad developers are still going to be bad, and unethical developers will find other ways to screw you.
Max, would you mind posting how much you usually pay programmers? If you're getting programmers that meet your bad points, I'm assuming you're probably paying low rates. I just can't stand people who complain about the quality of work but don't bother saying how much they are paying.
You should replace "For a programmer paid hourly" with "For a poor programmer" because any programmer who takes his craft seriously would not pull such a stunt. A worthwhile programmer would realise that good short-term work leads to more long-term work. Shoddy short-term work does not lead to more long-term work for that particular programmer.
Like others have said, fixed pricing leaves you open to the developer cutting corners because it's now in his self-interest to get the project done as quickly as possible. Also, you have the possibility of wasting time haggling over anything that may have changed from the spec. Fixed price works for simple things but hourly is better for ongoing work or larger projects.
Just to add on to my comment, just because a programmer works slowly or introduces errors or bugs does not mean he is doing it on purpose. Trust me, I've worked with some programmers that were doing their best but they really weren't cut out to be programmers.
Just to reply to Matt’s comment: Just because the client thinks their programmer’s working slowly and introducing bugs, that doesn’t mean that they actually are!
E.g. maybe the programmer was “working slowly” because he was also writing unit tests and proper error handling. Maybe he was “introducing bugs” because your existing code’s highly coupled, and adding feature Z here breaks (or reveals a bug in) apparently-unrelated feature B over there.
Or, to go back to Matt’s point, maybe you usually hire cowboys and you’re now comparing them to a decent programmer. If you don’t know what good work looks like, all you’ll see is the extra cost.
+1
” If you don’t know what good work looks like, all you’ll see is the extra cost.”
Wow. If this post is supposed to cause controversy, I've taken the bait.
I'm sorry you've worked with so many dishonest developers in the past.
I almost never work on fixed bid projects because I believe that sets my client up for failure. In a fixed bid scenario when we're not getting the traction and positive feedback we anticipated, I can keep building something they don't need according to spec, or we can evaluate what they do need and change directions. On an hourly basis, it could make for a higher, or lower, total cost.
I value and respect my time, and thus I'm going to charge for it.
If anyone reads your article at face value, then they’re going to assume all programmers are incompetent and corrupt – and treat them as such. And that’s going to break relationships and ruin the project for everyone. You forgot to consider that the client might (also? instead?) be incompetent and corrupt.
It sounds harsh but, if the project failed, you failed to manage your ‘employee’ and that’s your failing – not theirs. If all you change is the way you pay them, that just moves the cost of your continuing failure onto them – and since it was your failure, not theirs, they’ll have to move it straight back to you in the form of higher prices. If that prices them out of the job, so be it – if they’ve any self-respect, they didn’t want to work with your bad project management anyway.
Maybe your next article should be “how treating your programmers’ or designers’ time and contribution as valuable is in your best interest” or “don’t change your terms – up your game.”
They should have these "Make sure you smile" stickers that are put on telephones in callcenters included in the wordpress interface.
Seriously, just because you were screwed by some programmers that doesn't mean they are all unmotivated fraudsters.
In the end it all comes down to the typical principal/agent problem. Your programmers don't know whether you're the kind of asshole boss that will let them do plenty of extra stuff before getting paid and you don't know whether you're working with honest, intrinsically motivated and – most important – skilled developers.
Here's how I do it: If a developer comes with a personal recommendation or has done previous work with me I'm fine with paying by the hour.
If a programmer works with me for the first time I will let them do a very specified task of the project for a fixed price first and then renegotiate what we're going to do with the remaining parts of the project.
Additionally, I found it very helpful to break the project down into as many iterations as possible (or reasonable).
” Additionally, I found it very helpful to break the project down into as many iterations as possible (or reasonable).”
Lazy “entrepreneurs” don’t want to do that. They just want a working prototype right now which will end up in production.
Actually, it's against your best interest to hire using a project basis. Very few good developers will work on a project rate, so just by pursuing this approach, you've excluded many your best candidates. If your developers are doing any of the things in your first list, it's a sign that you've blown the hiring process. Hiring on a project basis has the opposite effect in that your devs will attempt to inflate the price to accommodate the scope creep they expect. It's a race to the bottom.
The approach I would recommend instead is Optional Scope Contracts. You start with your best attempt at a requirements doc and buy packages of hours based on an overall idea of the complexity of the project. With that time you and your developers work together to manage scope and priorities. This aligns your incentives. Your developers want to be approved for another round so they do good work. You are paying the real cost for each feature that you request, so you can carefully weigh the true value of each feature against its cost. Google for "Optional Scope Contracts" and there's a great doc with more background about this process.
(Background: I've been a developer for 12 years and managed dev teams for 10.)
What happened to my three comments?
Oh, that is quite an interesting topic though I don't believe that any of these "laws of hacker employment" represents the whole truth. Slow hackers who produce bugs are probably demotivated by an uncreative and intellectual toxic environment. Hackers on Projects may also benefit from ugly cowboy coding because if it breaks they are already gone and all the money with them. Difficult, difficult, difficult ..