Before a project gets started, we need to agree with the client what to build. Often, the project idea is from a simple need of the client. With hourly-billing, it's natural to build upon a simple need, adding more and more fancy features. Because why not? Client would need it, and we can bill more hours building it.

Then we need to give a proposal for this fancy plan, with a budget estimation (price / fee). To get this budget estimation, we need a time estimation, since we are billing for hours, right?

After reading the draft proposal, a developer estimates: "For these many features, we may need two years."

"What? That's impossible! The client need it as soon as possible. Can we cut it to two months so it also fits into their budget? Just use the native style and whatever third party library you can find."

At this point, the project is already doomed. After all, good, fast, and featureful. We can only pick two. With a short time frame and a tight budget, we have to cut the only thing left in the equation: software quality.

Once the project starts with a fixed budget and a fixed timeline, every minute counts.

To ship the project in two months, a lot of meetings are skipped. Because a 1 hour meeting with 5 people counts as 5 hours. It's just cheaper to dive into design and code.

After two weeks of prototyping and coding, we finally ship something, only to find it's not what the user needs.

(This kind of story always reminds me of the old saying: weeks of coding can save you hours of planning.)

Besides, no one has written a line of automated test. Why? Because programmers know the requirements are definitely going to change. Changing and maintaining these tests are going to make our budget tighter!

At the end of the sprint, what we've got is an untested, useless application. We need to hack it to make it really useful to the user. It's what we call a Death March.

After we've finished the Death March, there's one last challenge before we get fully paid: generate the time usage report and justify for it.

Recording time usage is not easy. Most people don't have the habit of doing it. When we are asked how much time we spent on a feature, the only thing we can only rely on is our memory. So the time usage report we generate would be inaccurate.

Then we send the report to the client. Even if the report is accurate, the client would have a lot of questions. These questions would be difficult to answer, because few clients are familiar with software development. For example,

1. "Why did a simple feature ("centering things with CSS") took you an hour?"
2. "Why is the time usage not like what you estimated? Are you not following the plan?"

Due the coupling of how much time we spend and how much money we make, we want to spend more hours on a project. But what's our clients really want? Result! All they want is a product, a solution that can make their life/business better. This misalignment is the root conflict between our client and us.

Due to this misalignment, we may prefer a fancier solution that costs more time. But what the client really needs is a simple working solution, ASAP.

Due to this misalignment, we may have less incentive to improve, which are required to get a better result.

"With this new X, we can deliver the same thing in half the time! But how can we charge it the same as before? Maybe we wait until next time."

Due to this misalignment, we may center our internal conversations around how many hours we've spent, but not how many values we can generate. People tend to be misled by these conversions and thus lose their focus on value.

Due to this misalignment, we may lose trust from our client. If we are not really thinking from the value our client can get, they will find it out one day.

A better alternative must keep us aligned with our client, by focusing on what value we can bring to them.

The coupling of time and money makes the price calculation simple: Price = Hours * Rate. So scaling with hourly-billing should be simple, too. Our only two options are obvious, but neither of them are scalable:

1. Spend more hours in projects.

   We can do this by working overtime, which is not sustainable for our own health. And we would hit the hard limit (24-hour-per-day) quickly.

   Or we can try to multi-task on different project at the same time. I don't think it's possible for me or any normal human beings. But if you know how to do it without affecting the quality of your output, please do teach me. :)

   The last resort is to hire some junior people to spend their time for us. But these people raise our internal cost by a lot, not only with their hourly rate, but also a management cost.

   A better alternative should decouple the time we spend and the fee we get paid, so we can get a higher leverage.

2. Raise our hourly rate.

   To raise our hourly rate, we need to find more valuable clients. They value their projects more, they value our work more, and more importantly, they have more budget to afford a higher hourly rate.

   Then the question becomes "How to justify a $1,000 hourly rate?" A smart sales person would start from our client's perspective: "Our experience can bring you tremendous value. By finishing this feature in 5 hours, you would get far more than $5,000."

   This is the A-ha moment for me: if we need to "justify" our pricing from the perspective of value, then why not give a pricing based on value, so we don't need to "justify" it anymore?