Tag Archives: cost

How Much Should a Developer Cost?

I recently went through the process of finding myself a new project and once more realized that at least 75% of the decision making for hiring a developer seems to be based on price. “You want – how much? Hey, I can easily find people who do it for 10 or 20% less!”

I am sure they can, for the whole “10 or 20% less”, if they just compare keywords like “Java”, “Oracle”, and “Maven”. Just as you can buy a car for $50.000, $20.000, or $5.000. While people are well aware that the price they pay has a substantial influence on the car they get, that fact seems to be ignored when it comes to hiring people.

The general assumption seem to be that once the overall skillset fits all developers are more or less the same. Well, that assumption is not supported by fact. How much does productivity vary really, you might ask? 10%, or maybe even 30%?

Tom DeMarco and Timothy Lister conducted annual public productivity surveys with over 300 organizations worldwide in their book “Peopleware” (which I strongly recommend). Here is what they found out:

  • The best people outperform the worst by a factor of 10 (that’s a whole order of magnitude)
  • The best people are about 2.5 times better than the median person
  • The better-than-median half of the people has at least twice the performance of the other half

And the numbers apply to pretty much any metric examined, from time to finish to number of defects.

Source: “Peopleware”, Tom DeMarco and Timothy Lister (Dorset House)

Wow! I am pretty sure that even a variance in salary of “only” 30% for the same job is rare, a factor of two is unheard of, and an order of magnitude is a feverish dream. And yet the performance of people you hire will probably vary by that much.

I originally had planned to continue with a long comment on what that means for the industry, for people who hire developers, and of course for the developers themselves. I am going to cut this short by simply suggesting a few things to employers and developers.

To employers

Keep the described facts in mind when you hire people. If you pay attention to quality even a larger difference in price is easily offset by substantially larger productivity – scientific research has proven that this is the case.

Think about how to interview for quality aspects. Comparing keywords or checking for certifications will not be enough, or will be even misleading. What does it mean if somebody says “I know Java”? What is their approach to programming? How would they define “good code”? How do they ensure they are a good programmer? What books do they read? What does the customer say about there work?

Regarding certifications: Certifications are mostly about being able to recall fact knowledge, and say nothing about practical experience and craftsmanship. In my personal opinion certifications mostly ensure that you looked into all corners of a specification, that you have seen the whole thing.

Taking Java as an example: It is good to know that you have Collections, Sets, Lists, and Maps in various implementations to your disposal. On the other hand, why would I need to know whether class Foo resides in package java.foo or javax.foo – it is completely sufficient that my IDE knows, or that I know where to look. That kind of knowledge doesn’t give anyone an edge over others, while practical experience in a number of different projects really does.

To developers

Highlight not only the technologies you have mastered, but also the quality of your work and your personal traits. Explain your approach to implementing a solution, what you value in good software, the books and publications you read to stay up to date and to develop your skills.

Provide some customer references that highlight your craftsmanship, that you write well structured, easy to understand, working code that comes with a high level documentation, that you are creative, innovative, professional, self-motivated, a team worker, easy to get along with.

The Cost of Quality: Two Hands, Two Bodies

Paying attention to software quality does pay off. Anybody who ever had to understand, repair, or extend existing software knows that lack of documentation (preferably on higher than code level), architecture, and coding guide lines, can turn maintaining even small amounts of code into a lengthy, risky and thus costly adventure.

Then why is software quality the first thing tossed over board, long before scope or – often arbitrary – deadlines?

Well, software works even with very low quality, if left untouched.

Having worked with a few large companies I found that the people benefiting from higher software quality are often not the same people that develop the software originally. Here is one concrete, real-world example.

Department A is responsible for initial software development. Department B is responsible for maintaining the software. B would clearly benefit from good documentation, architecture and so on once other developers than those comprising the original team are making changes to the software. But it is A that has to pay for additional quality that has little or no value to A.

What happened? Shortcuts taken by A mushroomed into exponentially rising costs for even the smallest changes by B, much to the dismay of the customer (department B, that is). Unfortunately there was no instance at the customer controlling cost of A and B in the context of the project they worked on.

That this won’t work is obvious – A has no incentive to spend extra money, and B has no influence on original development. Sounds contrived, unrealistic, and exaggerated? I wish it was…

So: If you find yourself in a similar situation try to find a sponsor that sees both sides, and inform him or her that investing in software quality pays off when the whole process is taken into account. Or at least inform somebody responsible for departments A and B that major and easily avoidable money wasting is in progress…

Prerequisites for Offshoring

One of my clients was trying hard to outsource software development, and has implemented processes for identifying candidate projects. The rules were pretty reasonable:

  • Existing software is documented in a suitable way (from requirements over specification and design to programming and rollout). “Suitable” means “competent people without prior knowledge of the project have access to enough information to extend the software successfully with reasonable effort”. That, by the way, is a pretty good definition of the quality any documentation should have.
  • The customer is aware that development is being done offshore, is willing to live with that, and accepts that documents provided by him to the project and documents produced by the project are written in English.
  • Processes are in place that allow for clear specification of stable requirements, and clear separation of phases and responsibilities.
  • The offshore workforce is reasonably stable so trained personnel is available over a longer period of time.

The problem was that pressure to increase the amount of offshored projects was so high that projects got moved to India, no matter the cost – ironically.

Here an example of a gone wrong (= more expensive then before) project transition:

  • The existing software was developed under high pressure, meaning “coding before design” and “we’ll do documentation when we have time”. That meant no overall design, and no documentation.
  • The customer did neither produce nor accept documentation written in English. All documents exchanged with the customer had to be translated at additional cost that couldn’t be billed to the customer. Translation was done in India, and results had to be proof-read by German personnel.
  • Because of sluggish processes a of lot of time got wasted between the customer voicing a request and the production of usable requirements.

The offshoring guidelines were very reasonable, but they were completely ignored. I can’t give any other advice than to “stick to the plan”, if the plan is reasonable.

Comparing Work by Cost Only

A company I worked for recently stated that “the internal hourly rate has to be brought down to xy Euros” in order to compete with other companies. This argument was mainly made to emphasize the importance of doing more (cheap) work off shore, thus lowering the average hourly rate.

Somewhat concerned I looked at the sentence for a while, thinking about whether this might be hinting at an unpleasant development that could have implications for me as a freelancer (I never ever have worked for as low as xy Euros per hour).

Then I relaxed.

You only may compare prices for specific services rendered if you are talking about the same kind of service, “the same kind” as in “same amount of work done per unit of time” and “same quality”. When buying a car you would never look at the price only: What make, what model? How old is it, what is the mileage, what is the condition?

Compared to German programmers, offshore resources only cost a quarter – on paper. In reality, the offshore partner regularly puts more people at the same task then the German side would. Some key people of the offshore partner will receive training on the project in Germany, and there will be a permanent on-site manager. So, add travel and hotel expenses, plus lost work time on the German and offshore side.

What if the customer doesn’t like documentation in English, and the offshore partner does not understand German? Ka-ching, add cost for translation, and load your tolerance module for accidentally introduced errors. And then, oops, personal that was trained in Germany leaves the offshore partner for sunnier shores. In the end, the cost is closer to 75% of the German rate.

“75% of the German rate” still doesn’t sound all bad. But this is for the development portion only. Sales, marketing, project management, requirements analysis, specification, design, testing, and roll out is all done in Germany. Development maybe is one third of the overall cost. In the end you would save about 8%.

“Saving 8%” is not nothing, right? Yes, but are you sure there aren’t any other ways to increase productivity, which essentially means getting more bang for your buck? Offshoring often has the side effect of alienating people working for you “at home”, and in my personal opinion offshoring is doing your local economy a disservice.

Why do people start with offshoring when they try to save money? When optimizing a program you start with an analysis first, identifying the code where most of the time or memory gets consumed. It is here that optimization effort gets you the greatest effect.

Blindly aiming for a lower hourly rate by using offshore resources is a brute force approach that does not look at underlying causes that drive cost up.

There are quite likely easier ways to improve productivity then transferring work abroad. Analyze your cost structure. Start working on the biggest items first. Review you processes. Educate and cherish the people working for you. Try a little harder at home!