

Working with queue and stack people - rmason
http://marcesher.com/2014/08/18/working-with-queue-and-stack-people/

======
bakhy
First, I believe wanting to fix broken windows and technical debt is
everyone's goal. The author mentions a couple of times that fixing technical
debt is just a stacks' preference. I disagree with that. Not least because
fixing technical debt can sometimes take quite a lot of time and boring,
error-prone work - not quite the stuff of heroic tales - but also because I
have seen many examples in my career of technical debt created by people
wanting to hack something together quickly, and then never getting around to
cleaning it up, leaving all sorts of surprises behind them. I think generally
it's good thorough thinking that gets rid of technical debt (see, e.g., Rich
Hickey's work, and his Hammock Driven Development "methodology").

Generally, I'm sorry, but chasing the quick-fix is immature, and a sign of a
desire to please. That is completely normal, and it's healthy to let off steam
through a quick fix now and then. But the "stack" model here sounds to me more
like what happens in my head when I procrastinate...

IMO for a project to succeed someone will ultimately have to keep track of
what is done. Do you want to be that person, or do you want someone else to do
it while you get lost in your stack overflows?

------
rdtsc
On a funny note, for mathematicians, "analysis vs algebra" bend predicts if
they'll eat corn depth first or breadth first.

[http://bentilly.blogspot.com/2010/08/analysis-vs-algebra-
pre...](http://bentilly.blogspot.com/2010/08/analysis-vs-algebra-predicts-
eating.html)

------
zniperr
The examples are very relatable, at least for me personally. Judging from this
fragment, I would consider myself a stack person: "For tasks that represent
pain that must be immediately alleviated, it’s not that the stack feels I must
fix it; rather, this must be fixed. The task is painful not because the stack
must fix it, but because it exists, period."

The frustrating part about this is that it is very hard to explain to
coworkers why you feel this, because you intuitively expect them to feel the
same way. I can recall some cases in which this has caused some friction when
working on group projects.

------
johnlbevan2
I've always thought of myself as a stack person - if there's an issue that can
be fixed now, get it done. Having something languish in a queue means that by
the time you get round to looking at it you may not have all the information
you require available / it'll take a lot of time to refamiliarise yourself
(most of the time you'll have had to do at least some investigation when the
issue first came in in order to determine the impact / priority of the task
anyway; if queued all that work needs to be repeated months later). Also, if
there's something in a queue which has been there for a year it's probably not
that important. If the same thing keeps recurring and you're a stack person,
that thing will automatically be jumping to the top of the stack each time -
so you can resolve it, then remove any duplicates further down the stack as
you hit them.

Queues are generally better for project work, Stacks are generally better for
support.

Regarding the time taken to prioritise and log work, XKCD's nailed it again:
[http://xkcd.com/1445/](http://xkcd.com/1445/)

------
oneeyedpigeon
It's great to think about this and perform a bit of self-analysis, with the
intention of improving one's behaviour. I am very much a stack person, with an
added serious flaw: my stack is very shallow due to poor memory management :)
I'm typically working on one or two long-term tasks, a few medium-tasks, and
lots of short-term tasks which just get dealt with as they arrive. The
long/short-term tasks are easy to manage, but the medium-term tasks always
suffer; colleagues typically have to remind me time-and-time again until I can
finally prioritise one. This desperately needs solving.

------
freework
I think your preference (stack or queue) is dependant on the nature of work
you are doing.

For instance, at my current job, I've been here for 2 years. I know the
codebase pretty well. If an issue comes up, I can almost always get it
resolved in a few hours or less. For this reason, I am currently a stack
person.

On the other hand, when I first started this job, I didn't know the codebase
very well, so it usually took me at least a week to complete a typical issue.
Back in those days I was a queue person.

------
wallflower
Since I help put out a lot of fires, some of them smoldering and with
potential threatening to (eventually) burn down the company, I like to think
of what I do as working from two priority queues.

The first priority queue is very small and what will be done today/in the near
future. The second priority queue is a list of everything else.

Stuff can get bumped from the first priority queue back to the second priority
queue. Both queues are constantly being reshuffled (in my mind, not in JIRA).

I never really understood the agile/scrum thinking that seem to block parallel
execution - or management implied could only be executed serially (as in this
feature needs to get done at the detriment of this one).

System-level issues trump individual customer-level issues. Long-term fixes
for customer-level issues trump individual fixes for customer-level issues
(unless, of course, said customer has escalated). Paying off high-interest
technical debt that has rolled over to several credit cards is a high
priority, as well.

The reality is that when the house is fire, you need to put out the fire.
Sometimes the perception is that there is a fire when there is not, though.
And, if you see something that is a potential fire hazard/already smoldering,
you need to aggressively put that out.

------
ajdecon
I've mostly worked in operations, which IME is a field with a very high
concentration of stack people. Sysadmins (including myself!) tend to derive
great pain from the presence of a production issue and feel the need to fix it
immediately, even if we could provide a greater overall win by focusing on
project work. I've sometimes seen this result in five people working on an
issue that could have been handled by one or two, simply because "it's broken
and I need to fix it".

One of the ways my current team tries to mitigate this is with an on-call
rotation and an explicit escalation process. When a new ticket comes in, the
on-call decides whether it is something they can fix quickly and easily, or it
would require too many resources for an immediate fix. The first kind of
ticket is handled immediately, or is added to the on-call's (short) task list
for that day; the second kind goes into our regular queue and gets prioritized
alongside project work.

Meanwhile, everyone else on the team focuses on their current projects and
handles issues according to the queue. Other team members are only called in
to help immediately if the on-call judges the issue to be urgent but can't
handle it themselves.

------
kabouseng
The question is, for a product, which approach is best? Do you solve the low
hanging fruit, and are responsive to clients but with high risk of breaking
something else, or do you work methodologically through your product road map
but are less responsive to clients.

The Agile movement's aim can be said, is to reduce the feedback loop of
software development, so favouring a stack approach (echo'ed in facebooks
"move fast and break things" approach), but I have also seen situations where
there is no strategic planning, and the team can churn for a year like a dog
chasing its own tail. Methodologically working through your roadmap can again
be seen echo'd in Steve Jobs approach of saying the client doesn't know what
he wants, its your job to give it to him.

~~~
falcolas
I think there is room in larger teams for both types. There are always high
priority tasks which need immediate attention, and a backlog of tasks which
needs to be churned through. If you can have both types of people on a team,
you can assign the tasks appropriately and be sure they will all get done.

------
johnloeber
Huh, this is a pretty salient observation. I'm curious about the extent to
which it applies -- I certainly am a stack-person some times, and a queue-
person at other times. Could it depend on context? Queue for important tasks,
Stack for unimportant tasks?

~~~
johnlbevan2
I wouldn't put unimportant tasks in the stack; that would mean you do those
first.

Fast turnaround tasks are best for the stack. Tasks which involve multiple
parties & thus planning and coordinating are best for the queue.

Many organisations already deal with this in having first line and second line
support; first line pick off the quick stuff and log the hard stuff; second
line then work their way through the hard stuff/ First line will also put a
task on hold if a new call comes in; their priority is to answer the
phones/get things logged, with working on resolutions taking lower priority.

So first line support's a stack, second line's a queue.

As the blogger mentions though, generally things are mixed; whilst there will
be a preference/default working style most people/teams will fall somewhere in
between, usually adding some level of prioritisation.

Another point is that prioritisation is generally based solely on the
importance of the task & detailed analysis of its implications for queue
people, whilst stack people will tend to guess at both the importance and the
implementation time to get a priority based on the weightings of both factors.

------
astletron
I've always thought about this as heap and stack people - those that are good
at managing ideas with random access and those that prioritize the recent. A
discussion between mismatched memory models can be difficult. An old (and
revered) team leader described himself as a translator between these different
storage approaches.

------
liotier
I'm a heap person.

Am I a heapster ?

------
_RPM
> If you have a long, narrow, single-door, multi-car garage that fits a
> single-file line of cars… that’s a stack: last in, first out.

That seems to represent a queue as well. If we assume the last car in is at
the end of the line, then, well, we have a queue, not a stack. A stack is hard
to represent in real life everyday events. At least it is harder to represent
than a queue.

The way I think of a stack is a singly linked list. A linked list where
insertion time is O(1).

~~~
Someone
The idea is that you cannot get the first car out of the garage if the second
one still is there because that garage, with its single door, is a single-lane
dead end street.

A queue would be a single-lane one-way street, like in a car wash.

------
sblom
I think I'm a stack in the short term, and a queue in the long term.

------
osense
There's the stack people, there's the queue people, and then there's the set
people who just randomly work on one thing that feels good right now.

