
Heisenberg Developers (2014) - Sidnicious
http://mikehadlow.blogspot.cl/2014/06/heisenberg-developers.html
======
CryoLogic
One issue with how developers are hired these days, is many large companies
are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS)
and mathematical ability. Try interviewing at MS, big G or Amazon and you will
see what I mean.

These developers are great as code monkeys, but a lot of them don't have any
idea what their code contributes to, or even how their business makes money. I
attended a hackathon with a number of Amazon employees, and one of my distinct
memories was a Principal Engineer who didn't even know what "publicly traded"
meant and was sure that Bezos owned 100% of the company.

A potential solution to this issue, is to hire engineers with more diverse
skillsets. Deep understanding of mathematics and classical algorithms is
fantastic for software performance, and low level details.

On the other hand, at a tech company - your software is literally your revenue
stream. You are hiring people who don't understand your business - to build
and grow your business.

Maybe hire some developers with strong business skills, and a good
understanding of the economy and your market - and put them on a team with
more traditional engineers. In doing so, you get someone with the big picture,
and someone with the details working together and might not even need another
PM.

Just my thoughts.

~~~
rorykoehler
Anecdotal I know but I've been told that my business knowledge and curiosity
is not welcome nor wanted whilst developing and that I should be more single
minded to churning out code. We live in an economic environment where
specialisation is valued over all else. Polymaths and generalists struggle in
this environment unless they found the business themselves or are lucky enough
to get picked up by a large company to head up a team.

~~~
CryoLogic
I spent my teenage years building fan sites and social networking sites for
games. I made enough money to pay off college, get a nice apartment by the
water and have a couple k leftover come graduation.

I was curious why I wasn't getting a lot of hits on my resume, so I talked to
a recruiter at a networking event who had seen my application (for one of the
"unicorns") and she said they where uncomfortable with how entrepreneurial it
looked.

I removed the sections from my resume, removed all of my contract work too -
only listed the internships and found some other grads (that got jobs) resumes
to copy the language style. Pretty much instantly my resume was getting me
double or triple the interviews.

Bummer too, because I worked my ass off and always had the false impression
that employers would like that.

Sometimes its the gap between marketing (how they want the company to appear)
and HR I think. Marketing wants innovators, HR wants workhorses that move in a
strait line and don't try new things.

~~~
shiftb
That's odd. We get excited when we see an entrepreneurial profile like yours.
We have several developers who want to start companies and actually try to
help them along that path.

The benefit to a motivated engineer is you can give them problems to solve
instead of specs. The outcome or results can be less predictable but can also
be much more effective.

~~~
rorykoehler
How do you feel about the potential for high turnover with entrepreneurial
types, as it seems the general consensus is they will inevitably leave to
start their own thing? How long do you expect someone to work for you before
hiring them, getting them up to speed with your system, and integrating them
into the company is a worthwhile investment?

~~~
golergka
When I get asked this in an interview, I always answer the same way: yes, I
will probably go to the next gig faster than other employees. But I will get
up to speed faster, and I will produce more output for the business itself in
the time I'll spend in your company.

~~~
rorykoehler
This is the reality but my question was more about perception vs reality.

------
vinceguidry
This is one of those wishful thinking rants that serves to highlight the rose-
colored glasses many developers see the business world through. All good
things eventually come to an end, and you need to be ready for the inevitable.

The author described two perfectly good responses for this scenario, and
managed to paint them both as the cowards path. Leaving the company, and
checking out mentally, letting the people with the responsibility hang
themselves with their own rope. The company is bigger than you are, its
decisions weigh heavier than yours. Stop with the ego-belief that you know
better than it. It's cold comfort to be right, so just get behind management
and try to make the new direction work.

I mean, come on, in the grand scheme of things, developers are wizards who
never have to be worried about 90% of the things other people in the world
have to worry about. These finer qualities of career enjoyment are nice-to-
haves, not necessities. There's always good, solid ground to retreat to in
case you get routed. Complaints like this remind me of a rich wanker bitching
about the valet not putting his seat back the way he left it. Just adjust it
yourself and move on with life. Life's too short to get mad about stuff like
that.

~~~
fsloth
The author is simply describing a transformation from a system driven mostly
by intrinsic motivation to a system driven by an extrinsic one.

Typically complex tasks are solved better in an environment with emphasis on
intrinsic motivators.

It's not wissful thinking. It's a keen observation.

Basically management offloads the responsibility of actually managing to a
process of accounting. It's a less skillfull, less productive, but a much more
predictable form of management.

The problem was not the Jira. It was the new PM who instituted the cultural
change. Jira can be used just a well to document work done by intrinsic
motivators.

~~~
skewart
This, 100%. I agree that complex tasks are generally better solved in an
environment driven by intrinsic motivation - heck, probably all tasks and not
just complex tasks.

I'm not sure if Jira and other task tracking tools can be used just as well to
document work done by intrinsic motivators though. I mean, yes, they _can_ be,
but I don't think they're as good as they could be. In fact, I'd say there's a
big gap in the market for a solution that gives non-technical managers some
reassurance that progress is being made while also not getting in the way of
the ad hoc workflows the post describes.

~~~
amag
I've found that tracking tools are good to have even at times when I've been
able to work in the manner of freedom the article describes. It's just that
they are used differently, more in a way to help remember things. Things that
either needs to be done or things that have been done. Especially those
nightmarish things that took a long time to solve, so documenting the process
is good for the future, in case it happens again.

It wasn't always like that for me (document, bah! comments, bah!) but as I
grow older I've come to appreciate the possibility to offload information in
my brain to a more persistent media. This way I only keep the index in my
brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I
hate doing the same thing twice. I also hate saying the same thing twice so
before I explain something to someone I like to write it down and give them a
copy. Then when they ask me about it I simply refer them to the document (in a
friendly (RTFM) manner).

------
gyardley
Oh, the joy of being a product manager for the particular type of programmer
who, by virtue of being a programmer, also knows absolutely everything about
absolutely everything.

This is the type that refuses to tell you if they think, completely ballpark,
whether something will take a day or a week or a month, but if they disagree
with a tiny aspect of the feature you've brought them, the deep domain
knowledge you were hired for and dozens of customer visits you've done are
nothing in the face of the awesome might of their computer science degree.
Better get comfortable, because it's going to take you several hours to
persuade them that you do in fact know how to do your job and the wild-ass
alternative they've just come up with is wanted by the market about as much as
syphilis.

With these guys (and they're always guys) you've got to process up and
micromanage, because the only way to get a little bit of intelligent
estimating out of them is to ask for ten times as much, so they can give you
what you need while still feeling like they're largely ignoring you. The only
silver lining is the process eventually makes them leave, so they can be
replaced by people who work well with others.

You know, I really don't miss being a product manager.

Ranting aside, good developers in larger organizations realize that people
have specializations, they and other parts of the company are interdependent,
and a little administrative overhead is necessary to keep everybody moving
forward together - so they work with people from other parts of the company in
good faith, and this makes it possible to keep the administrative crap (which
no one likes, it's not just them) as light as possible for as long as
possible.

~~~
PhantomGremlin
_This is the type that refuses to tell you if they think, completely ballpark,
whether something will take a day or a week or a month_

A comment in the article made a similar point. QFT:

    
    
       I dare say you wouldn't win much work though
       turning up to pitch to potential customers and
       declaring that you'll definitely deliver
       something, but you don't know how long it will
       take or how much it will cost.
    

Every employee needs to be aware of time, of deadlines, and needs to
understand that the money to pay their salaries needs to come from somewhere.
Or they need to find a job working for some government agency, or in academia,
not in the real world.

~~~
mobiuscog
If businesses didn't make promises before they knew if they could keep them,
the deadlines wouldn't be such a problem.

If an employee agrees to a deadline, it's fine. If an employee is just told
they have to complete a task within a deadline that they're weren't included
in estimating, that's not the employee at fault.

~~~
gearoidoc
Thats not what gyardley is saying though. He's talking about developers who
refuse to estimate how long a chunk of work will take.

~~~
mobiuscog
An interesting point on developers who refuse to estimate, is how often they
are then asked "Why ?".

I'm definitely someone who has either refused to give, or given massively
exaggerated estimates in the past, for various reasons, the main being "I
don't know".

Think about this for a moment - why wouldn't an (experienced) engineer know
how long something will take ?

The most likely answer (and in retrospect the only reason I ever did this) was
that the project was far too large / complicated to visualise, and needed to
be broken down.

By asking an engineer to break the task down into smaller tasks, until they
can 'ballpark' estimate each part, is the best way to solve this problem.
Maybe more design or investigation will be required to manage the breakdown.

Instead of writing off 'problem' engineers, try to work with them and find the
common ground.

------
donatj
This is exactly where my job is headed. We hired a project manager who frankly
knows nothing about tech. Suddenly, we the developers are no longer able to
file tickets ourselves and the tickets themselves need to be blessed and have
specs the higher ups can approve. One liner for a hot fix that's filling the
error logs? Needs a ticket - a ticket we can't file. All pull requests need
one or more associated tickets. I've done my best to actively ignore/subvert
it, but it's coming up more and more.

It's incredibly stifling and frustrating and I'm really peeved. It's hard to
leave a job I love and have been at for almost 5 years, but we're on a road to
hell.

All that said, if anyone needs a Go dev ;)

~~~
partycoder
The problem is not creating tickets. It is the process around them.

Creating a ticket takes seconds and you can even build templates around them
if you think they're time consuming. If you cannot report tickets your
workflow is wrong.

~~~
twunde
Seconded. You should be able to create tickets or at least file an initial
ticket that a PM can flesh out. Tickets (or any type of change control system
including git) really serve two purposes. 1) To track what changed 2) To track
WHY something changed. A dev should be able to look up your ticket a year from
now and be able to untangle the logic in your code changes tied to that
ticket. If your ticket only has a title, or the briefest of descriptions
you'll find it hard to debug any issues introduced by this (and you'll also be
going to dev hell)

~~~
donatj
git bisect + git blame I find usually more useful than verbose likely
partially correct notes.

~~~
gknoy
That often tells What changed, but rarely does it seem to tell Why. When the
logic changes (and tests too) because the sales team now needs Different
Things, it's very useful to have a ticket.

------
YZF
The story begins with a new feature request that the "business" thinks is
needed while the "developers" think is not. It's really hard to pick sides
here without knowing more about the specifics. I've seen situations where
developers are completely wrong about the business value of something and I've
seen it the other way around.

If the new feature was indeed critical to the business then the boss finds
himself in a situation where one of the best developers spends months trying
to build some DSL and comes back with nothing. So we can understand the
frustration on the business side of things. This is where things started going
the wrong way and there's a loss of trust on the ability of the technical team
to deliver.

Now obviously the new PM and his buddies (I've seen this before) only make
everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by
the old team used to doing whatever they wanted to do.

I think the truth here is there has to be some sort of balance. Developers
need to balance architecture and refactoring with delivering new stuff. They
need to listen and have a dialog with product management about new features.
There has to be trust. When there is trust there are less controls. When trust
is lost it's almost an unfixable situation especially when you have a
combination of a tech team that isn't delivering anything useful (from the
business perspective) with management who doesn't understand software
development.

Clearly the best situation is trust combined with good management and
developers who take ownership and see the big picture. Then useful stuff gets
delivered and things like architecture or refactoring get taken care of.

~~~
bb88
> Now obviously the new PM and his buddies (I've seen this before) only make
> everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by
> the old team used to doing whatever they wanted to do.

Everything I have read about agile is that if you do it right, everyone is
happy. The customer, the developers, and the managers. Agile itself is
supposed to be development-centric.

Tonight, I realized that Agile does not handle politics very well. I mean, how
can it? It's just a software development methodology.

~~~
mannykannot
> Everything I have read about agile is that if you do it right, everyone is
> happy. The customer, the developers, and the managers.

So they said about all its predecessors, as well. Pretty soon, they start
adding "...of course, you must have exceptionally competent people", and then
they define 'doing it right' by 'having a successful outcome'.

Problem solved by begging the question.

------
kasey_junk
It turns out that software development is a very immature industry. We simply
don't know how to judge successful software projects/developers.

In the face of that immaturity we can try all kinds of things. Personally, I
do anarchist development and hope for the best. Others try cargo cult project
management. Still others move to highly constrained development methodologies.

~~~
gearoidoc
I think its easy to judge if a software project was successful (eg. Did we
launch? Did we deploy that feature?).

The harder question I suppose is whether it was successful and we've
got/maintained a quality codebase.

~~~
kasey_junk
But compared to what? Most software continues to be bespoke/new work. If a
different team/process was used would we have been as successful/spent as much
money.

~~~
majewsky
This touches on the classic question of "is coding engineering or art"? If it
were engineering, it would become quantifiable once we have enough empirical
data from previous projects to base our theories on. If it were art, that
would be impossible since every project is as individual as the last one. It's
probably inbetween.

~~~
bb88
Engineering is just applied science. And other engineering fields experience
the same types of failure that software engineering experiences -- cost
overruns, undefined requirements, unseen technical hurdles, etc.

------
edderly
Not 100% convinced by the conclusion. There is good project management which
can be relatively fine grained, but it doesn't have to be micromanagement and
it doesn't have to be a death march.

There are some basic red flags raised:

> Our project manager would be displeased when tasks took longer than the
> estimate and would immediately assign one of the other team members to work
> with the original developer to hurry it along.

Shouldn't happen just at the whim of the PM. A sane environment would work by
a developer asking for help first, and it actually sounds odd that you have
capacity for a PM to throw someone to just 'hurry up' tasks

> Whenever there was any debate about refactoring the code, or backing out of
> a problematic feature, the new guys would argue against it, saying it was
> ‘ivory tower’, and not delivering features. The PM would veto the work...

Why does the PM have a veto? No technical lead or management with balls? PM's
need to manage the features of a release _and_ changes to the plan. Any PM who
says features are set in stone isn't doing their job. A PM's role is to handle
change and execute the plan. Sounds like weak management.

~~~
vfc1
> Shouldn't happen just at the whim of the PM. A sane environment would work
> by a developer asking for help first, and it actually sounds odd that you
> have capacity for a PM to throw someone to just 'hurry up' tasks

The problem is that if the PM decides to do that, the developer has no
authority to refuse that.

> Any PM who says features are set in stone isn't doing their job. A PM's role
> is to handle change and execute the plan. Sounds like weak management.

Most PMs are just proxies for business, they manage up and out but not down.
They will not risk their jobs by refusing requests from business, in the long
term that would put them in an unsustainable position.

~~~
ViViDboarder
Maybe at some companies. Where I work, Engineering Managers and PMs are
totally separate. So Engineers have much more representation.

But, even in places where this is not the case, they are willing to hire--
spend money - - to speed the project up. If it's made clear, not just to the
PM, that it's going to cost money and have no positive effect, it should be a
clear business decision.

~~~
edderly
> Maybe at some companies. Where I work, Engineering Managers and PMs are
> totally separate. So Engineers have much more representation.

Exactly!

------
iamthepieman
This is similar to an experience I had. Me and the small dev team were being
micromanaged. But we were getting lots of new customers for version 2.0 of our
main software product and specifically targetting feature relases to snag
certain customers, I feel like it worked from a business perspective.

We didn't have time to refactor, didn't have time to anticipate how something
would be used in the future and build extensibility into it and the number of
hacks in the codebase grew daily.

most of us on the dev team knew it was going to be a complete disaster at some
point. It was going to take a week to fix a simple bug because it's copy-
pasted in 7 different places and something derivative now relied on the bugs
behavior.

But we were releasing fast and getting money because of it. Initially we
fought it but eventually I just figured that if I wasn't on another project
when it came time to pay the piper then I'd just find another job.

I had given my warnings - when I did have time I still tried to do things
right and refactor old code. Ultimately though, the business tradeoff
decisions weren't mine to make and I wasn't going to lose any sleep over it.

------
jondubois
I've worked for companies like this. What's hilarious is that most of the
employees at these companies take the process very seriously (they obviously
don't know better). I've worked at both startups and big companies - I find
that fine-grained management in big companies is extremely inefficient. In
software, the more constraints you add to a project, the slower things will
progress.

It gives non-technical managers extra visibility at the cost of speed and
agility.

I can't help but chuckle to myself whenever we have a 'retrospective meeting'
\- Every single time, it's the same problems that come up over and over again
(related to management/communication issues) and these problems never get
fixed.

What's even funnier is that the closer we get to a deadline, the more meetings
we have - And the more it slows us down.

There is a fundamental problem with having very fine-grained
cards/stories/tasks; often, related tasks are assigned to different people but
it would have been much more efficient to assign all these tasks to a single
person.

~~~
dev360
>>> It gives non-technical managers extra visibility at the cost of speed and
agility.

Keen observation. Often times these situations are just self-inflicted wounds
on the part of devs too. I have worked with many devs that have had a habit of
keeping stakeholders and coworkers in the dark just because they feel like
they are too important to be bothered/be held accountable.

I know what I'm in for if a project management or glass house CIO is all of
the sudden needed, so my top priority is always to primarily earn the trust of
business stakeholders and to be as honest as possible.

------
partycoder
About processes: You add a process when you want repeatable results. Adding
blocking, synchronous steps involving people slows things down. Adding non-
blocking, asynchronous, tool assisted steps are less intrusive in people's
work.

About hierarchies: You add hierarchies in your organization when your quorum
involves too many people and things slow down. Hierarchies exist to make
consensus building simpler at the cost of representing fewer people and all
the associated consequences. Hierarchy must not be abused. People need to be
respectful towards others regardless of hierarchy. Each contributor is
important.

About quality and technical debt: If you are always reacting to defects, you
lost control of your product. You can no longer plan because you are too busy
reacting to ad-hoc unplanned work. This is unprefessional and unnecessary.
Keep things under control by being preventive, proactive and professional. If
someone tries to convince you that non-functional requirements cannot be sold,
remember that person that person to focus on functional requirements and leave
the non-functional requirements to the engineers.

------
vfc1
This is one of the best posts on software development I've read in many years.
Each sentence rings true and is an amazing read.

Its like the author is describing many of the projects I've worked before.

Micromanagement and software factories are the death of software development.

But then no matter how much I dislike these management methods, I can see why
they are put in place.

There are certain developers that get to a project and just start rewriting
everything with no good reason, introducing new cutting edge tools and
frameworks for the fun of it and for pure CV driven development.

They introduce huge bugs close to release dates, breaking browser support,
refusing to test on IE.

Lets face it, loose canons exist on all teams and we've all seen it before.

This is OK and necessary in the early development cycle, but when things get
to production its different. One day something gets seriously broken, and
management comes in putting in JIRA or equivalent, and micromanagement starts.

Demotivation of the early developers sets in, the ones who knew how to setup
an architecture and make technical decisions. The leave and are replaced by
other developers that don't necessarily could take those decisions.

The project entered a pure maintenance phase, where business as sort of given
up asking too many features, it just costs too much and the results are less
than ideal.

The project enters the keep it running final phase, where noone knows how
certain parts of the system work anymore, all original developers long gone.
Here the goal is to touch the code as least as possible and its no longer a
development job, its mostly technical analysis and troubleshooting of test
environments.

Then 5 or 7 years have gone through, and the business decides to replace the
system with a new one and the cycle starts again.

The only way i've found to deal with this, is to become a contractor and work
mostly on early to mid phases of projects. When the project enters pure
maintenance I wait for a few months and then look for a new project.

------
hlieberman
This is very true. My experience has always been that my team performed better
when there were /less/ controls on their time, rather than more. I also found
it was important to explain the reasons /why/ a particular thing needed to be
done by a certain date, on the occasions that some external pressure needed it
to be done.

People don't mind pulling out the stops and working extra hard, as long as
it's occasional and /necessary/. It's absolutely morale-killing to do so for
an arbitrary deadline, however. Nothing burns out a team faster than death-
marches to deadlines pulled from thin air.

~~~
jaggederest
And of course, the other key part of that is that you should consider those
exceptional cases to _be_ exceptions, in the sense of errors.

When production goes down, or the sales team overpromises, don't just fix it,
figure out _why_ it happened and do the full root cause analysis.

------
klochner
Many developers prefer to work like Navy Seals or Jazz Musicians. It's
objectively more empowering, arguably more fun.

Some jobs require an army or a big band, i.e., a lot of coordinated precision
- objectively less freedom and autonomy, arguably more tedious.

Beyond some threshold of granularity you will crush morale though.

Do what makes you happy.

------
kolbe
Work long enough and with many different companies, and you will inevitably
have had an experience much like this one. And it's not just in software. Any
profession that relies on some form of engineering knows what this is like.
There's a reason why Dilbert is so funny.

------
bcjordan
This stands as an interesting broad strokes story from a developer's
experience at a growing company, but worth keeping in mind it's one specific
scenario and one perspective on it.

In the generalizations-from-this-instance part of the essay, watch for two
false dichotomies—"developers that care about getting things done fast with
little technical debt and hate having PMs" vs "mercenary developers who like
doing one small thing at a time without architecting things themselves, don't
find fast ways to do things and ps like cars and money instead of hacking".

And "no PMs or process at all" vs "way too much process causing poor
development time investment".

The best developers, team leads, PMs, etc know when to introduce new processes
and team members and when not to. And, importantly, how to tailor processes to
each team member to make them as effective as possible. And they work together
collaboratively to solve problems—estimating and discussing features flexibly,
not tossing pie in the sky specs and finished products over the fence.

In this instance it sounds like they didn't do a great job of working with
existing scrappy developers' potential, but instead supplanted a new framework
(eng/PM) they had seen work before, and the blunt hammer of that move
destroyed a lot of potential the early team had invested in. It sounds like
there was a general communication issue that was crippling the team even
before a producer and new hires came in.

I've seen a few teams now grow from no dev process to combinations of issue
trackers, estimates, specs etc. Around 14-20 developers it becomes nearly
inevitable for someone to take on a high level production role and someone to
take point for engineering reliability, whether those are official job titles
or not.

Often this period coincides with when early team members move on. It's rad
when growing companies find ways to keep those early, scrappy hires with deep
historical product knowledge in productive roles as the company grows and
shifts priorities from staff-leanness and product-speed to staff-scale and
product-predictability. But that's often unfortunately not what happens, and
it can be extremely painful for both early team members and those trying to
evolve the company. (Growing pains!)

------
abalone
So a project was "months" behind schedule, they implemented an agile process
for tracking tasks, and "everything slowed"? Slower than what? Being months
behind schedule?

I get that some PMs can undervalue refactoring code / minimizing technical
debt, and that's super frustrating and shortsighted. But the basic premise of
this criticism of agile process is deeply flawed:

1\. The claim that features took "longer" to ship is directly contradictory to
the admission that the project was months behind schedule.

2\. If they were behind schedule, then "inflating" their estimates in response
to a detailed tracking process was not, in fact, an inflation. It was a
reality check.

Estimates are really hard. But the solution is not to just "give autonomy"
with zero estimation, because that's how you get into that problem they had in
the first place: a guy in a room that doesn't ship for months. That's why
agile's approach of breaking things down into tasks with very rough sizing and
measuring actual after-the-fact time and shipping small milestones frequently
is so helpful. You don't have to have super accurate estimates. You just need
to report your time and then it figures out a team "velocity". That helps
teams be more predictable, which is what it means to be professional and
deliver things to customers on time.

~~~
Joeri
Yet agile implemented top-down without team ownership of what to work on is
not agile and not good for the health of the codebase. I have seen it fail
repeatedly.

Basically, if your team is skilled and capable, the process is not that
important, as they will find a way to get things done. If the team is not
good, the process won't make them much better. The key to a smoothly
performing software dev team is good hiring and good coaching.

~~~
abalone
So if you're behind schedule, your team just isn't skilled enough? That's kind
of a dodge. Every team can improve.

Instead of exclusively focusing on finding "good" developers, let's also focus
on evolving "good" process. Time tracking, estimates, itemizing tasks.. these
are in fact good things.

~~~
jaggederest
I would, and have, argue that estimates and time tracking are, in general,
wasted effort.

If you have good priorities, estimates are irrelevant, because you'll be
working on the most important things, and that is unlikely to change no matter
the estimated effort. If you don't have estimates, then you don't need time
tracking to see if your estimates are correct.

You've just eliminated half of the overhead for software development - the
only added cost is that you must continually understand and update your
priorities (or values, if you prefer), which you should be doing anyway.

------
willvarfar
Ah the "lets make the project cooler by adding a DSL so customers can add
their own features!" never ever pans out! ;)

I spent the 90s working on office automation projects that always seemed to
degenerate into report DSLs. Is nothing new?

The better I get at coding the more I am attracted to avoiding complicated
tooling.

~~~
gearoidoc
There's always a flip side! My current project has a DSL (not written by me)
and it functions superbly.

It does take about a full work day to wrap your head around though :)

------
zwegner
Great article, this echoes a lot of my frustrations working in the software
world. It doesn't help that I've experienced being on a well-managed software
team working on interesting problems--it kinda spoiled me for all those other
jobs... :)

Anybody have any advice for escaping this? I want the freedom to work on
interesting things in my own way with a minimum of the politics. Ideally a PM
would be someone who pushes back on all this micromanagement crap and does
everything they can to make the developers' jobs easier. It seems I'm not
self-motivated enough to do freelance work or start a start-up, so what other
options are there?

~~~
bcjordan
It sounds like you were at a company you enjoyed before—are they still hiring?
:P

If not, maybe you can do another job search and try to select for companies
that manage their projects how you'd prefer. Try asking team members what the
process is like and how they feel about it. Often times those Qs are more
illuminating than ones about the software stack.

------
gearoidoc
Some good points but the argument that software teams will be most performant
as a result of autonomy really depends on the team in question.

I worked on a small team with 2 other developers who were both pretty good
devs technically. However they treated the business side with almost-contempt
and they would estimate even simple changes to take days.

As the most junior member on the team I couldn't really influence them.
Interestingly, after about 2/3 months on the job, the business side decided to
use me as their initial go-to for dev.

------
draw_down
I say it's a mistake to expect to have creative control at all, over something
owned by the corporation you work for. Best to accept that it's not your baby
you're working on. You don't get the profits or the glory or any of that. Just
do your tasks and treat it like what it is: a job.

Creative control and passion and all that is for side projects and things you
build yourself. I just feel it's setting yourself up for disappointment to
think otherwise. Companies are not founded to provide the ideal environment
for software development. They are founded to make products and hopefully a
profit.

You might argue that a smart business person would provide that environment in
order to get their product built, and maybe you'd be right, but that also
risks building the thing developers want to build as opposed to what could
sell. And as soon as you intervene, poof goes the ideal environment. So even
if the environment exists at a company, as at the beginning of this story,
it's best understood as a happy accident and shouldn't be expected to last.

------
ZigmundFreud
I think context is important here. What is the software you are building? Is
it highly critical or possibly life threatening, like a stock exchange trading
system or a aeroplane control system? Should the developers be given autonomy
to speed delivery? Or should more controls be put in place to ensure delivery
of the quality, validated product while possibly slowing down the delivery
speed.

------
ArkyBeagle
There's no "Heisenberg" here - the company decided to do the moral equivalent
of invading Russia in the winter. I quote - "Then came that requirement. The
one where you try to replace an expert user’s years of experience and
intuition with software."

The only problem with "finely grained management" is that it costs too much.

------
pacaro
The moral of this story is that "let's create a DSL so that users can encode
their business logic" is jumping the shark. I was mildly disappointed that the
hero of this tale (the PM) didn't fire the "DSL guy" on day one

~~~
bcjordan
DSLs for stakeholders aren't always bad. DSLs thrown over the fence without
early and regular stakeholder testing are usually bad though :)

------
option_greek
Sometimes I feel JIRA is the manna
([http://marshallbrain.com/manna1.htm](http://marshallbrain.com/manna1.htm))
for software developers :(

------
nostrademons
The more projects that I've shipped from conception to completion, the more
I'm believing that there are two fundamental phases for each project, and you
need radically different management philosophies for each.

Phase 1 is "will it work?" You get a vaguely-specified business requirement,
maybe some intuition that a market could be better served by software. And
your job is to build that software, and figure out exactly what's required for
it.

In phase 1, you _need_ the creative-genius programmers, and they need to work
in small teams with large amounts of autonomy. Because most of what goes on in
phase 1 is failure: you are learning about the problem space and all of its
corner-cases, you're trying out different approaches, and you're hoping to
make that one creative leap that brings everything together. Prototyping is
invaluable, refactoring is important, and deadlines and estimates might as
well be plucked out of thin air. To successfully run a phase 1 project, you
often need to be able to redefine success. When I read the article, my first
impulse was to say "Well, the biggest fuckup management made was to not cancel
the feature, because they had ample evidence that this feature was not worth
the cost." A startup's entire life is spent in phase 1, because once it's
exited phase 1 it's called a "high-growth company", and their version of
redefining success is the pivot.

Phase 2 is "make it work". You start phase 2 with a working prototype that
demonstrates the feasibility of what you're hoping to do, but still has a lot
of rough edges. And your job is to polish it down to something that the
customer wants to use daily. That means fixing bugs, improving usability,
adding admin tools & logging, improving performance and reliability, ensuring
security, etc.

In phase 2, you need a much larger team of disciplined, detail-oriented
engineers. Because debugging can be parallelized. You need unit tests, you
need formal processes, you need issue trackers, you usually need PMs or
management. It helps to break things into user stories so that you know you're
always making progress.

I see a fair amount of hate for Agile and Scrum on HN, but _these are tools_ ,
and specifically tools for Phase 2 work. I use them myself, for my own
projects, because I find that they help me manage all the little tasks
involved in bringing a product to market. The hate comes from people who
misapply them: startups who have big-company management who blindly apply what
worked at their last employer, or established companies that are trying to do
new green-field projects and believe it works the same way improving your
10-year-old product works. But similarly, there are a large number of
abandoned startups and open-source projects that never bothered to cross the
Ts and dot the Is, and so are largely useless to people.

~~~
sheepmullet
The more projects I work on the more I am convinced most projects are a
combination of phase 1 and phase 2 work.

The biggest problem I see is projects usually adopt a one sized fits all
approach.

If part of the team is using a strict scrum process and they find it helpful
because they are doing phase 2 work then all of the team gets forced into it
even if they are doing phase 1 work etc.

------
taylodl
Ever work with an engineering team? Building new weapons systems? Fighter
planes and the like? Just as creative an endeavor if not more so than software
development yet they have schedules and budgets to meet too. And yet people's
lives depend on the result. Software development can learn a lot from other
engineering disciplines.

~~~
seivan
I feel like you might have missed the point. Also you're assuming these
engineering teams for weapons systems and fighter planes are successful by
default.

F-35?

~~~
taylodl
Not all engineering projects are successful either. What I'm saying is there's
a lot of similarities between these disciplines and so there exists a large
body of knowledge and experience from which we can cull and learn.

------
mikekchar
The "Heisenberg Developer" name is really excellent. I recall DeMarco saying
in his excellent books (so many years ago): Do not measure anything unless you
have a very specific action you want to take based on the data. Why? Because
every measurement alters the way programmers work. The author reports that
increasing the granularity of the work (and thereby decreasing the time
between measurable status updates) led to a lack of refactoring. I have also
experienced this one and it led to much head scratching on my part.

Which is not to say that one should not measure. I've never actually used
Jira, but apart from that, many of the things the author talks about are
generally good ideas: reduce story size to a day or so, prioritise every 2
weeks, measure delivery at about the same interval. Don't throw the baby out
with the bath water.

I can say with some confidence that where they went wrong was that they tried
to estimate the stories and then they made the cardinal sin of trying to
measure the elapsed time for each story. In the first case, you don't need
estimates. Each story is a day or so. It's enough granularity. In the case of
measuring, there is no organisational benefit. You can see the average
throughput of stories. You can estimate your final delivery (especially if you
use a defect growth model to estimate how many requirements you are currently
missing before delivery). Measuring the actual time of an individual story
adds absolutely nothing to your control of the project.

The main argument that I've heard for measuring are two fold. First they feel
that measurement will allow people to get better at estimating. Again, it is
not needed. If you have a granularity of a day or two in your story sizes (and
your throughput is showing that you are achieving that), then you have nothing
to improve. If your throughput is not there, then you need to see what the
problem is. It will be one of 3 things: your stories are too big, your code is
too complicated, your programmers are crap. The first is solved by making your
stories smaller, the second is solved by working on technical debt, the third
is solved by firing your programmers. I recommend doing everything you can to
solve the first, move on to the second, and only then resorting to the third.

What measuring _will_ give you is an idea of the variance in the story sizes.
This is unimportant. In fact it is critical _not_ to measure this. All you
care about is throughput. Variance is where the developers are putting the
extra effort in to improve your throughput (by dealing with technical debt,
improving tests in critical areas, creating efficient build systems, writing
documentation, etc.). If you remove the variance (as described by the author),
you destroy the ability for the developers to optimize throughput.

The second argument for measuring time is to identify stories that are (or
were) in trouble. Again, this is unnecessary. First, if you have a story and
you are having a hard enough time that it is taking you longer than a day or
two, then you _already know about it_. Asking for help is what stand up is for
(and really, I hate to have to say this, but that's _all_ standup is for).

If you are not having trouble, but you are spending a few extra days to
refactor something, then you _already know about it_. Everyone else does too
because they can see the code that you refactored.

If you are sitting on your ass and wasting your days writing extremely long
posts on HN, then you _already know about it_. And so does everyone else
(because you haven't written any code today, and it's not like you asked for
help...).

I'm just going to write this one time. If your reasons for measuring the
amount of time for stories is because you secretly think that your developers
are crap and that they don't know what they are doing, no amount of
measurement is going to solve the problem. Make a decision. Fire them, or not.
You can't make a crap programmer good by pointing out how much time they spent
on a story. They _already know it_.

~~~
amag
> (and really, I hate to have to say this, but that's all standup is for)

Hehe, this earned a +1 from me. I've had standups where the scrum master (who
also was a lead developer) spent the _first_ 15 minutes talking about what he
did the day before.

------
rocky1138
This post should be pinned to the top of Hacker News.

