[HN Gopher] There Are No Bugs, Just TODOs
___________________________________________________________________
There Are No Bugs, Just TODOs
Author : Almad
Score : 367 points
Date : 2020-06-05 13:42 UTC (9 hours ago)
(HTM) web link (almad.blog)
(TXT) w3m dump (almad.blog)
| foobiekr wrote:
| This is close to how I worked for years (mine: build a dependency
| graph and then order by dependency, work through a graph at a
| time). It caused a ton of friction with my work environment which
| was managers prioritizing bugs and then expecting you to work on
| them in priority order which, often, was nonsensical.
| travisjungroth wrote:
| This post solidifies an idea that's been kicking around in my
| head: software tends to push productivity towards a local
| maximum.
|
| Let's say the author is right and ticket queues should be a
| single stack with no priority. That seems pretty easy to make.
| Easy enough on a popular enough topic that I'm sure it's been
| done. But, I've never seen or even heard of one in use. Why?
| Because it forces people to make hard choices. The software
| doesn't handle all the real world crap that comes up when people
| try to use it. It can't make the jump out of the local maximum.
| So instead, we get people endlessly iterating on the same ideas
| and releasing the same basic project trackers with slight twists.
|
| Also, I think there's a billion dollar company for someone who
| can make an internal support tool that people will actually use.
| jpswade wrote:
| Kanban is effectively this.
|
| It works to an extent, but then someone somewhere usually has
| an abstracted concept of priority, otherwise you end up with
| priority as per the "highest paid person's opinion".
| twic wrote:
| > Assign to a single person.
|
| That doesn't work in teams with collective code ownership, ie all
| successful teams. But you can replace this with "assign to a
| single team" and i think it works much the same. The footnote to
| this says:
|
| > For larger teams, that can be a team account, but in that case,
| it is team leader responsibility to go through all team owned
| tickets regularly and delegate them
|
| But that isn't correct. You can have a team pull from a single
| queue of tasks assigned to the team as a whole. There's no need
| to proactively assign them to individual team members.
|
| > Every team must have a single ordered queue of tasks.
|
| As long as you understand that "tasks" does not encompass
| technical housekeeping tasks like refactoring, improving the test
| pipeline, etc, sure. The queue of tasks needs to be ordered by
| someone with customer/business/domain knowledge. There's a
| negligible probability that this person is also expert enough to
| prioritise housekeeping against feature work. But the development
| team itself can do that, no problem.
|
| > I advise to start with the "Todo", "Doing" and "Done" triad and
| only add more if absolutely required
|
| This sounds good. My one thought is that there are usually
| different people who can say "i think this is done" (the
| development team) and "yes, this is done" (product owner / QA /
| etc), so i suspect todo/doing/ready/accepted as the minimal set.
| But you could find a way to make three states work, i'm sure.
|
| > When people scream "this is a bug", it is irrelevant what it is
| caused by
|
| It's relevant to estimating velocity. If over a quarter, you
| estimated you'd do a hundred features, but actually did one
| feature and ninety-nine bugs, you should not plan to deliver a
| hundred features next quarter.
|
| It's relevant to continuous improvement. If you're getting a lot
| of feature requests, great, carry on. If you're getting a lot of
| bug reports, not so great, slow down and see how you can improve.
|
| > Saying "no" is hard, but without it, the issue system becomes
| an unmanageable mess.
|
| We must recognise this as simply being an expression of the
| author's deletionist aesthetic preference, not a fact about the
| world. As long as you know what the most important tasks are, it
| doesn't matter if there are an infinite number of less important
| tasks behind them.
|
| > Yet I do believe this is actually a property of any job
| position: people rarely want their job to disappear. The moment
| you create a job position, it tends to metastasize.
|
| Very strong truth! My third (?) law is that if you hire someone
| to do something, then that thing will get done regardless of
| whether it is actually useful. I am most often reminded of this
| law when dealing with security people.
| lazyant wrote:
| I enjoyed and mostly agree with these ideas. Some points though:
|
| Re: Position In a Queue
|
| > Every team must have a single ordered queue of tasks > every
| single one of them is prioritized relatively
|
| This may lead in Eisenhower's matrix to prioritize urgent tasks
| vs important tasks and end up with tech debt.
|
| I lead a soft eng team and we have a task queue but they are not
| prioritized (and that may be a mistake). Beyond the time wasting
| agonizing if X > Y for tasks, I like to keep parallel tracks of
| urgent (blocking) and tech debt tickets.
|
| Re: Ticket Type
|
| The most or one of the most important metric in software is user
| angry or happy calls (a proxy for revenue). If an unannounced
| planned feature doesn't make it to the next release, nothing
| happens. But if the customer now sees a regression bug (something
| that worked suddenly doesn't) that's bad. There's value in
| differentiating bugs from features, at least in some industries.
|
| Re: Software Version
|
| See Semantic Versioning https://semver.org/ ; it's important to
| know if a release is backwards-compatible or not
| taftster wrote:
| A bug report does not imply a user is angry or not. Software is
| shipped with known bugs which often go unfixed. And a lack of
| features can be just as critical of an impediment for a user.
| So neither bug nor feature can fully describe the effect that
| an identified issue has on its overall priority.
|
| An angry phone call doesn't universally change the order of
| work for all companies. Some projects might rate this event
| more importantly than other projects. Most angry phone calls
| are a result of usability problems not strictly feature
| defects. So there's no direct correlation here between user
| product sentiment and backlog priorities, unless your company
| culture adds that correlation.
| lazyant wrote:
| thanks for this nuances.
| jpswade wrote:
| Much of this is only from the perspective of the consumer, a
| developer.
|
| What businesses want is a way to be able to track progress and
| communicate priority.
|
| The difficulty for the the business is how they communicate
| _their_ priority to you, that 's what the priority field is for,
| it's a way for the person raising the issue to supply a way to
| communicate how important an issue is to you.
|
| The position in the queue is how you (and presumably your team)
| should decide what order to tackle the work in.
|
| The final point is the solution to the problem is to create
| another system for issues, which goes against the point that says
| "every team must have a single ordered queue of tasks".
|
| I find it interesting that the solution to, in their own words,
| "One of my life's traumas" is to add another issue tracking tool.
|
| Are we trying to fix the right problem?
| mytailorisrich wrote:
| In general tickets describe change requests, and they are
| sometimes referred to as such (CRs): Someone wants the
| software/system to change in some way.
|
| A ticket type makes sense because bugs and new features are not
| the same and we should care about the difference. A bug is a
| defect in the implementation of a feature that should be fixed. A
| good practice is to fix defects before adding new features, as
| far as possible. A defect is discovered on a specific software
| version so it then makes sense to indicate that. Even with
| continuous delivery it is useful to know exactly what build
| exhibited the issue. Having explicit information on whether a
| ticket is a defect or a new features is also helpful for QA (as
| is severity): I need to keep track of the number of defects found
| in order to somehow measure the quality of my software and of my
| testing and to improve it.
|
| Assigning a priority makes sense because it helps setting the
| ticket's position in a queue (which can be called TODO list).
|
| Severity is not the same as priority. Severity is the impact of a
| defect. A defect that causes the application to crash and delete
| all data is very severe. A typo is likely not a severe defect.
| Again that helps in assigning a priority and thus how to insert
| the ticket in the TODO list.
|
| The position in the TODO list is not an input it is an output of
| the task that consists in analysing and managing the pending
| tickets.
|
| You could say that a dev is a worker task that picks the next
| ticket in the TODO list in a loop, while a (project) manager
| manages the tickets and insert them in the TODO list.
| Almad wrote:
| This analytical approach is exactly what I disagree with.
|
| > A good practice is to fix defects before adding new features,
| as far as possible
|
| This is the approach I describe as "bug is a proxy for
| priority", where you are essentially saying it's "highest". It
| is a good approach in theory, but just ignores business
| realities.
|
| It also means people will try to disguise feature requests as
| bugs in order to get a priority.
|
| > Assigning a priority makes sense because it helps setting the
| ticket's position in a queue
|
| Except if it's numerical, then over time, you can safely ignore
| everything that's not P1 and you have few dozens/hundreds of
| unprioritized tickets.
|
| > Severity is not the same as priority.
|
| I know. Why is it important to make the distinction though?
|
| > The position in the TODO list is not an input it is an output
| of the task that consists in analysing and managing the pending
| tickets.
|
| Agreed.
|
| > You could say that a dev is a worker task that picks the next
| ticket in the TODO list in a loop, while a (project) manager
| manages the tickets and insert them in the TODO list.
|
| Well, if dev is a factory worker turning inbound tickets into
| outbound features, yeah, cool, this works.
|
| I am yet to see this in practice. Team (or at least team lead)
| is taking active role in the managing cycle and this is exactly
| what renders a lot of your points at least duplicit.
|
| (But you have a lot of good points about assumptions about team
| organization that should be mentioned)
| mytailorisrich wrote:
| This analytical approach is the reality of managing tickets
| taking technical and business realities into account.
|
| A bug is not a proxy for priority. As said it is a parameter
| that helps defining a priority and, in fine, the position in
| the TODO list. Whether priority is "high", or P1, or whatever
| is exactly the same. Usually there no need for too many
| levels because, as you suggest, it mostly boils down to
| "now", "afterwards", "whenever", and that changes over time
| (hence Agile ideas).
|
| BTW, I have never seen someone disguising a feature request
| as a bug. That is totally unrealistic not least because
| obviously this is continuously scrutinised and someone doing
| that would be called out and ultimately fired for shear
| incompetence (or worse) and because features go through a
| definition process, it's not someone who suddenly dreams one
| up and sneakily hide it in a bug report to have it
| implemented without anyone noticing (what?!)
|
| The distinction between severity and priority is important.
| Severity is assigned by the person who reports a defect. It
| is a measure of how serious the impact of the defect is, as
| said. Priority cannot be set at that point, as it is a
| judgement made later based on further considerations.
|
| Devs really are as I described in teams that have matured and
| are organised (but maybe not in "messier" startups). A team
| lead is not a dev, 'lead' implies a managerial aspect.
|
| Lastly, of course you need to keep track of the number of
| defects (which can be from customers feedback and production
| metrics) and of their severity. This is basic QA, you have to
| know if you are effectively doing a good job in order to
| improve both your internal processes and the quality of your
| product.
|
| For example, if I start to see too many critical defects on a
| component/team I know we have a problem there. If I start to
| see too many critical defects found after the product has
| shipped I know we have a big problem.
| Almad wrote:
| I'd agree with you if I would be only seeing the teams
| through my management reports and not from the trenches.
|
| I am envious of the environment where you never saw
| somebody trying to bug feature request as a bug. I do think
| in a lot of cases, it's a judgement call...or a habit where
| problems perceived as bugs by customers are swung under the
| carpet as features as bug is only defined as "deviation
| from requirements".
|
| Fair on distinction of severity by customer vs priority by
| team, although I am used to make a distinction between
| support ticket by customer and issue in engineering team's
| queue.
|
| Lead implies either managerial or technological leadership
| and especially in mature organisations, I've seen both.
|
| My experience with management by bug statistics is...very
| inconsistent as it motivates people to game the
| system...and boy I've seen that a lot. I do agree trend
| knowledge helps, but I am not sure it's worth the side-
| effects and work.
|
| Of course, a flavor of this depends on context (and scale).
| It is very different if you have a single-instance SaaS,
| distributed system or images shipped to air-gapped systems.
| mytailorisrich wrote:
| > _I am envious of the environment where you never saw
| somebody trying to bug feature request as a bug._
|
| Really, I have never seen that in 20 years.
|
| Of course that is different from another team or the test
| team raising a bug because they expected something that
| was not in the spec. Then you tell them that it's not
| because it does not behave the way they want that it is a
| bug. But, yes, a defect (more general term than bug) is
| any deviation from requirements.
|
| Direct input from customers is different as well. Unless
| there is a contractual impact, if a customer is adamant
| something is a bug when it technically isn't then there
| is no point arguing. You can treat the request however
| you want internally.
| yiyus wrote:
| > It also means people will try to disguise feature requests
| as bugs in order to get a priority.
|
| If my car breaks and cannot start, that's a bug. If I want to
| add a radio to my car, that is an extra feature. The
| difference exists, and it is important. You are saying this
| difference should be ignored because someone may try to pass
| the desire for a radio as a broken car. At that point, you
| could just ignore any issue because it may be a lie.
|
| And the reason to categorize is not only to prioritize. For
| example, we have these rules: bugs require of a test case,
| and the test must pass to consider close the bug. On the
| other hand, new features are implemented first in a different
| tree, and the new feature needs to be documented (also in the
| tutorial). Moreover, we may have meetings to decide if we add
| a feature or not (for example, different new features may not
| work well together or may require extensive refactoring that
| we do not want to do), while a bug must be fixed.
|
| In your workflow, this distinction may not be important.
| That's perfectly possible. But, in my opinion, claiming that
| "we collectively shouldn't care" is going to far (unless "we
| collectively" means something more specific than it looks to
| me).
| emmelaich wrote:
| It is a fantastic article Almad, thanks!
|
| About the only thing I might add is dependencies. But even
| that is mostly value for management reporting and time
| estimation. It doesn't help the workers do their jobs that
| much.
| Almad wrote:
| Thanks!
|
| Yeah, this is something worth a separate article (this one
| felt long already): ticket systems as reporting tools.
| Almad wrote:
| > I need to keep track of the number of defects found in order
| to somehow measure the quality of my software and of my testing
| and to improve it.
|
| I would love if you could expand on that. Do you really need
| it? Is this more important than production metrics or customer
| feedback?
| kazinator wrote:
| The Software Version field should be used to identify the commit
| when the bug was introduced (perhaps the very first commit that
| introduced the entire thing in which the bug is found or perhaps
| a regressing commit). The way it's typically used is not helpful:
| namely that the user who reports the bug just fills in the
| version they happen to be running when it happened.
|
| There should be an Introduced-in Version and Fixed-in Version.
| taftster wrote:
| These fields aren't required for a good ticket system to work.
| They might be useful in terms of post-mortems, generating
| changelogs, etc. But fundamentally, the "version" that a issue
| was resolved in is not a requirement of the ticket tracking
| system. Some continuously deployed software doesn't really ever
| have a version number at all.
| taftster wrote:
| Great quote from TFA:
|
| _> Once you start assigning priorities from a list, anything
| else than "Highest" is a passive-aggressive way of saying "No"._
|
| What can be gamed will be gamed. Once you start applying the
| equation "feature = good & defect = bad" or assigning arbitrary
| priorities "high, really high, now, yesterday", you are in effect
| providing opportunity to game the system.
|
| Story points have this quality. More points are good, less points
| are bad. Let the games begin.
|
| The value of a ticket / work-item comes strictly from the changes
| made to the underlying system. The "diff" effectively. The labels
| and types that we assign to work-items don't actually add any
| real value to the system.
| gilbetron wrote:
| > The toolset that completes the version control log to form the
| development equivalent of double-entry bookkeeping.
|
| This made me wish for a "git commit --future" that lets you just
| track future things to work on within git itself. "git stash" is
| kinda connected into this concept as well, branches too if used
| as development caches. It gets a bit wonky with multiple repos,
| as well as non-code related tasks, but then we have a single
| location for tickets, and a UI could be created to connect with
| other teams.
| dboreham wrote:
| For me none of the SaaS bug tracking systems are usable. They're
| all much worse than c. 1996 Bugzilla.
| berkes wrote:
| The only system that I appreciate is taiga. It's extremely
| opinionated and quite un-configurable.
|
| What I like about it, is that it enforces workflows (either
| scrum, kanban or simply one-large-backlog) The Way They Were
| meant. So it solves a lot of bikeshedding and solves me & my
| team from trying to invent "something that works for us".
|
| The idea proposed by OP works quite well there too, with
| kanban. Just pick the card at top, and never have more than one
| card per working person in "active" at any time.
| emmelaich wrote:
| A quick web search gives me taiga.io, taiga.pm.
|
| What's the diff if any?
| Almad wrote:
| Oh cool, didn't knew about it and it looks like it may be the
| sweet spot.
| gitgud wrote:
| Github issues works pretty well for almost all software projects.
| A single list of issues viewable/searchable by the whole team,
| simple commenting, code referencing, tagging, assigning to
| people.
|
| We tried Jira but became tangled in a mess of complex
| configuration and endless confusing UI's...
| karatestomp wrote:
| You only need something more complex or heavy than GH issues
| (if even that complex) if you've got someone bugging you for
| burndown charts and metrics and shit just _all the time_ , or
| someone in the chain who just _loves_ poking around and
| dragging shit from here to there ( "oh goody I'm going to drag
| this into 'on ice', best day ever!"). The dragging action I
| don't bring up accidentally--it's very important, for some
| reason.
| Almad wrote:
| The main problem I had with them is inability to sort them in a
| list, which is somewhat solvable with GH Projects now.
| randomdata wrote:
| For most projects, sorting leads to prioritizing, which is an
| anti-pattern. For those who choose to eschew proper software
| development practices, it is nice that Projects is its own
| thing.
| aflag wrote:
| I don't think that prioritizing in general is an anti-
| pattern. You will do things before other things and you
| need to choose what to do first. The criticism in the
| article was about bad prioritization. With GH Projects you
| can have the liberty to queue issues however you may see
| fit.
| randomdata wrote:
| The anti-pattern is premeditating priority. It is true
| that you have to consider all angles and ultimately
| determine where to start, but once you've done that it
| makes no difference where an issue lies in a list.
| rurban wrote:
| There is a huge difference between a TODO and a FIXME.
|
| A FIXME cannot be in master, but TODO's all the time.
| uxamanda wrote:
| Nice, this highlights a lot of issues I've seen with teams and
| crazy bug systems.
|
| One difference I had from the article is that I actually find
| marking tickets with priority and types (like bug / enhancement
| etc) useful, but for a different audience.
|
| When I'm working on planning / strategy, aka in Product Manager
| mode, I like to be able to review what is still remaining in
| different buckets and adjust priority and do scenario planning.
| Maybe it's worth closing a whole bunch of low priority bugs
| before moving on. Often the priority changes over time and gets
| adjusted as we see what came in. Having a place to track that
| info on the ticket keeps me from moving to doing planning in a
| spreadsheet.
|
| When I'm in developer mode, I agree - I don't want to have to
| think about what the priority of a critical feature improvement
| is vs a low priority bug. I want to pick off the top of the stack
| and flow with confidence.
|
| I often am working in both roles on team projects and use this
| technique even when working alone.
|
| In my experience where things get weird is when the product
| planning metadata is required to be understood in real-time by
| all roles on the team. You can keep all that metadata around and
| still have a single prioritized backlog.
|
| Maybe Jira could be improved by showing different metadata for
| different modes... but even writing that out sounds like a new
| configuration nightmare!
| adrianmsmith wrote:
| > there should be an algorithm that everybody should agree on. An
| example may be:
|
| > - If there is downtime, it's the top priority of everyone
| affected
|
| > - If there is an incident, it's the top priority for an on-call
| agent
|
| > ...
|
| Very much agree about this.
|
| The trouble with "high priority" and "low priority" etc. is that
| different people perceive different things as having different
| urgency and importance. As long as you have >1 person entering
| tasks, each using their own algorithm to assign priority, a "sort
| by priority" (the only point in having a "priority" field at all
| as far as I can see) becomes completely useless.
|
| If you use names like "downtime" or "incident" then, as the
| author writes, everyone can agree. That's the important thing I
| think. Then a "sort by priority" can yield something meaningful.
|
| Plus there's the fact that when you have pages of "highest
| priority" tickets, managers just create all new tickets at that
| level, "otherwise they won't get seen and done" (true story)
|
| This way of working annoyed me so much I wrote a blog post about
| it: https://www.databasesandlife.com/priorities/
| mytailorisrich wrote:
| "Downtime" as a consequence of an issue is 'severity', not
| 'priority'. But yes there needs to be a clear and consistent
| definition of what the different levels of severity mean. This
| is usually the case because people will quickly notice that it
| quickly gets messy if everyone makes up their own.
|
| But, as I mention in another comment, severity does not
| directly map to priority. Something like severity x frequency
| (classic measurement of risk) is already getting close, but
| ultimately it is often a judgement call based on other business
| considerations as well.
| JamesSwift wrote:
| I think you misunderstood his point. He is saying that in his
| system severity == priority. His article he linked lists out
| explicitly his buckets.
|
| Within a given severity I think its then a judgement call of
| a product owner to rack-and-stack the issues in priority
| order, exactly how it would be done for traditional 'P1' -
| 'P5' grading.
| adrianmsmith wrote:
| I must confess I've never really understood the need for
| "severity" in a task tracking system.
|
| As far as I can see, consumers of tickets need to know what
| order to do stuff in, and producers and organizers and
| curators of tickets need to set what order things should be
| done in. That's "priority" or "urgency".
|
| I do understand in a theoretical sense that "Prod system is
| down" might not _always_ be the absolute highest priority
| thing to work on. If a particular issue causes a downtime of
| 1 second every 10 years, it 's still downtime, but might not
| be the most urgent thing to work on.
|
| But that's a theoretical example. In my 20 years of software
| development and managing projects, if the Prod system is
| down, it's an emergency, and that's what you need to be
| working on. So "Prod is down" is a useful priority/urgency.
| At least that's been my experience so far...
|
| What am I missing? Are there times when priority and severity
| are useful as two separate fields?
| mytailorisrich wrote:
| Priority vs severity is an all time classic.
|
| "Severity" is a measure of how serious the impact of a
| defect is (Using the term "impact" instead of "severity"
| can make things clearer). It does not say anything about
| the priority that should be assigned to fixing it, though
| it is obviously often correlated.
|
| Severity is an absolute metric, priority is a relative
| metric.
|
| In general the person who creates a defect ticket sets its
| severity based on what has been observed. The priority is
| set later by project management.
|
| > _If a particular issue causes a downtime of 1 second
| every 10 years, it 's still downtime, but might not be the
| most urgent thing to work on._
|
| Exactly. There may be a _severe_ issue but because it
| happens so rarely it is probably not urgent to fix and thus
| may be assigned a low _priority_.
|
| Of course if the issue "prod is down" is both severe and
| urgent to solve. But after investigation you may find the
| root cause and determine that it is costly to resolve while
| occurring only very rarely and thus that root cause issue
| may be low _priority_ though it is still high _severity_.
|
| The difference really is useful in practice where the
| effort and cost of solving issues may not be trivial (large
| systems and systems involving hardware for example). I have
| seem severe bugs that were tracked down to ASICs deployed
| in the field, so very expensive to fix, and for which the
| fix was deferred to the next product version because it was
| determined that the issue was rare enough that customers
| could live with it until then.
| wbeckler wrote:
| It sounds to me like you're describing Pivotal Tracker
| (https://www.pivotaltracker.com/). It forces story ordering
| (rather than "prioritization"), it's pretty barebones, and it's
| fast.
| jpswade wrote:
| Both Jira and Trello allow ordering, how does this differ?
| hyperpape wrote:
| One missing thing: maximize the number of things that can safely
| avoid going through the bug tracker, because the tracker
| represents overhead and (even more importantly) latency.
|
| Does that marketing website typo fix need to go through the
| development team and require a ticket? There are reasons it
| might, but fixes will never really be fast enough if it does.
|
| Or worse, what if a developer has to ask someone to create a task
| and add it to the board to add documentation to a method? Then
| either no will ever document anything, or they'll sneak those
| changes into other tasks, slowing down code review and feature
| development.
|
| One way you can create those pathologies is to have auditors, and
| promise the that "all code changes follow a process" and soon
| you're signing forms in triplicate to make any kind of change
| whatsoever.
| nicbou wrote:
| This sums up why I like Kanban.
|
| The TODO column is an ordered list of things to do. The job of
| the developer is to pick tasks from the top and move them towards
| the right. The task of management is to keep the TODO column
| sorted, and prevent tickets from being stuck in any other column.
|
| The task of management is aided by limits on how many items each
| column contains. Those limits are based on how many things people
| can realistically do at once.
| junon wrote:
| I disagree. Who is sorting those tickets? Are they sorted
| arbitrarily or were the technicals considered? Is the ticket at
| the top feasible given the current state of the
| codebase/product?
|
| In theory this would work, but it has the pre-requisite that
| whomever is managing tickets understands technology - which, in
| my 10 years in the field, has been quite rare.
| nicbou wrote:
| They are sorted according to the project roadmap, usually by
| a person who understands business requirements, and a person
| who understands reality.
|
| In my experience, it's usually done in a weekly meeting that
| involves a small subset of the team. We don't need to
| estimate tasks. We only need to know their logical order
| (dependencies) and priority (requirements). We don't need the
| whole team present for that.
|
| If the requirements or reality change during the week, there
| is no cost to reordering the todo column. It doesn't change
| how much gets done, just in which order it gets done.
| Almad wrote:
| In my experience, the final sorting needs to be done by a
| collaboration between ticket manager and someone-who-
| understands-technology anyway. If the ticket manager doesn't
| have a clue, they can't make judgement calls necessary as for
| nontrivial software, it can be hard to say if this is one day
| or one year of work.
|
| And that affects prioritization a lot.
| nicbou wrote:
| That would be me. My job is to clarify requirements, gather
| assets and prepare tasks so that tickets spend less time in
| progress.
|
| This involves adding a triage column before the todo
| column. This column is for tickets that are necessary, but
| not prioritised or ready to work on.
| berkes wrote:
| I appreciate how clearly it is written down. It is how I would
| like to work and have tried at numerous jobs.
|
| I do find that reality is hard, though. There's always that
| moment when you don't feel like picking "the one at the top".
| Maybe because you have time for "a quicky" maybe because after
| spending a week on Foo, you now want some Bar?
|
| What this also does not solve is the "panic shifting". When a
| business goes into panic mode (deadlines, rough patch, downtime,
| chaos) you'll often see that tickets get moved from underneath
| you _while working at them_.
|
| - Holdit, I'm done 80% with that SuperImportantEmergencyBugfix.
| Can I not finish and deploy it? - No, there now is a
| SuperEvenMoreImportantEmergencyBugfix that has to be fixed two
| hours ago.
|
| No ticket system will fix that, but anything that helps with
| those moments is very helpfull, I guess.
| nicbou wrote:
| In my experience, it worked better with Kanban.
|
| The "top ticket first" approach forced us to improve knowledge
| sharing in the team. In practice, you can pick the second
| topmost ticket if it doesn't affect the schedule. You're a
| grown up.
|
| The tickets you work on should not be based on your feelings,
| but on actual priority. In practice, if you feel like it won't
| affect the schedule, go for it. You're a grown up.
|
| In my experience, panic shifting is more manageable with
| Kanban. Tickets aren't given arbitrary deadlines, so shifting
| them around doesn't change the order of work, but not the
| intensity of work. Bringing one ticket up pushes every other
| ticket down. Nothing gets squeezed into the sprint.
|
| As for interruptions, it's a matter of urgency. Usually, Kanban
| dictates what you do next, not right now. There's also a limit
| on how many tickets you can have in progress. In practice, it's
| up to you to decide if a task is urgent enough to interrupt
| your work. You're a grown up.
| wpietri wrote:
| > There's always that moment when you don't feel like picking
| "the one at the top".
|
| A few solutions for this that have worked for me:
|
| * Small units of work
|
| * Having a tech-debt backlog broken into short lumps of
| cleanup, so you can "take a break" with something different
|
| * Pair programming with frequent pair rotation. The next ticket
| is always taken by the next open pair, but you can work one
| something different every few hours if you need.
|
| * trade tasks with a colleague
|
| * sighing, saying, "well, this is my job," and picking the top
| thing anyhow
| ehnto wrote:
| Priorities changing is one of the more frustrating parts of
| doing client work. Business priorities can change for so many
| different reasons, and you just have to learn to let go. I've
| seen entire product lines disappear the week a singular person
| leaves the company. Product in boxes, ready to ship, no longer
| needed.
|
| If you are in an environment like this though, try to do very
| atomic commits as you go. Often you can salvage some work for
| the betterment of the platform even if the whole feature is not
| needed. Maybe you did some refactoring, if that's in a neatly
| organised commit you can just cherry pick it right out of
| there.
| Etheryte wrote:
| I think an important consideration is important for whom. If
| the only reason something is important is because of an
| arbitrary management deadline, the right response is to stand
| your ground and calmly finish working on what you already
| picked up. While I understand it's easier said than done, if
| you don't stand your ground, it won't get better. The polar
| opposite of this is when I personally broke something and it's
| stopping others from doing their work. In that case, the right
| response is to drop what I was or wanted to be working on and
| fix the issue.
|
| An extra case of all of the above is planning work around big
| releases and the like. Regardless of how solid your CI pipeline
| is, if there's a bigger change set released, it's good to have
| someone who's designated on call. They're free to work on their
| stuff if they please, but their main priority for that whole
| day is the delivery. If anything is fishy, they're the guy who
| picks it up first.
|
| None of the above happens without good communication. To get to
| good procedures you need to take the time, discuss with your
| team, and agree on what your plan of operation is. Make sure
| it's clearly communicated both inwards and outwards. If anyone
| internal or external comes to you with a fire, you can point
| them to your plan. It may be urgent to them, but that doesn't
| mean it overrides your team's agreements.
|
| With all of the above in place, the scenario you described
| changes considerably: instead of asking whether you can finish
| your task, you will instead inform the other side that you're
| going to finish your task, and if it fits your plan, then deal
| with their problem. At the end of the day, it's a matter of
| mutual respect -- it doesn't matter what the org hierarchy is,
| they're asking you for help, they can't demand it.
| TheRealPomax wrote:
| As an employee of the person telling you to drop your current
| work and go work on something else, it literally doesn't
| matter "for whom", you do it because you want to stay
| employed rather than doing "what's right" and getting fired
| over it. Standing your ground if you don't have solid
| seniority first is about as ridiculous advice as a parent
| telling their 7yo to "just tell them to stop" when they're
| getting bullied. You don't have ground to stand on, and even
| if your input is right, and well reasoned, it can't come
| _from you_ because your voice has no weight.
|
| By all means, try to change the system, but telling others
| they should too is advice from an extremely privileged
| position.
| Etheryte wrote:
| I sincerely disagree. Taking the extreme case you described
| as either do it or be fired, the other party wants a
| result, a task done or something similar, which still won't
| be done if they would fire you on the spot. It seems you
| misread my reasoning as blindly standing your ground which
| is not the case I was making. If there is a good reason to
| switch what you're working on, you should, as I also said
| above. But if there isn't one, you should either ask until
| you get a good reason or stand your ground.
|
| The argument from privilege frankly confuses me. I've
| applied the same principles both when I've been the
| underdog and the one asking others and it's good guidance
| since it also gives you input whether you want to work
| where you currently are. Sometimes I've had harder times
| because of it, but I've never stayed in an abusive work
| relationship.
| cerberusss wrote:
| I remember when I had ~3 years of working experience. We
| were on the tail end of a fixed price/fixed date
| contract. There was a bug that needed to be fixed, and it
| was in a module that everybody had worked on, and the
| code was pretty bad.
|
| So during the meeting, I said: that bug is just a
| sympthom, the module needs to be rewritten. And I knew
| what I was talking about.
|
| No, said a senior, we're just going to fix the bug, no
| rewriting. I said that's your call, but I sure am not
| going to fix that bug. I can tell you: nobody listened to
| me.
|
| So he more or less finished the discussion and said: I'm
| going to sit down with you, and we're going to fix that
| bug. And we did.
|
| At that point it was the right call.
| Etheryte wrote:
| In that case there clearly is a good reason though? In
| the scenario described, you have one known bug, in the
| case of a rewrite you have an unknown number of bugs.
| Surely, both approaches may have more unnoticed bugs in
| them but in the former case people have already tested
| the solution so that's less likely. When you rewrite, you
| enter new untested territory with more room for new bugs.
| TheRealPomax wrote:
| Every junior and intermediate dev would like a word with
| that concept, because it sounds magical. Once you have a
| few years at an org under your belt, you have the creds
| to pipe up, but until then, you either talk with the
| better devs in private and hopefully convince them, or
| you do what your boss told you to do.
| WrtCdEvrydy wrote:
| I will usually drop a small comment saying 'deprioritized
| due to OTHER_TICKET_NAME' and mark the ticket as Done.
| eska wrote:
| Yeah, the best you can do at that point is to meticulously
| document your work. You don't want to look unproductive and
| get fired just because you're constantly stopped from
| releasing your work. And in the case that you do get fired,
| you will want to give your lawyer some ammunition in the
| form of work logs outside of the ticket system, which you
| will be barred from.
| nix23 wrote:
| First i do what my boss says, when i did that and we both
| have a little time to talk, i explain to him why i was
| thinking the other stuff was more important, often he has a
| good point from a complete different perspective than i
| have, sometimes i 'win' from my 'technical' perspective,
| after some time passes you learn to read each other and
| decision's are made without questions, for me its super
| important to know each others and the base where decision's
| are made.
| crdrost wrote:
| There's a great manufacturing-management book that regrettably
| speaks to a manufacturing context and not a project context and
| therefore applying it literally to our software projects would
| be a fallacy, called "The Goal"--and then the rederivation of
| the same principles for project management is in a follow-up
| book called "Critical Chain." They are both weird in that they
| are textbooks written as novels and therefore you do have to
| roll your eyes a little bit, of _course_ when the beleaguered
| manager follows the smart scientist's advice his company
| succeeds and his marriage gets better, sigh. And why is it a
| he, both times? But if you pay the cost of these eye rolls you
| get some joyous moments.
|
| For instance, your "panic mode" is discussed in The Goal (as
| "factories that seem to have three priority levels: Hot, Red
| Hot, and Do It NOW!!!") and the emergence of those panic modes
| is actually diagnosed as a failure of those first principles.
| If you had managed differently, you would have been aware of
| your spare capacity, and this panic mode instead becomes a
| business problem of some sort--either you are not getting
| enough biz value out of your "SuperImportantEmergencyBugfix"
| project to justify continued investment of developer time or
| you are not getting enough biz value out of the
| EvenMoreImportant project or else you are getting enough
| business value out of both that it is time to expand your dev
| team so that your bottom line can get better sooner. But rather
| the panic is usually because the two projects are not
| profitable either way, and the company was willing to take a
| loss to build them up to profitability, but now revenues have
| gotten unexpectedly tighter and people are trying to
| fallaciously optimize on cost rather than marginal profit.
| jrs235 wrote:
| I need to reread The Goal again.
|
| "people are trying to fallaciously optimize on cost rather
| than marginal profit."
|
| Pure truth.
|
| Another great book is The Principles of Product Development
| Flow: Second Generation Lean Product Development
| twic wrote:
| The Phoenix Project is a software instance of one of these
| textbooks-as-novels:
|
| https://itrevolution.com/book/the-phoenix-project/
|
| https://itrevolution.com/wp-
| content/uploads/files/PhoenixPro...
|
| And Commitment is about software projects, and is a graphic
| novel (with a female protagonist!):
|
| https://hennyportman.wordpress.com/2016/05/29/review-
| commitm...
|
| I'm also reminded a bit of Simon Wardley's dialogues with X;
| these are just a roundabout way of him expressing his
| thoughts, but because they're structured as a debate, i think
| he gives himself a bit of unearned authority when he runs
| rings around his imaginary opponent:
|
| https://twitter.com/swardley/status/1082647878349324288
| lazyant wrote:
| The Phoenix Project has several main characters but
| arguably the main one is also a woman, as well as other
| characters (meaning not only one).
| thombat wrote:
| Our company became determined to control such panic-driven
| prioritisation, and had four simple levels of importance, P4 up
| to P1, a predictable conveyor belt delivering work.
|
| Equally predictable was the later addition of P0. Followed
| inevitably by P-1. Sadly the company was bought out before we
| learnt whether the underlying datatype was a signed short or a
| long...
| VBprogrammer wrote:
| That is so familiar that I seriously wondered if we had
| crossed paths at a previous job. The only difference being
| our priority was the other way around P4 being the highest.
|
| Basically all tickets would naturally migrate to P4.
| Eventually when someone started working on 'the wrong thing'
| another level was added.
|
| In my current job we use Jira and the backlog has things at
| the bottom which have been just added, things at the top
| which we thought were priorities at some point and a whole
| bunch of crap in the middle which is unordered.
|
| I keep thinking about some kind of system where people would
| rate the priority of one ticket against each other rather
| than against an arbitrary scale.
| jschwartzi wrote:
| That's the whole point of that backlog. The order should
| reflect the priority of everything relative to everything
| else. You drag stuff up above other stuff that is lower
| priority and part of everyone's job is to groom that list
| so it reflects reality.
| VBprogrammer wrote:
| While that may be true in theory in practice it is
| difficult. A big improvement would be if new things
| needed to be inserted into the backlog at an appropriate
| place but I don't know if it's possible to do that in
| Jira.
| mumblemumble wrote:
| This, I think, is exactly why everyone I know who is
| happy with their backlog management does it in an Excel
| spreadsheet or Google Sheets.
|
| I'm fine with ticketing systems for handling immediate
| work in progress. Which, incidentally, is what they're
| meant to be used for. Every time I've ever seen people
| try to juggle business priorities and long-term goals in
| a ticketing system, though, the end result has always
| struck me as being something of a failed experiment to
| develop a product that works well as both an ice cream
| topping and an engine lubricant.
| travisjungroth wrote:
| That ticket comparison idea is awesome. You could have it
| for one person, or do it democratically.
|
| I bet there'd be circular comparisons (A>B>C>A) a
| surprising amount of the time. Not a huge deal, you could
| just show the pairings back again in a different order
| until they resolve.
| mytailorisrich wrote:
| This does not mean that having priority is not useful, this
| just means that they did it badly.
|
| Everything is prioritisation. I'd say that prioritisation is
| one for the key skill of people leading organisations.
|
| People who can't do it will fail whatever tools they use.
| vincentmarle wrote:
| This works well in theory, until managers urge you to treat
| every task as "P-0" and you suddenly need to prioritize
| within the P-0's (we would jokingly use negative numbers
| instead).
| ehnto wrote:
| I've seen good success with having an entirely different
| pipeline for rushed/rapid/panic tickets. The rapid pipeline
| reduces some of the ticket and procedural bureaucracy of the
| normal pipeline, and only lasts a sprint. That obviously
| comes with risk, so putting something in the rapid pipeline
| needs to be weighed properly.
|
| The somewhat untold benefit of this system, is it makes the
| product manager or client decide between "I want to control
| this ticket" and "This needs to be done as fast as possible".
| That seems to naturally filter out tickets that are only
| superfluously high priority.
| dataduck wrote:
| This seems interesting but I'm having trouble visualising
| it. Would you care to elaborate?
| ehnto wrote:
| Sure!
|
| A standard ticket pipeline might look like this: Backlog
| > Review/Estimate > In Progress > Internal Review >
| Testing > Client Review > Feedback > Testing > Release
|
| But the rapid pipeline will be more like: Create Ticket >
| In Progress > Testing > Release
|
| This leaves the ball almost entirely in the developers
| court, and removes any step that requires waiting for
| feedback from the client or even the Project Manager.
|
| So you can see the risk factors pretty quickly, with no
| review steps what if the developer gets it wrong? So that
| leaves the Project Manager some important questions: Is
| this ticket concise enough to be rapid? No room for back
| and forth discussions or muddy details. Is this ticket
| small enough to be rapid? Can't be a big new feature
| that's just being framed as urgent but could
| realistically wait. Can I trust the developer to get this
| right with no review? If you can't, then it's probably
| best it goes through the standard pipeline with the
| review steps anyway.
|
| In big enough teams it can help manage workload, you can
| leave a specific developer intentionally under-utilized
| so that they have space for rapid tickets. During their
| under-utilized time they can be open for
| mentorship/learning/pair-programming until a rapid ticket
| pops up.
| medius wrote:
| To tackle this, I highly recommend the percentile technique
| from MIT paper, "A Structured Approach to Strategic Decisions".
| [1]
|
| If you are judging any dimension, say priority, then assigning
| percentile rating to a task (i.e where does this given task
| stand relative to all the others) can be quite helpful to
| overcome the "SuperEvenMoreImportantEmergencyBugfix" cases.
| This is what the article is also suggesting.
|
| And if you end up assigning 90% percentile to more than 50% of
| the tasks, you know your judgement is wrong, and it can be
| corrected accordingly. And it can also be standardized much
| better across the organization. Everyone can now judge their
| own judgements.
|
| Rating on multiple dimensions with low correlations important
| for your company, say signup rate, retention, security, etc.
| and adding them up is a good way to not miss something
| important. It's not important to assign weights. Equal weights
| is fine [2]
|
| I'm finding this technique quite useful in deciding what to
| work on next with fewer doubts about their priority. I failed
| to make Trello work for this and use a spreadsheet.
|
| [1] A Structured Approach to Strategic Decisions -
| https://omegaleadership.com/media/Structured_Approach_to_Str...
|
| [2] The robust beauty of improper linear models in decision
| making. -
| https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d3...
| zelphirkalt wrote:
| Time for a quicky is always good to have. When I don't however,
| I usually take that "annoying" task and see, whether I can
| divide into sub tasks. Divide and conquer often helps. If that
| does not work, I make a list of steps, which I need to take to
| accomplish whatever the task is about.
| Almad wrote:
| In my experience, the relative queue _is_ helping with that
| since you can be explicit. If SEMIEB is really more important
| than SIEB, it's fair to switch--but it should be done as a
| relative comparison / override. I mostly saw people pushing
| SEMIEB without being aware what they are pushing down.
|
| Although I would agree that if you have to reshift on hourly
| basis, this sounds more like oncall than normal dev work :)
|
| Agreed on "on the top" not always being viable / feeling like
| it, but it helps when you go top-to-bottom consciously as
| opposed to randomly.
| [deleted]
| wpietri wrote:
| The panic shifting thing is real, and for me way too many
| companies operate in permanent panic. I'm fine with responding
| to actual crises. But so much "urgent" work is really just
| managerial failure. Fake deadlines used to "motivate" people.
| Broken processes that people work around. Executives urgently
| need to look like they're doing something. Easily solvable
| problems festering until they become crises. Managers rushing
| to score points, or to cover up for earlier neglect.
|
| If everything is urgent, nothing is urgent. Even in an early-
| state startup, where urgency abounds, it's possible to work
| with a measured pace and clear focus. I've done it!
| https://williampietri.com/writing/2015/the-big-board/
|
| The fact that larger, more stable companies fail to create
| order is not because it's impossible. It's because the people
| with power either don't care or have interests that actually
| work against getting things done quickly and reliably.
| mumblemumble wrote:
| > people with power either don't care or have interests that
| actually work against getting things done quickly and
| reliably.
|
| This is what I have seen, time and time again. Decision
| makers don't work for their employer, they work for their
| compensation package. It's amazing what one can rationalize
| when one thinks it might positively impact some number that's
| mechanically tied to one's bonus.
|
| I've also seen it arise as a simple "too many cooks in the
| kitchen" situation. Ironically, the one thing from Scrum that
| I like without reservation is also the first one to get
| thrown out the window: the idea that _exactly_ one person
| gets to decide the development team 's priorities. Because if
| you allow _n_ people to collaboratively allocate a scarce
| resource, they will allocate it to _n_ * 100%, every single
| time.
| wpietri wrote:
| Agreed. Although it's possible to get people to
| collaboratively agree on priorities. I've had a lot of
| success with putting stakeholders together at at table,
| making them write down what they want on cards, and then
| saying, "Ok, put them in strict linear order of delivery."
| It helps to give them a bunch of cards with "RELEASE"
| written boldly on them.
|
| I once did this with 25 people representing a dozen
| different nonprofits, and I've done it many times at both
| startups and large companies, so I know it can work. Every
| time, people try to put things side by side. But if I
| gently say, "strict linear order" enough times, everybody
| gets it. And then they start discussing, negotiating,
| planning.
|
| Another approach, one that works if your teams are
| established enough that you can give good engineering
| estimates, was what Rob Fan at Sharethrough used for
| quarterly planning:
| https://www.slideshare.net/rfan622/launch-scale-
| presentation
|
| Basically, they gave out poker chips that represented the
| available engineering capacity for the quarter. And then
| had everybody discuss and persuade until they arrived at a
| quarterly plan.
|
| As you say, the trick is to have some way to make sure
| people don't overallocate, which they dearly love to do.
| With that in place, stakeholders stop fighting with
| engineering and instead wrestle with one another, letting
| engineers quietly get on with popping things off the
| backlog and shipping them.
| [deleted]
| stickfigure wrote:
| This describes Pivotal Tracker almost exactly. You can go into it
| cold turkey, but to get the best use out of it, it helps to be
| familiar with the Pivotal software development process.
|
| The important thing to realize is that pivotal tracker is not a
| "bug tracker" in the traditional sense - a giant database where
| issues go to be forgotten until someone clears them out in batch
| three years later. In the Pivotal process there is a product
| manager whose primary responsibility is curating the backlog.
| There are no priorities, just position in the backlog. The PM
| should know what's in there, that's their job - they don't write
| code.
|
| Engineers just grab stories off the top of the backlog.
| code-faster wrote:
| The central point that work trackers track work is true important
| and jira astronauts need to be stopped, but the piece misses the
| bureaucratic purpose of jira: work legibility.
|
| Work tracking isn't just about figuring out what work needs to
| get done, it's about helping management get a picture for the
| state of work.
|
| Developers and other line workers don't care about obsolete vs
| won't do. But management does. They want to know if they're being
| requested for work that will be rendered useless in a few weeks.
| They want to know if too much work isn't getting done because
| work is floating up to the CEO and it's not worth his time.
|
| There's a terrible principal agent problem here where management,
| the principal, decides how to track work, and can put the heavy
| lifting of filling in values onto the developers. This happens
| when management's more worried about losing their job than
| improving their team's output.
| karatestomp wrote:
| > There's a terrible principal agent problem here where
| management, the principal, decides how to track work, and can
| put the heavy lifting of filling in values onto the developers.
| This happens when management's more worried about losing their
| job than improving their team's output.
|
| I no longer believe a single tool is good for both a team
| tracking & communicating amongst themselves about the work
| they're doing, and communicating the same to and among
| management. Trying to make them both the same thing is a great
| way to come up with something that's terrible for one or the
| other of those uses (usually the former).
| Almad wrote:
| I do completely agree. In fact, when people asked me for JIRA,
| I've always said I am happy to do it since it's a software
| designed for me, the CTO.
|
| Yet I refuse to do it to them, the ICs.
| twic wrote:
| There may be a similar legibility point about severity levels.
| Some boss somewhere has to put the set of tasks in priority
| order for the development team, and once it's in that order,
| severity levels are useless for the developers. But they might
| be useful as a way for the person submitting the issue to
| communicate something to the boss who does the ordering.
|
| Say there's a billing system. One of the accounts receivable
| clerks notices that due dates aren't properly adjusted for
| public holidays. As a developer, do you know how big a deal
| that is? Probably not. Doesn't sound like a big deal. But maybe
| it means we're imposing penalty charges on customers where we
| shouldn't be, and that's a huge legal and reputational risk. Or
| maybe it really isn't a big deal! The boss will need to have a
| conversation with the clerk to learn all this, but maybe having
| a severity field is an ice-breaker for that conversation.
| ydlr wrote:
| Why not have the clerk assign the severity? Why can't the
| programmer and clerk discuss the problem themselves if there
| is uncertainty?
|
| The only problems in your scenario arise from the
| introduction of a boss as go-between.
| twic wrote:
| I am proposing that the clerk should assign the severity.
|
| You could have the programmers do the prioritisation, if
| they had the business understanding to do that. In that
| case, they're also the boss. The severity assigned by the
| clerk could still be a useful starting point.
| drewcoo wrote:
| But if they're not called bugs, there is no blame game. And extra
| pressure can't be put on developers to . . . to shape up! Sense
| of urgency and all that.
| zakallen wrote:
| I feel the same way about Asana and Jira. They're so customizable
| and cater to too many people that it requires management to be
| someone's full time job. And I haven't found someone who is
| passionately in support of such as service as you might find with
| say Notion.
|
| I've been working on a project that is attacking this problem but
| from the TODO comments angle. https://cosmolabs.io
| karatestomp wrote:
| Working in Jira and (especially) Asana always feels like
| working on a VNC share of the person in charge's cluttered
| desktop-covered-in-folders organizational system. Everything's
| hard to find and I'm afraid to touch anything for fear I'll
| accidentally drag something somewhere then not be able to find
| it again to put it back.
|
| Except it's that plus 1.5GB of memory use and a few tens of a %
| of a processor core.
|
| [EDIT] and I've found that to be true when working for people
| so good at using the software that they made popular training
| videos for it, not just morons who don't know how they work.
| rightbyte wrote:
| Sometime I wish that my project was managed in a folder with
| neatly arranged subfolders all in ASCII text. Specs in the
| specs-folder. Release lists in the release list folder.
|
| Bugs in the bugs folder, with a text file for "reported",
| "active" and "fixed" bugs sorted by release version folders.
|
| I honestly would want to try it. Files and folders are the
| abstraction that was supposed to replace physical folders
| with files, but in practice files stored in
| computers/network/mail are just a bunch of papers randomly
| put everywhere. How about using folders as they were supposed
| to ...
| nicbou wrote:
| It's my full time job, and I agree. However keeping Jira in
| line with reality helps me catch inconsistencies in
| requirements and plans.
| hinkley wrote:
| > When people scream "this is a bug", it is irrelevant what it is
| caused by.
|
| When people say things like this I often wonder if they worked
| with a more consistent caliber of people than I have.
|
| There are most definitely bugs, and figuring out that most of
| them come from a couple of people is critically important to
| saving the project in the long run.
|
| Knowing that you have 5 bugs and I have 7 is, I will agree, not
| important. But knowing that Steve has 50? Is really fucking
| important.
| rconti wrote:
| Would people otherwise be aware that Steve has an order of
| magnitude more bugs than anyone else?
| seph-reed wrote:
| Something this article completely overlooks is coder mental
| health. Working on bugs constantly is the equivalent of being a
| code janitor. Getting to own/run a new feature from time to time
| can re-invigorate your interest.
|
| The suggestion I put out at an old company (which was shot down)
| was the idea of owning features. If all the bugs for features you
| own are resolved, pull a new feature. You now own the bugs for
| it.
|
| It gets difficult when a feature is too big for one person, or
| too important for that developers bugs to be a blocker.
| juangacovas wrote:
| So there are no debuggers, just untodoers...
| scottporad wrote:
| This idea is very clever:
|
| "then 'upkeep' and 'new' should be the ticket types"
| bogdanoff_2 wrote:
| These can lead to discussions similar to "it's a feature, not a
| bug."
|
| Is "Make app work on device X" or "Add cornercase Y" new or
| upkeep?
| ken wrote:
| > When people scream "this is a bug", it is irrelevant what it is
| caused by. It is a scream of a significant expectation mismatch.
| The team should work on resolving it, regardless of whether it
| was caused by a developer diverging from the designed intent or
| because of the original intent going wrong.
|
| As a user, it's extremely relevant to me. I paid for your
| product/service because of what it claimed to do. Bugs are ways
| in which it doesn't do that. (It doesn't matter to me if some
| other hypothetical features don't exist yet, because I was happy
| to pay for the product/service knowing it didn't have those
| features.) As far as I'm concerned, a bug is your company not
| holding up your end of the bargain, even though I've held up my
| end by paying for it. That's not a good look.
|
| Another way to look at it is that a bug is downtime for a
| feature. Elsewhere, you say (system) downtime should be #1, "top
| priority of everyone" until it's fixed. But what good is the
| system being 'up' if it's still broken in the way that I need?
| When I lose power at home, it's no consolation to hear "The power
| grid as a whole is still up -- it's just your neighborhood that's
| not working", nor would I consider this reasonable justification
| for de-prioritizing fixing it.
|
| Maybe your company is at the stage where attracting new users
| with features is more important than keeping existing customers
| with quality. But they say it's always easier to keep customers
| than it is to acquire new ones, and I've blackballed several
| companies because they no longer place the priority on quality
| that they once did. You should be aware of what you're giving up
| by de-prioritizing 'bugs', or pretending they don't exist. I see
| comments here on HN every day complaining about specific
| companies whose software quality suffers. It takes years to dig
| yourself out of that hole.
| patrickyeon wrote:
| That's what the author is saying though. The classification of
| "bug vs. feature" is irrelevant to the user, and trying to
| convince someone to call it something other than a bug to make
| the developer feel better is missing the point. What matters is
| something isn't working for the user, and should be made to
| work.
| david_draco wrote:
| > One way to recover is to automatically close tickets after a
| certain period of time. This may be a subtle way of saying "no",
| but I think it has its place, especially if we are talking about
| public trackers.
|
| Ugh, RedHat bugzilla trauma is coming back to me. Report issue ->
| 12 months nothing -> bug closed because new RedHat linux version
| was released. Repeat.
| z3t4 wrote:
| Dont use todos or tickets or issue trackers! It takes too little
| effort to write a todo/ticket item. Your engineers will spend
| time doing work that are unnecesary and they will spend hundreds
| of hours implementing shitty ideas that only took 10s to come up
| with. Instead write down a project plan, write down the vision of
| the product. Write down what your goals are, and what you stand
| for.
| taftster wrote:
| Um yeah. I mean, I appreciate your ideals. But back down here
| in the real world, part of that "project plan" is the part
| about taking a bite off the elephant. You've got to start
| somewhere. Defining and tracking the progress you've made
| eating the elephant allows you to know when you've fully
| consumed it.
|
| And remember, most (all?) software projects are not defined in
| a singularity. They evolve. As users use the product, the
| understanding of what you built changes. There is no ability to
| define a project of any significant size in a box the first
| time. We aren't pulling rabbits from a hat.
| randomdata wrote:
| > Defining and tracking the progress you've made eating the
| elephant allows you to know when you've fully consumed it.
|
| You can also simply keep track by keeping tabs on the work
| you are doing, which also leads to a better product as you're
| familiar with what the product does rather than simply
| knowing that X, Y, and Z issues are closed.
|
| Non-technical stakeholders will not be able to follow it that
| way, having their focus on other important parts of the
| business, but that's why you have project managers who can
| follow what the technical side is doing and provide the
| necessary non-technical communication to them.
|
| Ultimately, you're both right. There is just some conflation
| going on. What is useful for some segments of an organization
| does not make it useful for everyone.
| [deleted]
| 5cott0 wrote:
| There Are No Margins, Just TODOs
| BaitBlock wrote:
| Web readermmode:
| https://baitblock.app/read/https://almad.blog/essays/no-bugs...
| arunc wrote:
| The website theme is nostalgic. Does anyone know of jekyll theme
| that generates such simple website?
| lostinroutine wrote:
| There is no CSS on the page. I have a feeling your comment was
| facetious though, hinting at the amount of bloat (e.g. Jekyll
| theme) we need today to do the simplest things.
| Scottopherson wrote:
| It's your browser's default styling. Only CSS I see is:
| article {hyphens: auto;}
| barbegal wrote:
| > There is one good argument in its favor [closing tickets that
| are too old]: the software continuously changes and hence old
| issues may be invalid. In order to put them into a sprint, they
| need to be checked--in some cases, that's actually more work than
| the issue itself.
|
| I agree this is sometimes true, those difficult to reproduce
| tickets often mysteriously disappear when you make other changes.
| But there are lots of times when a lot of work has gone into
| creating the ticket so there is actually not much left to do to
| fix the issue. In this case closing tickets that get too old
| would be very counter-productive.
| jayd16 wrote:
| If an issue is getting added to or starred or commented on then
| its not old.
| agloeregrets wrote:
| For a pretty crazy take on this, take. A look at BaseCamp's
| "Shape Up" philosophy, They do not have a backlog. Period. To
| them, they work a little slower and expect to give enough time
| to a task to ensure zero bugs instead but then have cycles of
| bug-fix focus. Additionally, something I found interesting is
| that every dev is expected to understand the complete stack,
| that way any dev can fix any corner. Sure this might not work
| in a larger company without strong levels of splitting up the
| product, but It's an enjoyable thing to look at.
| kazinator wrote:
| A bug should identify where it was introduced. If a bug was
| introduced in version 0.5, then version 0.5 forever has that
| bug, and so the issues is forever valid in that sense, as a
| truthful comment about a historic thing. If the current version
| is 1.2, and it has not been confirmed to have fixed the bug,
| the view should be taken that the bug still exists in 1.2. Bugs
| don't just become invalid; if we are justified in calling a bug
| invalid now, that can only be because it was never valid in the
| first place.
|
| Suppose that someone tries to check, but the bug doesn't
| reproduce in 1.2. However, it was never root-caused. All we
| have is a description of the behavior that was happening in
| 0.5.
|
| Now what? Do you just close that bug to get the open bug count
| down?
|
| Probably an "unsolved mysteries" or "cold cases" category would
| be more appropriate for it rather than lumping it with
| genuinely closed bugs: those that were traced to a root-cause
| and confirmed.
|
| In cases when you're sure that the bug was due to some software
| that was entirely rewritten such that the same bug cannot
| plausibly be in the rewritten version, or some software that
| was removed entirely, then there is justification in closing
| that.
| wintorez wrote:
| The small amount of padding in that page was a bit disturbing.
| groby_b wrote:
| With the small caveat that this is scale dependent. I can assure
| you that there absolutely are projects that require components.
| (If you prefer a different model, you can assign a different bug
| tracker for each component - but that makes collective metrics
| harder)
|
| I agree that ultimately (and quickly) the bug needs to land with
| a single person, but the component matters in the routing step
| before that. Because you'll have frontline triage who can only
| vaguely figure out where the bug goes, second-line triage might
| get the team right, and then the team needs to decide where it
| goes.
|
| Yes, that's a lot of overhead. Unless you have 1000+ people
| working on your software, you won't need it. Up to ~100 people,
| you can probably assign fairly directly, depending on the range
| of problems the code base spans.
|
| Similarly, there are reasons why you don't want to do task
| breakdowns for everything in the bug tracker. Global refactorings
| are a good candidate to skip that, because you _will_ do that
| across teams, piece by piece, and tracking them in a bug tracker
| is not necessary. We got spreadsheets for that ;)
|
| Same goes for priority - sometimes you _do_ need it. That zero-
| day you 're fixing is a "drop everything else" bug. And really,
| the "flow" is just nine different priorities. (God, let me never
| work on something that has nine different priorities ;)
|
| So, "season to taste". But there are definitely lots of good
| ideas in there. If there was just ONE I could enforce across all
| projects I ever work on, it'd be "Close the damn bugs if you're
| not going to work on it" - issue hygiene is incredibly important.
| IshKebab wrote:
| > One way to recover is to automatically close tickets after a
| certain period of time.
|
| Just be thoughtful about how you do this otherwise it can easily
| come across like "we don't really care about your issue".
|
| Google has had two rounds of auto-closing old Android bugs and
| their message is really bad. Something like "Our product team is
| prioritising other things.".
|
| Similarly Github's stale bot is way over used. One project I
| submitted a bug to closed it because there was no activity for
| only a month.
|
| If you must close old bugs automatically, word it nicely, and
| don't close it instantly and ask people to reopen it. Something
| like this is best:
|
| > We're trying to clean up our bug tracker. This bug is older
| than 5 years and has had no activity for 2 years. Is this still
| an issue?
|
| Compare with Google's message:
|
| > Thank you for your feedback. We have tried our best to address
| the issue reported [they hadn't], however our product team has
| shifted work priority which doesn't include this issue [what does
| that even mean?]. For now, we will be closing the issue as "Won't
| Fix (Obsolete)" [great, thanks]. If this issue still currently
| exists, we request that you log a new issue along with the latest
| bug report here: https://goo.gl/TbMiIO and reference this bug for
| context.
| junon wrote:
| Agreed. Github's Stale Bot is the most infuriating, aggravating
| and insulting bot in widespread use. Every time I encounter it,
| I reevaluate whether or not I even want to contribute to the
| project.
| neonate wrote:
| There are no TODOs, just bugs.
| taftster wrote:
| You've made the same point as the author. The idea that a
| "ticket" or "work-item" has any sort of label (defect, feature,
| todo) or priority (high, low, now) doesn't add value. The label
| you give a work-item is meaningless. The value comes strictly
| from the change being applied.
| [deleted]
| lifeisstillgood wrote:
| >>> Every team must have a single ordered queue of tasks.
|
| No. Every _organisation_. All the politics, all the empire
| building and compromises just to get along are brought into the
| fore and must be solved to decide if projectX is above or below
| projectY.
|
| Do that, and we might just believe you are a company worth
| working for.
| ahungry wrote:
| Interesting read - to a person working tickets, I think it can be
| true that there is no useful difference between viewing a task as
| a bug vs a feature - in either case, its "what needs to change"
| and performing work to do the change.
|
| However, the big difference to people not handling the ticket
| (the customer/business + the person(s) who have to deal with bug
| accountability) - a bug usually represents a failed promise and
| is quite different from a feature.
|
| If I go to a restaurant and there is a "bug" in my order, I
| expect it fixed for free, so that in the end I'm getting my
| original order (with the extra work/time requirement eaten by the
| side which erred to begin).
|
| If I want to change my order because I don't like the food after
| all, then that's not a bug, that's a change in
| requirement/feature request.
|
| Having bucketed priorities (highest/high/medium/low/lowest) is a
| big failure of Jira / ticketing systems though. They should be a
| unique set of priorities, with only one single ticket occupying
| #1 priority, another slightly less one in slot #2 etc.
| taftster wrote:
| I don't know that I've ever seen a feature that wasn't some
| sort of "failed promise". The feature sometimes hits and
| sometimes misses, and is usually somewhere in between. This
| idea that a defect is a failure of a feature is probably more
| to do with the inability to predict the future. Sure there are
| defects like you tried to read from /dev/null, but more
| realistically the "defects" you see today are more about the
| inability to predict exactly how a feature is going to be used.
| bberenberg wrote:
| > Having bucketed priorities (highest/high/medium/low/lowest)
| is a big failure of Jira / ticketing systems though. They
| should be a unique set of priorities, with only one single
| ticket occupying #1 priority, another slightly less one in slot
| #2 etc.
|
| Jira supports both. The thing you're describing is called Rank
| and is used on every board and backlog. Our team uses Rank
| almost exclusively. The bigger thing to understand here is that
| different people use different "labeling systems". If you
| ignore software dev and think about note taking, there are a
| bunch of different systems. Some work better for one group of
| people, others work better for another group. I think Jira has
| had a lot of success because it doesn't force people into one
| system. The downside is that people often configure it to use 3
| different systems at the same time and they vary team to team
| and this causes a lot of strife and confusion.
| fredfjohnsen wrote:
| This is the most logical, sensible comment in the thread.
| Jira is the most flexible system for workflow management in
| existence. The fact that it is extensible is "a feature, not
| a bug."
|
| I don't see really see anyone stating obvious truths about
| bad developers & software engineers (as shocking as it may be
| to read on HN that there are, in fact, objectively bad
| developers & software engineers with high-paying jobs at
| companies whose names you know.)
|
| - they are more interested in making a new thing instead of
| fixing a broken thing they released
|
| - they often can't remember how they built the last new thing
|
| - that's because they aren't interested in building &
| documenting a fully working thing with test code from the
| start
|
| - they aren't interested in data structures or architecture
| built to be easily maintained or in making scale part of
| their designs
|
| - they despise being told to fix bugs because it is much
| easier to write code than it is to read it
|
| I believe some organizations implement Jira thinking it is
| going to solve their cultural problems. This is magical
| thinking.
|
| I am so tired of hearing about how terrible Jira is from
| developers.
|
| It's usually the case that where Jira isn't working it has to
| do with the way it's configured (e.g., giving too many people
| access to set priority, setting too many priorities, setting
| too many components, using components in illogical ways, no
| one actively managing & grooming queues...)
|
| To implement Jira successfully probably requires more work &
| effort to get it right than to not use it at all. The point
| of it is not to eliminate the work of issue tracking. It is
| to organize the workflow management of moving incredibly
| complex information from one person to the next. It's pretty
| great at this if you know how to use it.
| adrianmsmith wrote:
| > They should be a unique set of priorities, with only one
| single ticket occupying #1 priority, another slightly less one
| in slot #2 etc.
|
| I've heard the ability to drag & drop tasks around in an
| ordered list (i.e. a task only has priority relative to others,
| i.e. it's position in the list) as "ordinal priority".
| lifeisstillgood wrote:
| I love the restaurant analogy - it has great resonance
| especially if you consider cost of making it right.
|
| If I order a Lasagne and get spaghetti meatballs, i think
| that's a big and i expect to be fixed.
|
| If I order Lasagne and get Beef Lasagne when Inamna vegetarian
| then I still think it's a big, but the failure is not
| immediately in the kitchen - why did the waiter not check, if I
| am wearing dungarees and a a Tee Shirt saying "Die all meat
| eaters" should that be a clue?
|
| And what about the kitchen response - we all like the
| restaurant that apologises and comps the food for free. But we
| would be a bit surprised if we were told the Beef Lasagane was
| not going to be refunded and we had to pay again to get the
| veggie one.
|
| But all those models exist in software.
| gregmac wrote:
| As a developer, I generally find having a distinction between
| bugs and features useful.
|
| If I'm going to do a big refactoring of some component, I find
| it useful to look for related open bugs (even if they're low
| severity) because sometimes it's low or zero extra effort to
| fix them at the same time. This only works if you have good
| quality tickets though (proper tags, alias words, etc), which
| is a whole different topic.
|
| I think it also reduces cognitive load while looking at tickets
| to have them categorized that way too. Of nothing else being
| visually distinct (via icon or something) just makes it easier
| to process.
|
| Above all though, it's important not to argue about bug vs
| feature. Ideally any bug can link to the feature ticket that
| isn't working, but either way it's more important to make
| things better for the customer, so if that means considering a
| what is _really_ a feature request a "bug" because it'll cause
| a big argument otherwise, then do that.
| protonimitate wrote:
| Yup - from a implementation perspective, bug vs feature is a
| artificial designation.
|
| Where I think it _does_ matter, is when a business wants to
| track metrics like "# of bugs over time" or "# of bugs per
| feature".
|
| My team recently got a lot of heat about "a rising number of
| bugs", and the insinuation was that our code quality was poor.
| Turns out, > 75% of the "bugs" reported were mis-labeled
| feature requests or lack of knowledge about how a particular
| feature was designed to work.
| chias wrote:
| One way the distinction gets used where I work is to have
| custom / required fields keyed on the ticket type.
|
| Oh, you want to make a bug ticket in my project? In that
| case, required fields include "steps to reproduce", "expected
| result", and "actual result". You want to make a feature
| ticket in my project? In that case, required fields include
| "rationale" and "acceptance criteria".
| gregmac wrote:
| Whoever is giving your team heat about bug metrics needs to
| read about Goodhart's Law.
|
| There's so many ways to influence number of bugs that it's
| pointless to measure anything that way. For example, do you
| make a single bug that lists 15 typos spread around, or 15
| bugs (because after all, each typo is a different word and in
| a different part of the app). Do you accept vague but
| obviously real bugs while you try to collect enough info over
| time, or immediately close them as "cannot reproduce"? Is
| that a bug, or really a feature request?
| bpyne wrote:
| I like the analogy. I'm trying to get people in my organization
| to understand that it's not a bug when a feature works as
| specified in the app requirements. Either the requirement
| wasn't specified well or a change of circumstances requires it
| to work differently. In either case, it's a request for
| modification not a bug. Your analogy should help me explain the
| difference.
| tuwtuwtuwtuw wrote:
| > I'm trying to get people in my organization to understand
| that it's not a bug when a feature works as specified in the
| app requirements
|
| Oh no.... You are wasting yours and theirs time. This is such
| a developer thing to do.
| bpyne wrote:
| Please see my comment to allanniehuis.
| coelh0 wrote:
| Don't confuse the waiter with the customer.
|
| If the waiter gets the request wrong from the customer, it's
| still a bug. Even if the kitchen does exactly what was in the
| waiter request.
|
| It's a team effort.
| bpyne wrote:
| Please see my comment to allannienhuis.
| allannienhuis wrote:
| The user doesn't care whether the bug is in the requirements
| or if it's in the code. They just know that it's not working
| for them, and want it changed.
|
| Arguing that it's not a bug seems like saying 'not my
| problem' to everyone else. I expect different companies have
| different cultures around assigning blame that might make
| saying 'not my fault' important, but I'm pretty sure that
| customers/users don't care one bit about that.
| jiveturkey wrote:
| there's a -- critical -- feedback loop problem that you're
| ignoring. sure, you might work on it with the same priority
| regardless of characterization. but if it's properly
| classified as an error in specification, that is
| _extremely_ valuable information for process improvement.
| bpyne wrote:
| Whether it's a bug or a modification to requirements I'm
| still the one who works on it. So "not my problem" doesn't
| exist in my situation. The distinction matters very much
| when it comes to prioritizing my work. I'm 100% time on
| projects and jump from one to the next with no pause
| between. I'm also the only developer who supports the apps
| I built. Bugs usually jump to the top of the queue.
| Management puts a lower priority on requests. In order to
| not hurt my current "customer", I need to make sure past
| ones don't try gaming the system by declaring bugs when
| they're not.
| ahungry wrote:
| Right, to the customer it doesn't matter (just like to the
| developer it doesn't need to matter either - it just means
| the work needs to be performed).
|
| However, it matters greatly to other observers - if one
| person or team is highly out of the norm for rate of bugs,
| it might be indicative of other problems that need to be
| worked on (lack of testing, peer review, tasks being
| assigned beyond the working abilities etc.).
|
| Just like the restaurant analogy - the expectation is that
| bugs shouldn't be happening to begin with, and when they
| do, it should be "our fault" to remedy them.
| Almad wrote:
| I do agree completely on "failed promise" and this is actually
| why I think the bug vs feature is flawed. I think "failed
| promise" is a great ticket type though ;)
|
| There are obvious cases where I have nothing against what you
| say. But to use the analogies, "I thought the food would take
| differently and I don't like this one" is the more common type
| and it's the one that's murky to resolve.
|
| The point here is that regardless of the reason, you want to
| tend to "customer is not happy" case.
| m463 wrote:
| But you have to acknowledge some features are bugs.
|
| For example, if you have a word processor, having a running
| word count sounds like a feature.
|
| To a developer it seems frivolous, like having a LOC counter.
|
| But to people who write professionally word count might be the
| most critical metric of all (like a progress bar for "article
| is done")
|
| just saying... failed promises
| mrtweetyhack wrote:
| There is no code, only characters
| evantahler wrote:
| There's a great tool - pivotal tracker - that acts in the way
| that the author describes. It's great because it's opinionated.
|
| It also includes pretty good PM tools like burn down charts,
| predicted velocity, etc.
| cdcarter wrote:
| I'm going to add to the pile-on that the "Ticket Type" field is a
| little more useful than the author gives it credit.
|
| > why do you want to have this information and what is it going
| to be used for?
|
| You might say this is yet another proxy for priority, but it's
| slightly more nuanced than that. A lot of software companies do
| not have the experience of continuously deploying the main code
| branch. I work on a SaaS solution that's gained traction in
| highly regulated industries.
|
| It's very useful to be able to identify (trends in!) bugs that
| could be described as a "regression" or breakage in behaviors
| that customers are known to rely on. This isn't the example of
| "Customers" from your post though, ultimately how the change gets
| prioritized and released is what they care about! This is about
| being able to identify and systemically manage change in high
| risk areas.
| taftster wrote:
| Most if not all software is shipped with known defects. So
| clearly, the fact that a "bug" can be identified doesn't give
| any weight when describing when it needs to be fixed.
|
| A missing feature can be just as onerous to a user as a defect.
| Understanding if an issue gets in the way of productivity is
| all that matters, regardless if it's described as a bug or a
| feature.
|
| Tracking metrics against bug vs. feature is a surefire way for
| a system to be gamed. If there are consequences in
| finding/reporting defects, then all work-items will eventually
| be labeled as "features". Or if you reward finding bugs, then
| all work-items will gravitate towards "defects". It's up to you
| how you want to play this game.
| hackbinary wrote:
| Almost certainly what you can fix and release in an hour has
| higher priority than something that is going to take a month, for
| example.
|
| I have had quite a bit of success in having the technical teams
| assess the length of time a fix or a feature takes to do, but
| letting the stakeholders determine the relative priority.
|
| I have seen requests and suggestions go from completely critical
| when requested, but when estimated at a couple of work then
| broken down into multiple much easier and clearer tasks when the
| stakeholders are included in the prioritisation discussion.
|
| My experience is that stakeholders much prefer having things
| turned around quickly and they will what they can to optimise for
| things that are quickly and easily deliverable.
| marcus_holmes wrote:
| Upvoted for calling out "management by Jira". I hate that.
| arnklint wrote:
| On point in so many ways... There is simply no way of
| decentralize prioritization. Thanks Almad, for sharing valuable
| insight/realization with the rest of us.
| Almad wrote:
| Happy to, glad you like it
___________________________________________________________________
(page generated 2020-06-05 23:00 UTC)