Heisenberg Developers (2014)

#1

Post by shenoybr » Wed, Jun 22, 2016, 7:58 PM UTC

Heisenberg Developers (2014)
mikehadlow.blogspot.com

Re: Heisenberg Developers (2014)

#2

Post by kuharich » Wed, Jun 22, 2016, 8:50 PM UTC

Previous discussion: https://news.ycombinator.com/item?id=11024656

Re: Heisenberg Developers (2014)

#3

Post by desireco42 » Wed, Jun 22, 2016, 9:11 PM UTC

This is probably one of the better posts about development I read this year, full of sound bites, like "Jira strikes fear in a heart of every developer". I just love it and can read it occasionally nodding my head.

Re: Heisenberg Developers (2014)

#4

Post by mikerichards » Wed, Jun 22, 2016, 9:14 PM UTC

Been there, seen that. Nebulous, pie-n-the-sky requirements coupled with PMs that don't understand software development and probably don't even understand the product.

I feel bad for PMs, because there is a role for them - just usually not the role that they've been assigned to. PMs tied down to small teams usually causes problems. PMs should be facilitating inter-team development. I believe tech-leads and BAs should be assigned the role that PMs seem to find themselves in when they're assigned to small teams.

And please PMs, learn what the product is all about. Too many times I've seen PMs actively not wanting to know what the hell the product is about and instead love getting bogged down in process (and of course meetings).

Re: Heisenberg Developers (2014)

#5

Post by vvanders » Wed, Jun 22, 2016, 9:26 PM UTC

mikerichards wrote: post #4

Been there, seen that. Nebulous, pie-n-the-sky requirements coupled with PMs that don't understand software development and probably don't even understand the product. I feel bad for PMs, because there is a role for them - just usually not the role that they've been assigned to. PMs tied down to small teams usually causes problems. PMs should be facilitating inter-team development. I believe tech-leads and BAs should…

Yup, your PMs should be the one unblocking your developers and not randomizing them in return.

The best PMs I ever worked with I could come to with "I need X from the organization" and within a few hours or less I'd be unblocked and could move forward. The other type that pester developers are poison and should be thrown off the boat for the reasons listed in the article.

Re: Heisenberg Developers (2014)

#6

Post by beatpanda » Wed, Jun 22, 2016, 9:27 PM UTC

I don't identify with this at all. One of the first things I started asking for at my most recent job was a better, more clearly-defined process so that we knew exactly what we were building, what it needed to accomplish and what does "finished" mean. I largely got what I was asking for. Its made our engineering team a lot more focused and enabled us to deliver faster than we were before. It also makes it easy to figure out what to work on next.

Maybe the difference for me is that software engineering is my job, not my lifestyle or identity. I don't know.

Re: Heisenberg Developers (2014)

#7

Post by outworlder » Wed, Jun 22, 2016, 9:35 PM UTC

beatpanda wrote: post #6

I don't identify with this at all. One of the first things I started asking for at my most recent job was a better, more clearly-defined process so that we knew exactly what we were building, what it needed to accomplish and what does "finished" mean. I largely got what I was asking for. Its made our engineering team a lot more focused and enabled us to deliver faster than we were before. It also makes it easy to fig…

Maybe the difference is also what you are working on, or the stage the project is in. Or the level of understanding of the business requirements from everyone involved.

However, this case appears to be micromanagement, pure and simple. Micromanagement is "way too much of a good thing".

EDIT: Don't forget the pie-in-the-sky requirements. If you have sane and straightforward requirements, then you can usually break them down without too much drama. But, if they are that simple to break down, should they even be?

Re: Heisenberg Developers (2014)

#8

Post by capote » Wed, Jun 22, 2016, 9:38 PM UTC

I think time pressure is the worst thing cited here, and it's the reason I tend to stay away from methods in which I sense agility.

The time estimate and completion time features on tools like Jira make my insides sink a little bit. I think it's somewhat difficult to know ahead of time exactly how long something will take to implement, and, even worse, committing yourself to that puts pressure to ignore unforeseen events or complications or to not take care of them properly. I'd rather be extra careful than quick.

Assuming your team isn't massive or out of control, I think it's possible to have trust in programmers that they won't muck about and will deliver work in the time it takes to deliver the work--which for a good programmer isn't affected by management or Jira or estimates. It's just a constant.

Re: Heisenberg Developers (2014)

#9

Post by Tenoke » Wed, Jun 22, 2016, 9:42 PM UTC

I definitely see where he is coming from but throwing out all management and issue tracking (although yeah, jira is pretty bad) is definitely not always the answer. There are plenty of examples of teams for which fine-grained issue tracking has worked, as well as counter-examples like this one and it is hard to take this post as more than a generalizing anecdote.

From what I read, it honestly sounds like maybe things started slowing down because 1. development generally slows down as a project becomes bigger (even when keeping technical debt in mind) and 2. Because of a shitty feature request. Yeah, it sounds like the PM didn't help either but it's not clear to me that they were the biggest problem here (although it is true that PMs can definitely be hit and miss, even more so when hired in the middle of the project's lifecycle).

Re: Heisenberg Developers (2014)

#10

Post by stronglikedan » Wed, Jun 22, 2016, 9:48 PM UTC

capote wrote: post #8

I think time pressure is the worst thing cited here, and it's the reason I tend to stay away from methods in which I sense agility. The time estimate and completion time features on tools like Jira make my insides sink a little bit. I think it's somewhat difficult to know ahead of time exactly how long something will take to implement, and, even worse, committing yourself to that puts pressure to ignore unforeseen ev…

We have a client that needs to know up front what things will cost, so that it can be budgeted, and the budget approved. They get a SOW (as tight as we can get it), and an estimate (which, to them, is a quote). The estimate is whatever the developers have estimated the tasks to be, multiplied by three. It seems to cover us in most cases, and the client happily pays.