Hacker News Reader

Comment by nickjj | Hacker News Reader

It's really eye opening to read something like, knowing it was written in 1971:

> It is not unusual —although a mistake— to consider the programmer's task to be the production of programs. (One finds terms such as "software manufacturing", proposals to measure programmer productivity by the number of lines of code produced per month etc., although I have never seen the suggestion to measure composer productivity by the number of notes, monthly scribbled on his score!).

47 years later, a lot of people still measure programming productivity by LOCs. Hell, even major freelance marketplaces try to track your every billed second by taking screenshots of your desktop or webcam "just to make sure you're working".

View on HN

> Hell, even major freelance marketplaces try to track your every billed second by taking screenshots of your desktop or webcam "just to make sure you're working".

Well that's some dystopian nightmare stuff I had no idea was happening.

EDIT: refine quote and add italics

A big part of the problem IMO is the software development community has gravitated toward rate compensation instead of product compensation. A composer is commissioned to deliver a product and is compensated for said product, not for the time he/she worked to create the product.

This was real eye opening for me when I did contract/consultant work, even as a 1099. I can understand the enterprise, butts in the seat model of developers being on retainer but for contracting houses I don't get it.

If developers don't want to be bound by these metrics they need to get better at forcing the client into contracts for deliverables with clearly defined acceptance criteria. Also, it seems to me that the best way to get proficient and creating and updating these contracts is by having to work twice as long to deliver a work product as was initially estimated.

I'm not very optimistic that we'll ever be able to reach that utopian state, though. After all, the only person in the fixed-bid equation with any incentive to nail down requirements up front is the developer - it's in the best interest of the buyer to be as vague as possible so that they can defer actually making any decisions until they've had a chance to see the finished product, when the consequences of the decisions are most obvious. Then they can turn around and say, "the requirements clearly state that..." or in other words, you're going to be working for free. Once you get up into even five-figure bids (never minds something that might take a year to deliver), the people writing the checks are happy to put more effort into deliberately obscuring the requirements gathering process than actually gathering requirements, just to keep their options open, and they have a legal department that you don't.

I hear what your saying but there's a whole host of other fields that seem to pull it off. Other than the fact that software is not bound by physical constraints, I really don't see the major differences.

I think we're just fighting the "always done this way" mindset.

A lot of developer contract work doesn't fit into a fixed bid model.

What if someone hires you as an ongoing general problem solver?

I've had many contracts like this for 4-5 months where they just threw problems at me and expected me to think of a solution and then implement it.

This could be anything from little scripts to make development better, ops / deployment improvements, better docs, being a 2nd set of eyes for pair programming, etc..

Something like that isn't really possible to plan out, so paying by the hour makes sense.

On the other hand, I do fixed bid pricing on a lot of things when it makes sense. I sometimes even do a hybrid approach where it starts as a fixed bid and ongoing maintenance becomes hourly.

Something I'm forced up against frequently at a company that provides fixed bids for projects and refuses to bill anything hourly: How do you determine a fixed bid for fixing or modifying an existing product you're unfamiliar with?

If a client comes in and says "one out of every 50 times you load a page in this web app, it renders a blank page, how much is it going to cost to fix?" what do you say?

Every hour you spend investigating or familiarizing yourself with the problem is basically just spec work with all the risk that entails. In many cases when you're "fixing" something, the project could be entirely spec work as you spend 8-16 hours determining that the problem is simply a misconfigured setting that will take 5 minutes to flip.

Clients very rarely (in my experience, never) specify problems to a degree sufficient to create a concrete scope of work, and they're not going to pay you hourly to do so.

If I take my car to a mechanic and say "it makes a funny rattle sound, how much will that cost to fix?" he's not going to give me a fixed bid.

The more unfamiliar it is, the more inclined I would be to use hourly billing. In your blank page example I would bill by the hour.

> track your every billed second by taking screenshots of your desktop

Wow, that would definitely trigger my neurosis into a full-blown nervous breakdown. Does reading e-mail count as "working"? Does configuring environment variables and adding printers count as "working"? Does reading documentation count as "working"? And don't you dare stop by and interrupt me with a "quick question"...

I am a freelancer but fortunately I don't use such platforms so I can't answer your questions specifically.

But, there's a lot of talk about it online. Google for "upwork time tracking" and similar queries and you'll find heaps of people complaining. Upwork is just 1 marketplace that has apps like that.

> Hell, even major freelance marketplaces try to track your every billed second by taking screenshots of your desktop or webcam "just to make sure you're working".

Think of that as a very clear way to indicate that you shouldn't work for them if you have a choice. Pity those who have no other options.

Reply on news.ycombinator.com