
Heisenberg Developers (2014) - shenoybr
https://mikehadlow.blogspot.com/2014/06/heisenberg-developers.html
======
kuharich
Previous discussion:
[https://news.ycombinator.com/item?id=11024656](https://news.ycombinator.com/item?id=11024656)

------
Tenoke
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).

~~~
beatpanda
I don't understand all the JIRA hate, my team has 0 problems with it

------
ebiester
I feel like the problem came at the beginning: there was a requirement that
was a difficult problem, and the developers needed to take the time then and
do some Big Design Up Front to the point that they could get the users to
collaborate in a solution to understand how Big a problem it was.

The team also needed to evolve, starting with a very small implementation and
evolve it to handle each additional use case in a way that the stakeholders
felt there was progress in their biggest pain points.

It's an experienced lead that takes their hands off the keyboard for a few
weeks and immerses themselves in the social problem. (And yes, sometimes it
means breaking big problems into small pieces as a team and organizing around
the work in separate steps, even if that feels unsatisfying.)

------
mikerichards
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).

~~~
vvanders
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.

------
capote
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.

~~~
2muchcoffeeman
I used to hate all previous attempts at being agile. But my current workplace
gets it more right than wrong.

People over process right?

~~~
capote
Maybe it's just whichever process matches the people and vice versa.

------
desireco42
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.

------
vchynarov
I view this post as being a rant against this particular shop with potentially
subpar management practices which is frustrating, and I sympathesize.

However, if you intend this as an argument against general software project
management, I must disagree. (See: "He introduced us to ‘Jira’, a word that
strikes fear into the soul of a developer.")

Lately I've had the opportunity to work at a place with very forward-thinking,
progressive, and helpful PMs and generally good organizational structure.

I like our approach and here is why:

* We are not afraid to change things. This might lead to some temporary disagreements between technical leads and PMS, but EVERYONE in the team has transparency into the process, and an opportunity to voice an opinion.

* We taking scoring tickets very seriously. I've been at places where everyone on a team might vote on a ticket, even if they cannot appreciate the true scope of it. Here it's different. For instance, we have seen that in the last couple of weeks, our velocity was unusually high. This might indicate we are scoring tickets too highly, and from what I've seen of my own work, I'm inclined to agree.

I've had a length interview with a PM who spent some time afterwards telling
me about his metholodogies (I gladly listened.) When given the choice between
Gantt charts which have cliffs (indicating poor future planning and rushing to
get things done last minute) and nice step-ladder charts, we see why PMs
prefer things the way they do.

Sometimes it gets in the way of just writing code sure. But with good
organizational structure, especially in a mid-size company that has upcoming
deadlines and business features to ship, we identify priorities quickly while
still being aware of things like reducing code debt.

------
alexmingoia
You can't have your cake and eat it too. If managers want accurate estimates,
they need to allow just as much time planning and estimating as they do for
developing. And requirements must be frozen.

Just look at construction - spend years planning for 6 months of development.
And there are still schedule overruns!

Sure, you can have detailed estimates. But every company I've worked at wants
detailed, accurate estimates with maybe one day's worth of planning. Often
they want "guesses" or "rough estimates" on the spot, literally seconds after
telling you what they want. I've also never come across a single company that
actually froze requirements.

And every developer knows what happens when you say you can't give an accurate
estimate quickly: They demand you make a guess anyway and that becomes the
estimate. If you give a range, they'll take the minimum as the estimate.

------
holtalanm
I think it really depends on the level to which you use tools like JIRA, and
it also depends on how involved the developers are in the project planning.

We use JIRA, but our PMs understand the importance of fixing things that are
broken. Refactoring code is usually added as a subtask to stories that have to
deal with the code that needs refactored.

I will agree that micro-managing is not a good way to do software development,
but many times if you just go pure laissez fair then a lot of times projects
go off the rails.

------
beatpanda
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.

~~~
greenyoda
_" so that we knew exactly what we were building, what it needed to accomplish
and what does 'finished' mean"_

That only works when the people who are asking for the software know what they
want. In the situation described in the article:

 _" The one where you try to replace an expert user’s years of experience and
intuition with software. What started out as a vague and wooly requirement,
soon became a monster as we started to dig into it."_

In my experience, the business people aren't good at turning vague and wooly
requirements into precise specifications for software - they're not trained as
logical thinkers. Usually, that job falls on the developers, who will try to
clarify the requirements until they have something that's precise enough to be
translated into logically consistent code. This may involve a lot of trial an
error, since trying to extract the requirements from the business people is a
non-linear process (e.g., they can change their minds on what the spec is, and
a seemingly small change in the spec can have a large effect on the
architecture).

