Hacker News Reader

Comment by blowski | Hacker News Reader

Because managers also have managers. If the managers at the highest level think developing software is pretty similar to packing widgets in a factory, they understand and want to see the Frederick Windsor Taylor school of management in the engineering department.

For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.

But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.

View on HN

This is why I'll never work for anything but smaller startups. That sound awful and counter to how software should be done.

I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.

> I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.

I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?

I have personally also tracked time on my personal projects. While not sure if it does bring much value, it is not a huge investment time-wise.

I think that's not the point OP is trying to make. There's nothing wrong with tracking time for yourself, or clocking in and out of work. Time however is a really really bad measure of productivity. If somebody constantly stays late at work because they never finish stuff on time, in our current culture they often get promoted for being hard workers. While some might do the same job in 2h that they do in a month.

So what the super productive guy learns after a while is that they just need to "work overtime" and delay presenting results to get ahead. If this attitude starts pervading your team the productivity might start tanking too.

> Time however is a really really bad measure of productivity.

Situationally. With programming there are loads of different tasks. For some tasks I think time can be quite a good metric. Still, metrics matter and I think having lousy metrics is better than not having metrics at all. Of course you have to realize what purpose the metric has in certain situation.

> I think having lousy metrics is better than not having metrics at all.

I fundamentally disagree. Metrics don't live in their own world. They affect the world around them and incentivize certain actions. Bad metrics can produce bad incentives. There are certainly many cases where simply not knowing something is better than knowing something that's only partially right. However, that requires a level of humility and acceptance of one's limitations that can be hard to defend to others looking for straight answers to all questions.

Well, very situational question. My question here is mostly, what are the bad incentives caused when people time track their days for example in with 1 hour or 0,5 hour granularity with software development tasks? I have been doing that kind of tracking both professionally and in personal projects, and I don't see the harm caused.

Fair enough. I mean I guess I wouldn't go so far as to claim that time-tracking is an obviously bad metric. However, I would definitely claim it can be poorly utilized. This metric is just a tool. Employed effectively it can increase performance. Employed ineffectively it can increase...time.

But generally I think my main point stands. We need to be humble enough to sometimes accept lack of control (i.e. not using certain metrics/processes) rather than deluding ourselves by through certain metrics that really aren't very good.

The problem is not the tracking. It is your boss coming over after 3 days asking why this 1 day task is suddenly taking 3 times as long, and how much longer do you think it will take?

Never mind that the task spec changed 5 times in those 3 days.

This 100%. "What gets measured gets managed" is a 70 year old quote by Peter Drucker and it is no less true today. It reminds me of a great anecdote by Mark Graham Brown about "chicken efficiency", which is a great term to describe these situations. https://corporater.com/en/the-chicken-kpi-be-careful-of-what...

Isn't it the most basic rule of any information-based analysis that having wrong information or unreliable one is worse than not having any?

Because: 1) you know what you are lacking 2) you won't take action on wrong information.

If you're a doctor deciding whether to recommend a risky surgical procedure, you certainly don't want to jump the gun when reliable information hasn't yet come in. It surely will do in due course, if you're patient.

But if you're a manager giving out raises to your team, taking no action (i.e. giving no raises) might seem a worse choice than using the unreliable data - and there's no expectation reliable data will arrive if you wait.

Tracking time spent on various tasks can be useful (if not required, eg. for claiming R&D grants). But I feel like tracking time in office/time at desk is a different beast.

Happy employees, at a certain level of knowledge work, have a degree of autonomy.

Unhappy employees who could otherwise be happy employees are a waste of potential and money.

Having a clock on/clock off and a 9-5 butts-in-seats management style and incentive structure reduces perceived autonomy.

You like being micromanaged and told what time you need to be in and out of the office everyday?

>I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?

I don't agree with using it as a slur, but I do think it's an awful way to work in a creative field. Some of my most productive work happens as a direct result of my taking breaks - a walk here, a cup of tea there. All the while I'm thinking about the problem at hand. Time tracking discourages this of lateral approach in favor of brute forcing your way to the answer.

> For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.

I would like to understand why on earth time tracking is against "genuinely good engineering practices".

Would you do time tracking for someone writing a script for a movie? Or for a painter? Writing code not only requires skill, it's a creative process. You not only need to think about what you write, but also need to stop and relax. When your mind is tired, you're going to write shitty code. It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow. Worst case scenario, everyone writes bad code, unnecessarily increasing complexity, making the code prone to failures and requiring more rewrites, more developers and more time to understand it.

I don't follow how that is related to time tracking.

I have used time tracking for personal projects and also professionally and I genuinely think that it can add value to my workflow, in a way that I can analyze how much I spend on certain tasks etc.

I would guess also painters and script writers track quite often track their time. I think some level of time tracking is good for almost any level of work. For example, if your goal is to produce paintings and sell them for living, you probably want to know how long does it take for you to produce something so you can see if you are approaching sustainability. Similarly if you write movie or tv scripts it is probably relevant whether it takes 2 months to write the script or 2 years. Some work is just structurally different so different approaches to time tracking make sense.

You're talking about two completely different levels of granularity. It's fine to discuss "what did we accomplish this month" and try to quantify it. It's not fine to ask a script writer why they didn't write any lines between 8:30 and 9:00 this morning.

Personally the software development tasks I have been doing are quite often separable in tasks that take several hours. Sometimes there are tasks that take days without clear separation.

I think asking whether it is discuss "whether you did line this amount of lines within X hours" is more like management and workplace culture than software development issue. It seems that people here are fed up with their managers and funnel that bad feeling against time tracking. In my opinion time tracking is valuable tool and should be used in principle almost everywhere. Bad managers of course make any type of work a pain.

I always found a strong disconnect between what the business side thinks is meaningful and what an engineer and his technical manager finds meaningful. Typically the detailed granularity just isn't there and the data is really noisy as well.

More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.

Heh, presuming management knows what a hard feature looks like. Or understands the reason why it is hard. They sometimes conflate a patch, a hairy patch or writing correct code from start.

Bonus points if said manager does not understand that writing tests makes one go faster rather than plugging the code and trying to run scenarios manually...

One of the things I now always do is tell my boss both how much work work somethings going to be and how 'hard' something is going to be. Features/changes that are hard have very unreliable estimates. A lot of that has to do with how difficult it is to reason about and debug the feature. And how much other stuff needs to be changed.

When I know ahead of time exactly what the code I’m about to write will look like, I takes this as a warning sign and check in with myself.

Why do I know exactly what this code is going to be? Is it because I’m doing something repetitive? I’m a software developer. My job is to make the computer do the repetitive parts, not get paid for spending four hours doing something we’ve done ten times before.

Mastery isn’t doing more, it’s about being more effective. You develop intuition. And the way your intuitive brain surfaces warnings is as discomfort. If you cultivatea sensitivity to this discomfort it means you are adverse to powering through. On some level you “have to” address this issue instead of tolerating it. You have to scratch.

Now you’re not doing rote work. How long will it take? Who knows. But it’s less time than doing this thing eight more times this year. And it’s not just time. It’s energy and face. A repeated process that can introduce human errors makes you look like a clown to your customers, and your boss’s boss.

I also sometimes track time, so I know how long takes particular task. Good developers do this and can quickly estimate project’a complexity by breaking it into known length tasks. I saw this in a highly specialized consulting company. My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. This time tracking thing can become very ugly in micromanagement environment.

> known length tasks.

I think the only known-length task is a completed task.

Known exactly, maybe. But when I was a consultant we had a pretty good idea of how long it took to do a good job on a project.

We'd add in some padding because you don't know if something will need a bit more research or if the lead is going to come down with the flu or whatever. You write deadlines that are under the client's control, rather than yours, into the contract.

So you don't know exactly. But if you have a decent handle on the scope of work and aren't trying to solve wide-open problems, you can usually get pretty close.

Certainly, a lot of people don't have this level of experience in a domain. When I do similar work internally at a company now, people are often surprised that I can come up with time estimates (and meet them) pretty easily.

You know how long your budgeted for it. Which is fine up to a point, but when things go over budget then corners get cut. And that costs in time further down the road.

I suppose you can always spend more time but the type of work I did didn't create downstream dependencies. There was no maintenance. (It was reports, competitive analysis, and the like.) Although I can't ever recall a situation where we were like:"It's not good. But it's good enough. Ship it."

That’s the kind of work that can be automated. You’re arguing with people who are doing new feature development almost exclusively. These are apples and oranges.

And frankly if you get too smug about it in a work environment you’re going to antagonize someone into scripting your job out of existence. So I wouldn’t pull on this thread too hard if I were you.

When a task is of known length is the time to automate it.

Movie scriptwrites are not getting paid per hour though. What they get paid for a script is unrelated to the time they spent.

Do you think software developers get paid for completing the features or for the hours spent hitting keys?

Typically employed developers get paid per time (i.e. hourly or monthly salary). Contractors may be either per hour or a fixed sum to deliver to an agreed-upon specification.

With scriptwriting (and often art in general) you first develop the "product" and then try to find a buyer. This is IMHO not a feasible model for individual software developers.

I realised years ago that getting paid per hour is anathema to my enjoyment of work. I'd much rather charge per project (even if that charge is based on an estimated number of hours) then spend whatever time it takes to complete the project than work at an hourly rate and find myself staring at the clock.

Opposite for me! In my experience, being payed a fixed sum for a project requires a very detailed spec up front and still may lead to bickering about whether any issue is a bug or a feature request. Being paid by hour makes it possible to continuously adjust the project without either party getting screwed.

> Would you do time tracking for someone writing a script for a movie? Or for a painter

If change the flattering comparisons then why not? Instead of someone writing a script for a movie, imagine it is someone writing sales copy. Instead of a "painter" presumably working on some masterpiece, imagine instead it is someone in one of those Chinese factories churning out still life 3265.

Most programming tasks are well understood - most programmers in big corporations are working on CRUD apps. The correct comparison is not to some highly creative process but to some semi-creative process. Sure the details might be different but in the main it can be well understood how long it takes to add crud screen 26.

I guess pg himself popularised the flattering "programmers are just like painters" nonsense: https://idlewords.com/2005/04/dabblers_and_blowhards.htm

It's up to you to choose a more creative engineering job that almost requires you to be a painter (or a screenwriter). Sometimes it's the jobs that are product-level slash engineering, sometimes it's purely engineering ones that require a lot of innovation. If you are a creative type and if you want to make your life more interesting, you will be attracted to these jobs.

> It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow.

I'm on the fence regarding this statement. If you are accumulating increasing amounts of fatigue by being there and writing bad code, then yes, go home, rest, and recover. But, optimal is the enemy of good. Write some shit code in your own branch, learn from the mistakes you made, so that the code you write tomorrow might be "the good code".

It increases anxiety and stress, which probably decreases productivity to a much greater degree than whatever benefits you'd get from time tracking.

I suspect the number one factor to a successful project is a happy, healthy team. I'm pretty sure there's a section in Peopleware that backs that up. I'd be really careful with any approaches that risk losing that dynamic (or preventing it from forming).

Because making software is like oneoff or small batch production as opposed to a traditional production line.

Engineering practices vary wildly depending on what type of engineering you are doing.

That's one of the problems they had when developing BS5750 and ISO9000 , "where do you hang the defect ticket" was one of the areas where they had problems - that was what the head of the BSI software quality project told me back when he was auditing a project I worked on ack in the 80's.

It's easier going the other direction: what is time tracking good for ?

Tailorism was good for simple, repetitive and immutable tasks, where the only planned improvement would be the worker. If the task was to be revised, it would be top down from an 'analyst' that designs a new task and test it on workers.

What changed this perception ? Toyota like factories, and the idea that tasks should progressively evolve, workers can change their environment in non top-down ways. The metrics was not how much time it took to do a single task, but how much the whole pipeline was efficient.

It's just an example, but I think time tracking should be a relic of the past, as an idea that was too simplistic and too seductive to micro-managers to be really valuable.

From a throughput management perspective for more office-like work:

It's easy for one person to increase in time-tracked productivity in ways that decrease the aggregate productivity of the group they are in.

Sometimes, the person is happy with their own work and unhappy with everyone else's, and they have a blind spot because it's so hard to understand how improving their own productivity can slow down other people so much to be net negative.

But I've seen it, I think it's real. I think it's sometimes a very strong effect, which can make or break a business.

Just like manufacturing pipelines, people affect each other's work in non-linear ways that clog up the system.

As with pipelines, performance improvement lies in working with those non-linear dynamics well enough to reconfigure the system, so each person can excel at their best.

Reply on news.ycombinator.com