

Ask HN: Developers, do unexpected ad-hoc requests piss you off? How to avoid? - tobinharris

TL;DR<p>When you&#x27;re at work, how often do unexpected tasks crop up from management? And does this piss you off? And does anyone know how to avoid it?<p>To explain...<p>My company combines client work and internal product development. The client work can be very reactive at times. E.g. &quot;Can you fix this bug and build and resend it to us within the hour?&quot;, &quot;Can you just get this feature done in the next 2 days?&quot; etc.<p>As a developer, I personally want to know what I&#x27;m doing for 80%-90% of the week, and can handle a few surprises. As a manager, my feeling is that I need to reduce or batch the ad-hoc requests from clients as they&#x27;re pissing us off. Any thoughts on how you achieve that would be appreciated :)
======
joeld42
This is why it's good to have a ticketing system. At first, just create
tickets yourself for the ad-hoc work (but make it visible to the requestor). I
do this for anything that takes more than an hour or so, or for even miniscule
tasks if it's a particularly busy time (just to keep track of everything).

If it's a larger request, then you can say "Sure, I'll fix it, but i'll have
to stop working on TICKET-1234, is that OK?"

Eventually people learn to create and prioritize their own tickets.

This is also good because sometimes a "five minute" fix can turn into a huge
project because of unanticipated factors.

------
Spoom
Separate developer days into blocks.

A small block at the beginning of the day for an "open house" where anyone can
directly ask questions of devs, come to chit chat, etc.

One block can be support tasks / ticket fixing. Contacting devs is OK here but
it's preferred to be in the open house time.

Another block can be heads-down, planned development. Developers don't get
bugged here unless there's an active fire burning. The plan should be set
forth at the beginning of the week so there's no confusion.

We've been doing this for a couple of weeks (after a department
reorganization) and it's been working pretty well.

It's important to get buy-in from the rest of the company on the idea that
context switches are actively harmful to development. Joel Spolsky knows
it[1]. Jeff Atwood knows it[2]. So do many others. But you have to get
management to understand it, or you'll never escape from the constant "just a
small fix" interruptions.

1\.
[http://www.joelonsoftware.com/articles/fog0000000022.html](http://www.joelonsoftware.com/articles/fog0000000022.html)

2\. [http://blog.codinghorror.com/the-multi-tasking-
myth/](http://blog.codinghorror.com/the-multi-tasking-myth/)

------
jtfairbank
Might have to start saying no to clients, specifically "no we're booked for
the week, but can get that feature request in for you next week".

Smaller things you can still do ad-hoc, just budget in a few hours per dev per
day for them. If the dev doesn't use all that time, they can get their other
work done faster.

~~~
tobinharris
Yes, this is probably the root cause. I guess fundamentally we can never get
predictable if we don't schedule work.

------
tobinharris
The "trade this ticket X that ticket Y" is a good approach. I've done that too
with _some_ success.

One problem is that we have multiple clients, so each doesn't care about the
others tickets.

------
munster
Scrum sprints deals with this. It helped us a lot in that regard.

~~~
tobinharris
Good idea.

It will probably take a month for us to determine our velocity, then we can
predictably dish out points.

~~~
lstrope
It will take much more than a month to begin to understand your velocity

