Working with queue and stack people

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?

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

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.

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/

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.

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.

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.

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.

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.

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?

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.

I'm a heap person.

Am I a heapster ?

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

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

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.