Hacker News Reader

Comment by rossdavidh | Hacker News Reader

Great article, but one key difference missing from the software experience is that the person for whom you are installing the washing machine doesn't like it there, and wants it moved over to the others side of the utility closet so that when you open the door it is easier to put clothes from there into the dryer. Also, it's too noisy, we need utility closet doors that absorb more of the sound.

One primary driver of the unknowability of software estimation, is that the customer doesn't actually know, and perhaps CANNOT actually know, what they really want or need until they see something that isn't it. No amount of asking beforehand will bring out this information, and complaining afterwards that they didn't say that doesn't accomplish anything except souring the relationship.

Bill by the hour, and absolutely refuse to bill by the project. It's the only way.

View on HN

This is why bespoke software development is never ever primarily about the software, and thinking that it is is probably the biggest and most common misconception in the field. What it is, is helping the client figure out their processes/product/business model precisely enough to codify it on a computer. The rest is the easy part.

>> This is why bespoke software development is never ever primarily about the software

Let me rephrase: This is why bespoke software development is never ever primarily about the code

It has all to do with SW. The big problem is thinking SW=Code

But you are essentially 100% right

> wants it moved over to the others side of the utility closet so that when you open the door it is easier to put clothes from there into the dryer

That's when you swap the hinges so the door opens the other way, and you thank the manufacturer for providing such an easy solution to a common problem. It's good to keep things flexible and user-configurable.

Now quick, someone reply with a counterexample of how user configuration complicates the product and increases cost. It's design tradeoffs all the way down...

Do NOT bill by the hour. Bill the project as a fixed cost to get your foot in the door, but with a clause to switch to hourly for changes requested that stray from the original requirements, with a two hour minimum per change.

The pain of being billed hourly will discourage clients from requesting too many trivial changes.

> Bill by the hour, and absolutely refuse to bill by the project. It's the only way.

Or, bill by the project, but have an actual scope of work with details. Which will help you estimate the project cost and give you cover when something new comes up to increase the project cost.

Customers hate by-the-hour because they don't know what it will cost. Providers should hate by-the-hour because it ripe for abuse by the customer, who assumes you can do anything they want because "it's just another few hours".

Doesn't billing my the hour go against all of the contractor compensation advice given here on HN?

Not necessarily, that advice usually assumes that you either are the subject expert or that your job is scoped and therefore benefits from being able to rush a job to maximize compensation

If you can bill by the hour, you benefit from the customer figuring it out on the go, which will take longer, but also be better fitted (If you can make it work)

If your job fits in "I'll make your X twice as good" or "I'll implement this standard" bill by the project, so you don't get punished for being more efficient; if it fits in "we'll solve your software problems", bill by the hour and you'll be rich, because they won't run out of problems to throw at you

I feel like it depends highly upon the nature of the project.

I've worked with (and for) consultants and we typically billed by the project for things with well-defined scope, work, and outputs. (Maybe a small business website, or PBX system.) But we billed by the hour for things that were unfamiliar territory for us and forced us to learn as we go. Like migrating a bunch of data from an ancient proprietary database to Postgres.

Reply on news.ycombinator.com