Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Measuring gets a bad rap, but proper measuring can be very valuable to engineers as well.

If the company is only trying to measure developer productivity, they're missing the big picture. Developers will only get blamed when the number doesn't match some hidden expectation.

Good organizations measure a lot of things, such as tech support effort (mentioned in this article), roadmap churn, number of unexpected feature demands that derail forecasts, and other metrics that evaluate the company rather than laying blame on a single group.

Measuring roadmap churn and the impact of unexpected feature requests has been very helpful for me at metrics-heavy companies. When management starts asking why things haven't been shipped yet, it's amazing to pull out a quantified list of all of their unplanned requests, roadmap changes, and other management issues that set everyone back.

View on HN

I think a lot of the bad rap comes from how the measurements are used - I personally like to know my trends for how many hours/commits/etc I did in different areas during a time period. I use Wakatime[1] in my editor and love checking in every once in a while. However I would never ask everyone on my team to install it and share the dashboards, because then the measurements may be used the wrong way, e.g. "Alice did way more commits than Bob last week, so that's bad for Bob".

As another example I like using story points/velocity to get a feel for the team, but I don't think you can extrapolate on that data and expect the results to be valid. I think most of the frustration from devs come from the measurements being used to try to plan out the future when that isn't really possible. IMO you can choose a set of features OR a release date but definitely not both.

I'm no expert but I've read a fair amount on different strategies to try and make timelines for software and my big take-away at this point is "don't make timelines for software. If you _have_ to, then keep it probabalistic and don't promise anything by an exact date". I think we as devs need to kinda educate the rest of the business that it's a tradeoff between features and release dates. I like the "iron triangle" model but you can't just add more people to a team and expect things to be done faster (Mythical Man-Month), so it's really just scope VS release date.

[1]: https://wakatime.com

They help in the same way that a speed limit helps drivers. Sure, it actually makes the roads safer to some extent. Is there some amount of abuse you have to expect in enforcement? Yes. Is there some amount of unjust rule breaking that will happen? Also yes. Does it massively reduce the fun of driving? Also yes. If everyone just knew what they were doing on the road would it really be necessary? Not really. And do you need them for small, high-trust areas? Not really.

> And do you need them for small, high-trust areas?

OSHA would disagree, and even racetracks have rules.

I think a lot of developers on HN just have a problem dealing with the fact the rules are going to be applied to them. If you become an owner of a company your engineering rules go away, but then you have all the regulatory fun of a business owner trying to make a living and selling things at the same time. Working for a larger organization tends to have benefits like steady pay, but in return they ask for you to justify your expense and it's very possible the people asking for justification have no idea exactly what you do.

OSHA is not the ultimate authority, it's just one country's solution to the problem.

I don't have a problem with rules being applied to me, I just see it as dysfunction that any organization gets to the point that they need a significant set of rules. The more rules, the worse the dysfunction, typically. Exceptions include life-critical applications, where the entire existence of the company hinges on stripping human error from the product. But even then, more rules ≠ less problems.

This even works introspectively; it's a bit like fitness tracking. Is a little bit of data helpful? Yes. But who is out there reading into every time they got sick and missed a few thousand steps, or thinking about every utterance and flatulence during sleep and how it signals an overall moral failing needing to be addressed? People with mental disorders, that's who.

Somewhat tangential, but we have the already have the tech to know when license plates show up at a certain place, we know the map and the speed limits, so we could completely automate tickets for speeding. If the limit is 60mph and you show up 10 road-miles away in less than 6 minutes then you must have sped somewhere along the way, then the owner of the car gets a ticket in the mail.

In the short-term I think most people would hate this, but then I think we need to choose between raising the limit or following it. We all make the laws so we can raise the limits, and this approach completely removes the potential for abuse or playing favorites. As an added benefit it wipes out a lot of what cops spend their time on, so if you don't like cops we could justify having way less, or if you do like them then it frees up their time to focus on more important things.

I also recognize this opens up a huge potential for abuse by the govt having all this data, but we already have it for tolls so we might as well use it for good - having human police officers handle stuff like this is a huge risk for abuse and a waste of time.

> We all make the laws so we can raise the limits

How democratic is your country? Will the limits raise or will your government take the extra revenue and keep things unreasonable?

You will find that people have many different answers for those.

That would still be unjust, since there can be heavy traffic at the end which renders a speeder having driven, on average, within the speed limit. Bottom line though is that if you get too draconian with the enforcement, people will revolt. There is definitely such a thing as too much structure.. that's arguably the whole reason the US was created.

Could you share some specific tactics/metrics you've defined to measure things like roadmap churn or unexpected feature demands?

This problem definitely resonates with me, and I have some very primitive ideas of tracking (i.e. tagging tickets that fall into these buckets), but I would love to learn from your experience if you're willing to share!

Heh, I like how you were downvoted. I think a number of people here are a little bitter about their own negative experiences in companies and don't have enough self reflection to admit it's possible they could be part of the problem.

Reply on news.ycombinator.com