There Are No Bugs, Just TODOs - <AUTHOR> https://almad.blog/essays/no-bugs-just-todos/ <comment><USER2> 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.

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

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

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

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

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

</comment></comment></comment></comment></comment></comment><comment><USER7> 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.

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

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

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

<comment><USER10> It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.

</comment></comment></comment></comment></comment><comment><USER11> > 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](https://goo.gl/TbMiIO) > and reference this bug for context.

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

</comment></comment><comment> code-faster 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.

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

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

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

</comment></comment></comment></comment><comment><USER15> 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.

<comment><USER16> 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".

</comment></comment><comment><USER17> 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.

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

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

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

</comment></comment></comment></comment><comment><USER18> It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include:

* who reported the issue * what they reported happening * what they expected to happen instead

For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.

But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made.

Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work.

I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate.

<comment><AUTHOR> Thanks, this made me think. My first knee-jerk reaction was something about things and implicitness, but after some consideration:

* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)

* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does

</comment></comment><comment><USER19> 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.

</comment><comment><USER20> > 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/](https://www.databasesandlife.com/priorities/)

<comment><USER21> "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.

<comment><USER20> 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?

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

</comment></comment></comment></comment><comment><USER22> Super interesting, I like how the minimal skeleton for product development has been broken down.

Overall, I'm mostly aligned but it seems to me that it's very focused on low level product delivery. I feel like it's ignoring the bigger picture of how these "tasks" come to life and where they go after they're shipped.

Shipping software is much broader than moving tasks from "to do" to "deployed". If that was it, then yes, all you need is a flat & ordered list of tasks with an assignee for each. But it's not:

-How do you decide what do build in the first place? How do you make sure you are working on what's most meaningful?

-When you've prioritized the right problems to solve, how do you collaborate to come up with the right UX?

-How do you perform user research and user testing to validate your assumptions?

-How do you handle the feedback inbound you receive from stakeholders and customers? How do you take these inputs into account in your prioritization process? How do you then complete the feedback loop?

-How do you work with customer success and marketing to ensure everyone is informed of what you've shipped?

-How do you balance demonstrating product velocity while working on meaningful projects that take several weeks or months to ship?

What I'm saying is there is a broader context to shipping software beyond "accessing a prioritized list of tasks and getting them done". It's good to climb fast but if you're climbing the wrong wall, you're just getting to the wrong place faster.

That's the reason why my co-founder and I built Cycle ([https://cycle.app/](https://cycle.app/)) – an all-in-one tool that helps engineers, designers, and product people to better collaborate in the process of shipping good stuff.

</comment><comment><USER23> 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.

</comment><comment><USER24> 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...

<comment><AUTHOR> The main problem I had with them is inability to sort them in a list, which is somewhat solvable with GH Projects now.

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

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

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

<comment><USER27> It's more than that though. Once the list is sorted, the next time you come back to it, the list is still more or less in the right priority. So the work for prioritization becomes easier.

<comment><USER25> Once you close an issue the code is in a new state and the list deserves revaluation, returning you right back to square one.

<comment><USER26> That doesn't seem the case in projects I worked with. In my case, there were more features than engineers and some features were more important than others, so the list made sense. Obviously, it's not set in stone. Features can sometimes jump queue, be completely dropped, or more important features can show up. But I don't think I was ever in a position when a broad list of tasks for the quarter didn't make sense.

<comment><USER25> Features are emergent out of solving the business needs. If you see a business opportunity in toasting bread, it wouldn't make sense to have an outstanding issue that says "Affix fireplace to the bottom of the apparatus". Instead, knowing your business goal, you start to think about how bread should be toasted and when you come to the revelation that an electric coil is the most efficient method to solve your problem, you finish adding it to the product and then revisit what your next business need is in the context of what now exists and what you have learned in the meantime.

Issues only come into play when your understanding is wrong, to serve as a reminder to revisit your assumptions. New features don't fit. If you are spending so much time finding features to develop faster than you can develop them, your human resource allocation is flawed.

<comment><USER26> It all depends on the business and business model. For instance, I worked in a classroom app. We had a few goals per quarter but let's just see a couple. For instance, one goal at a certain point was to create all these new lesson types. However, some were clearly more important than others (the ones which were used in almost every lesson was more important than one that's used in a couple. For bigger lesson types there may be more than one issue. For instance, being able to select a single option in a multiple choice lesson can be done before the feature to allow multiple selection and things like that.

Another goal that would frequently appear is paying tech debt. Some changes are also more important than other in that track.

All this work has business value and may be part of the BAU of a established business. I think you're describing a business in a very primordial state. Although, even in startups I've created having a list of things we wanted to do was helpful. We saw our competition we wanted to do better, but we also need to catch up. Lots of things are just obvious and not all the work one does is revolutionary. I don't disagree that changes do occur, though.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> 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.

</comment><comment><USER29> > 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.

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

<comment><AUTHOR> As mentioned, this is true for versioned software, not for continuously deployed SaaS.

</comment></comment></comment><comment><USER31> It sounds to me like you're describing Pivotal Tracker ([https://www.pivotaltracker.com/](https://www.pivotaltracker.com/)). It forces story ordering (rather than "prioritization"), it's pretty barebones, and it's fast.

<comment><USER16> Both Jira and Trello allow ordering, how does this differ?

</comment></comment><comment><USER32> For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.

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

<comment><USER33> A quick web search gives me taiga.io, taiga.pm.

What's the diff if any?

<comment><USER2> I did not know about taiga.pm. I use the hosted version at taiga.io.

But, since Taiga is FLOSS[1], anyone can host it and/or build a business around it, which -I suspect- is what taiga.pm does.

[1] [https://github.com/taigaio](https://github.com/taigaio)

</comment></comment></comment></comment><comment><USER34> 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!

<comment><AUTHOR> True. I think one of the issues is slapping an issue tracking system on a bunch of different problems.

</comment></comment><comment><USER35> 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.

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

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

</comment></comment></comment><comment><USER37> > 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.

<comment><AUTHOR> I do agree it can totally suck to be on the receiving side.

</comment></comment><comment><USER38> 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.

</comment><comment><USER39> > 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.

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

</comment></comment><comment><USER41> From my experience in 5 companies at various stages, engineering task management in whatever form is generally efficient until you hire your first program manager. This happened several times regardless of team size. The engineering manager/director/VP gets tired of his work and takes a break by hiring a Program manager. PM's sole job is to make sure the tasks management is shielded from the rest of the org but invariably, they overengineer the "process". I am yet to meet a PM who simplifies things or makes things more efficient.

<comment><USER41> Not to mention .. their job is the only one inside the engineering department that doesnt expect them to build/run/test the code hands-on.

</comment></comment><comment> seph-reed 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.

<comment><AUTHOR> I'd say quite the opposite. What you say is one of the myriad of considerations that _should_ go into prioritization by the team, yet is super hard to capture by any hard attribute as I believe the "positive/negative mental health effect" is way more complicated than "bug/feature", yet known by the team.

</comment></comment><comment><USER21> 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.

<comment><AUTHOR> 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)

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

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

<comment><USER21> > _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.

</comment></comment></comment></comment></comment><comment><USER42> 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.

<comment><AUTHOR> "Season to taste" I totally agree with, no way to capture the whole world in a signel post ;)

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

I do agree it's about routing. My problem with components is alignment with teams and their stability over time and survival of existing tickets across those changes, which is why I think different routing mechanisms are better. But yeah, if it works...

> Same goes for priority - sometimes you do need it. That zero-day you're > fixing is a "drop everything else" bug.

I call those "an incident" and in every environment I've been at, everybody knew which one it is very well without any labels ;)

<comment><USER42> If you can share more about different routing mechanisms, I'd _love_ to hear it. It's not that components are making me happy, per se ;)

As for the priority label - it makes sense if there's either a huge bug load (cf. bug hygiene ;) or in environments where you have automated workflows. I.e filing a bug with P0 alerts the responsible engineer, starts a log document for the inevitable post mortem, lets production know, whatever you need to do for P0s.

Not all fields in the database are for humans :)

I have occasionally thought it'd be nice if we ditched a lot of UI & status fields, and the IC view in the bug database is just "what is the most important thing for me to work on right now". One issue. Only comment history, no other fields. You still need the rest for reporting, analysis, workflows, but as IC, that's what you care about.

</comment></comment></comment><comment><USER43> 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/](https://semver.org/) ; it's important to know if a release is backwards-compatible or not

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

<comment><USER43> thanks for this nuances.

</comment></comment></comment><comment><USER44> 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.

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

</comment></comment><comment><USER16> 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?

<comment><AUTHOR> Hmm, I communicated wrongly then. Because the separate system for issues is _for a different team and a different purpose_ and no, it's definitely not a solution to the problem, but rather a prerequisite for the outlined system to have a chance at working at all.

<comment><USER16> You described it as a "separate system for handling questions for the development team".

How do you propose that queue is prioritised and consumed by the development team?

<comment><AUTHOR> In both companies I've been using that, it was a very simple RT/JIRA-SD-style system: "open a subject/text ticket, clock starts ticking, on call engineer gets a non-wake-up memo and will reply with high priority during work hours" and ticket will get closed ASAP and we do achieve inbox 0 regularly.

Yes, there are obvious issues and it requires two things to work:

1) If you actually have no clue about the product, you are respectfully told to fuck off to normal user support channel 2) If you keep misusing this for user support / slack channel, you get your access revoked.

...which are hard sells in large companies, of course—on the other hand, in BigCo I got success in getting an engineering headcount to accommodate that.

</comment></comment></comment></comment><comment><USER45> Web readermmode: [https://baitblock.app/read/https://almad.blog/essays/no- bugs...](https://baitblock.app/read/https://almad.blog/essays/no-bugs-just- todos/)

</comment><comment><USER36> 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.

</comment><comment><USER46> 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.

</comment><comment><USER47> > 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.

</comment><comment><USER48> 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](https://cosmolabs.io)

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

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

</comment></comment></comment><comment><USER51> > 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.

<comment><AUTHOR> I actually never new about bugs being assigned to people as opposed to products, interesting to know.

</comment></comment><comment><USER30> 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.

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

</comment></comment><comment><USER52> >>> 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.

</comment><comment><USER53> We used the Ticket Type field with a totally different workflow. There was always one developer on each sprint whose task was to only bug fixes, nothing else. That person got the "Bug" Type tickets. It was always a mistake in existing implementation.

</comment><comment><USER54> But if there is only TODOs and not bugs, how managers will prevent the creation of 'high severity bugs' when they're in panic mode? I wish I was joking but that's something to think about..

<comment><USER55> They create them and they go first in the queue. If there is more than one, they have to decide which is first.

If there are conflicts then it's up to the managers to fight it out.

<comment><USER54> That's not what I'm talking about: when a software is late there is a 'panic phase' by the managers where they forbid the creation of 'high severity' bug tickets. So if there is no more bug tickets what will happen when the managers are in 'panic mode'? Something to think about before removing bug tickets.

<comment><USER55> Okay, hmm. It seems like if you already have a lot of high-priority work then logically, most new bugs will go _after_ them in the queue.

And if you're running out of time, that would amount to the same thing, since you'll never get to it.

Also, so long as you have enough work queued up for a few weeks, there is not really much point to stack-ranking the remaining queue items anyway. Everything else is "lower priority".

</comment></comment></comment></comment><comment><USER56> 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.

<comment><AUTHOR> Happy to, glad you like it

</comment></comment><comment><USER57> _There are no "bugs". There are "defects"._ \-- HP, back when they were good.

</comment><comment><USER58> The website theme is nostalgic. Does anyone know of jekyll theme that generates such simple website?

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

</comment></comment><comment><USER60> There Are No Margins, Just TODOs

<comment><AUTHOR> As the frontpage says, intentionally deferred :P

</comment></comment><comment><USER61> Upvoted for calling out "management by Jira". I hate that.

</comment><comment><USER62> The small amount of padding in that page was a bit disturbing.

<comment><AUTHOR> One of the reasons I am delaying design is getting deeper into accessibility and readability research. And I have decided to write some content first ;)

</comment></comment><comment><USER63> This idea is very clever:

"then 'upkeep' and 'new' should be the ticket types"

<comment><USER64> 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?

</comment></comment><comment><USER65> So there are no debuggers, just untodoers...

</comment><comment><USER66> 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.

</comment><comment><USER67> There are no TODOs, just bugs.

<comment><AUTHOR> Note: Author is Eastern Europian, so #totes

</comment></comment><comment><USER68> There are no TODOs, just bugs.

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

<comment><USER68> You caught me because I didn't read the article. I was just thinking of the old duality between bugs and features. An unimplemented feature is just the bug "the software doesn't have this feature yet", and a bug fix is implementing the feature that "the software should do this correct thing instead of that buggy thing". Since this insight is decades old, maybe I should switch to saying the article contains nothing new?

</comment></comment></comment><comment><USER13> > 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.

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

Agreed. My point was more about that there has to be a single person responsible for making sure there are no leftovers.

> But the development team itself can do that, no problem.

Yup. To the domain point, I do think that collaboration on that boundary is needed.

> It's relevant to estimating velocity (...)

Fair, if you only define velocity as adding features and if you automatically prioritize bugs.

> We must recognise this as simply being an expression of the author's > deletionist aesthetic preference, not a fact about the world.

I think this doesn't hold over long term. It is true as long as you do have an idea what's in the rest of the pile. But the moment you change the person responsible for managing the tickets and suddenly they have thousand tickets to go through and orient themselves in, it matters. And if they don't go through all of them, they don't actually do the prioritization against each other.

</comment></comment><comment><USER69> It's cool! I agree ;)

<comment><USER69> Hey,me too!

</comment></comment><comment><USER70> There is a huge difference between a TODO and a FIXME.

A FIXME cannot be in master, but TODO's all the time.</comment>


Awesome mechanical engineering resources - <AUTHOR> https://github.com/m2n037/awesome-mecheng/blob/master/README.md <comment><AUTHOR> Please feel free to contribute to this list. As this list is still in a nascent stage, I will appreciate if you can advice here in HN about what to add.</comment>


Rocket Deck got 200% funded on Kickstarter - <AUTHOR> https://www.kickstarter.com/projects/rajarjit/the-rocket-deck?ref=ccc4f1 <comment><AUTHOR> Happy to take any questions and feedback. This is my third attempt. The previous two attempts failed miserably. AMA.</comment>


Collaborative Evolution: The Mona Lisa in Canvas - <AUTHOR> http://peterbraden.couchone.com/lisa/_design/lisa/index.html

<comment><USER2> I really like this because I can see the evolution taking place, including all the strange mutations. Reading synopses of genetic algorithms is often somewhat boring: "after 2000 generations, I had a fitness ranking of 54, but after another 3000 generations it had settled around 56!" The frustration boils down to the fact that they lack a story of how the algorithm arrived at its answer. It just has an answer, and it happens to work, and it's inscrutable. It's cool, because it works, but its opacity makes it a poor spectator sport.

Here, I get to see an entire story. I see innovation, progress, bold new ideas be attempted and fail. Of course, the story is all in my head, but I feel like I can see how it works, and what it's trying to do. My browser can't handle enough generations, but maybe after watching it more I could see what it's good at and what it struggles. Never underestimate the power of visualizations.

(aside: link got borked?)

</comment><comment><USER3> Surely there's a more interesting way to do this than random variations and picking the best. Why not constrain the color of the circle to the one that maximizes your objective function given its position? That isn't hard to compute.

<comment><USER4> "Surely there's a more interesting way to do this than random variations and picking the best".

The whole point behind genetic algorithms is precisely, randomness (mutations) and picking the best (fitness). Constraining the mutations would maximize the chances of finding a local optimum.

</comment></comment><comment><AUTHOR> oops, couchone has gone down. The source is on github at <https://github.com/peterbraden/genetic-lisa>

<comment><AUTHOR> and back up. I have no idea how much load I'm sending them, but apologies in advance!</comment></comment>


Sign of the times? - <AUTHOR>

I have been following posts on Hacker News, albeit, not religiously. I wish I had time to neatly categorize posts based on the content in the post but in general, a few themes standout: (1) sagely start-up wisdom (2) another day, another web application (3) another day, another debate about the best MVC framework for the web app (4) VC gossip (5) gossip around Apple, Google and Facebook (6) Another post about how language X sucks, a contrarian spinning his/her wheels on why language Y rocks. That pretty much sums up hacker news. The Signal/Crap ratio is scary if you rip apart fluff masquerading as technology.
Don't get me wrong, I have nothing against the site. What bothers me is this penchant to appropriate the "start-up" cool as opposed to focusing on the idea, product, or service that is being innovated -- as if a start-up is the end-all-be-all in life. Is start-up association the technology community parallel to celebrities who are famous for being famous? That brings us to another abused word namely, "innovation." Since when did 100 lines of web application code become innovation? Where is the innovation that focuses on the hard problems? I am not sure if there can be a scale for innovation but a 100 line web 2.0 application is no match for the integrated circuit. I am sorry, I cannot put these two in the same league. As a developer myself, I can tell you, code is just code. Pasting code on blogs and sites is just show-off; much like the friendly sales guy in a suit who is flashing the latest smartphone at the airport to appropriate the phone's coolness.
What seems to be also missing is the appreciation for incremental and painstaking detail oriented innovation. There is joy in watching sustained growth in small increments. The satisfaction comes not from the magnitude of change but in nourishing the small yet subtle and perceivable increments that are part of the larger vision of a hard problem. <comment><USER2> If you want to change this then you and anyone who agrees should do the following:

        1. find and submit interesting stories to HN

        2. visit /newest often and upvote stories that aren't fluff

If you and all the other people who love HN do this, it will substantially improve the community.

</comment><comment><USER3> > Since when did 100 lines of web application code become innovation?

When it makes executing and polishing the products easier.

> I am not sure if there can be a scale for innovation but a 100 line web 2.0 > application is no match for the integrated circuit.

So, |EE| > |CS|?

100 lines of well written code in a functional programming language can do marvelously things. Just look at: <http://norvig.com/spell-correct.html> and then tell me how connecting AND and OR gates compare intellectually?

> Where is the innovation that focuses on the hard problems?

<http://news.ycombinator.com/item?id=1585850>

> code is just code

Or education material so those that come after us skip 10% of our problems.

> Pasting code on blogs and sites is just show-off

Or marketing

> What seems to be also missing is the appreciation for incremental and > painstaking detail oriented innovation.

In aggregate, you get to see the results of people's pain staking details in whatever form they market it as. A post may represent a good night of hacking or a year of research to produce one moment of clarity.

</comment><comment><USER4> I've recently been thinking about Steve Blank's characterization of start-up companies as essentially "searching" for a business model to "execute".

I think the reason so many noteworthy things not directly related to entrepreneurship pop up on yc news is that this "search" process uncovers unexpected things along the way. It's a kind of nexus for new thoughts and unusual twists.

Many of us engage in the entrepreneurial search process and at the same time co-opt it for other purposes. There is a lot of value in the overlap.

</comment><comment><USER5> _As a developer myself, I can tell you, code is just code. Pasting code on blogs and sites is just show-off; much like the friendly sales guy in a suit who is flashing the latest smartphone at the airport to appropriate the phone's coolness._

As a developer how can you say this? Code isn't just code, its good code or bad code. I cant count how how many good coding solutions to problems I've found on blogs, and how much time it has saved me.

</comment><comment><USER6> Reminds me of this great article by Tim O'Reilly: [http://radar.oreilly.com/2009/01/work-on-stuff-that- matters-...](http://radar.oreilly.com/2009/01/work-on-stuff-that-matters- fir.html)

</comment><comment><USER7> I think you neglected an important category:

(6) Building Things (physical things)

For me, the two biggest responses when posting stories to HN were both woodworking related projects w/instructions.

<http://news.ycombinator.com/item?id=1906181> <http://news.ycombinator.com/item?id=1027994></comment>


Show HN: Alphacortex (for AWS) – a consolidated reference to all things AWS - <AUTHOR> http://aws.alphacortex.io/ <comment><AUTHOR> hey hn. This is Kevin, the founder of Alphacortex. Alphacortex is a service to help organize and find information in specific domains. Alphacortex for AWS is our first public index built on the platform.

Currently Alphacortex for Aws supports access to AWS CLI, Cloudformation, IAM, Terraform, and Developer docs with more sources being added on a weekly basis. If you are interested, please take a look at our roadmap, make suggestions and +1 your favorite features: [https://github.com/kevinslin/alphacortex- roadmap/projects/1](https://github.com/kevinslin/alphacortex- roadmap/projects/1)</comment>


Path of Exile's patch post mortem - <AUTHOR> https://www.pathofexile.com/forum/view-thread/659606 <comment><USER2> It's worth noting that Path of Exile is a free-to-play game that had an un- scheduled 45-minute outage, and the resulting post-mortem is written with more detail and attention than I've seen in cases involving pre-negotiated service- level agreements.

Beaujolais to Grinding Gear Games!</comment>


Something odd is happening at haskell.org (Edit: Domain registration lapse) - <AUTHOR> http://haskell.org/

<comment><USER2> They let the domain expire? Typical laziness.

<comment><USER3> Can they do that? I would think you'd have to use the NetSol monad and force evaluation.

</comment></comment><comment><USER4> Next time you think something is odd please explain what that is. Please.

</comment><comment><USER5> See also on Haskell Reddit --- [http://www.reddit.com/r/haskell/comments/encrv/whats_happene...](http://www.reddit.com/r/haskell/comments/encrv/whats_happened_to_haskellorg_did_someone_forget/)

</comment><comment><USER6> I have to admit that I'm a little puzzled whenever this happens on a well- known site. Do not all registrars allow you to set up auto-renew on your domains? I have to explicitly choose _not_ to renew a domain.

<comment><USER5> The latest I've heard is that it wasn't due to expire for another year, but Network Solutions decided it was expiring anyway.

[http://article.gmane.org/gmane.comp.lang.haskell.general/184...](http://article.gmane.org/gmane.comp.lang.haskell.general/18401)

</comment></comment><comment><USER7> It seems that they let the domain expire. This should get you by: <http://hpaste.org/42369/haskellorg_ips>

<comment><USER8> #fail

</comment></comment><comment><USER9> I'm confused - this simply appears to be the usual Haskell landing page. What is it that's happening that you're claiming to be "odd" ?

<comment><USER5> The domain was expiring and got redirected to a Network Solutions domain parking page. It looks like it's been renewed, but the correct dns settings don't seem to have propagated everywhere yet.</comment></comment>


A complete rewrite of R-Type for the Amstrad CPC6128. - <AUTHOR> http://www.rtype.fr/

<comment><USER2> There's something almost pathological about the un-nostalgia behind these projects, but in such a wonderful, persistent, perfecting way. Forgive me for self-linking, but the one I would like to see on the CPC is a less-terrible interpretation of Black Tiger: [http://boingboing.net/2011/10/20/8-bit- remakes-fix-the-past....](http://boingboing.net/2011/10/20/8-bit-remakes-fix- the-past.html)

<comment><USER3> I think you have pretty much made nostalgia for that era an art form, so you'd be doing everyone a favour by linking to some more of your posts, e.g.:

Classic Arcade Game Deaths <http://boingboing.net/2011/03/25/classic-arcade- game-1.html>

Tinyhack <http://boingboing.net/rob/tinyhack/>

</comment></comment><comment><USER4> I swear I dreamt about R-Type last night... it was similar to the Amiga version but much improved. When I saw this in HN I was blown away by the coincidence!

</comment><comment><USER5> Amstrad CPC6128 was my first computer.. put it to good use for several years, both gaming and my first steps in programming (BASIC FTW!). Ah, the memories..

<comment><USER6> I had a CPC464. I put an incredible amount of time into coding on that computer.</comment></comment>


Samsung teases CES unveiling of HDTV with 'unprecedented new shape' - <AUTHOR> http://appleinsider.com/articles/12/12/31/samsung-teases-ces-unveiling-of-hdtv-with-unprecedented-new-shape

<comment><USER2> Maybe the bottom half of the screen is reserved for a menu/dashboard. At my house, we have two TV's that have computers attached, and it would be nice to browse media files while still watching full screen without resorting to plugging in a separate VGA monitor (which I haven't done yet).</comment>


Bruce Sterling requests assistance proving the validity of his marriage - <AUTHOR> http://blog.wired.com/sterling/2009/04/bruce-sterling.html

<comment><USER2> Jasmina Tešanović is no goddman mail-order bride. On her own, without a USian hubby, Tešanović is exactly the sort of person any healthy democratic society needs and we should welcome her with open arms. Of course, I wouldn't put it past Uncle Sam for targeting her because of her activism. Warlords have their kids and trophy wives here, naturalized and all.

</comment><comment><USER3> The INS is despicable. I hope I never have to deal with them again.

<comment><USER4> Immigration & Customs in almost all countries tend to be despicable in general. It's harder to get accountability from them, since the people they lord over tend to have no voting powers.

<comment><USER5> But they are also a very easy target. Immigration services do a job that is never going to be popular, but in the end their actions and decisions are mandated by a political leadership.

It's too easy to single out these agencies in a hatefest.

<comment><USER6> How cares if they are an easy target? They are still the ones who are enforcing an unjust law against you.

<comment><USER7> It's unfair because they are only enforcing the law as written, and it's written by representatives of the people of that country(1), and thus they are only doing the will of the people. If you don't like it, be angry at the people responsible for the law, not the agency.

It's like hating the policeman because they keep busting you for drugs. It's not his fault they're illegal. In fact, many policemen feel the drug laws are stupid. It's equally likely that many in the INS feel the law is unjust. What are they going to do, though? Break it?

Responsibility flows upwards in such matters, especially where governmental mandate is concerned. Blaming officers of the government for merely enforcing the will of the people is misguided.

(1) Doesn't count for non-democracies, obviously, but even in those cases they'd just be enforcing the law of the land, with little individual perogative.

</comment></comment></comment></comment></comment><comment><USER8> Doesn't the US government have more important matters to deal with? The US is one of those most xenophobic first world Western nations I know of.

<comment><USER9> Exactly what I was thinking! Why in the world are they spending tax payers money on 2 seemingly do-good-ers when there's a plethora of really important stuff out there to fix ?

BTW, I'm not in the US, am in the UK at the moment, and even here, the same bloody nonsense happens. Government spend scarce resource on really minor matters

</comment></comment><comment><USER10> Log into your Flickr account or your "My Pictures" and produce printed copies of the hundreds of digital photos you took together. That is a solid place to start.

</comment><comment><USER11> I think that they should each use their private SSL keys to double-sign a document stating that they're married.

<comment><USER12> Wrong Bruce.</comment></comment>


Ask HN: Multi-head disc drive - cool-RR

Hello everyone,
Does anyone know why we use disc drives that have only one reading/writing head?
This applies to any optical disc, regardless if it's CD or DVD or Blu-Ray or whatever. Why don't they put two or three heads in each drive, so we could burn a DVD in 2 minutes? Also, I find it annoying that it takes like 10 seconds from the time you put a disc in the drive to when the computer reads it.
Maybe something like this exists and I just never heard of it? Does anyone have an idea? <comment><AUTHOR> This has been attempted; my understanding is that IBM had a hard drive where each platter had independently controlled heads about 20 years ago.

It turned out to not work very well. Disk heads have to seek very accurately, and stay unmoving very accurately once they fine the right location; having other disk heads moving around made this incredibly difficult.

</comment><comment><USER2> There have been multi-headed drives is the past when seek times were in the hundreds of miliseconds. It's not done now because it greatly increases cost and the complexity of the software, and doesn't work very well. A dual-headed drive would probably cost more than two single headed drives.</comment>


Ask YC: Good mySQL tutorial on linking tables - <AUTHOR>

I'm trying to develop a scalable table structure for my current project and I think the best way to do things will involve linking tables. I'm looking for some good tutorials on how table linking works as well as what are the best ways to create scalable database structures.
Does anyone have any good links on these subjects?
Any help is appreciated as I'm a total newbie on this subject. <comment><USER2> Not quite sure this is what you are looking for, but maybe:

<http://philip.greenspun.com/sql/>

<comment><USER3> great resource. thanks!

</comment></comment><comment><USER4> Hi, <http://www.percona.com/presentations.html>

There you have around 20 presentations on pdf related to MySQL, indexing, improving performance, query optimization, techniques for scaling, etc.

Have fun with those!</comment>


Iranian news agency says its website has GONE DOWN 'due to US sanctions' - <AUTHOR> https://www.rt.com/news/479137-iran-sanctions-fars-news/ <comment><AUTHOR> It seems they have removed the DNS entry for www.farsnews.com therefore, www.farsnews.ir is still accessible.</comment>


Ask YC about timing: When to monetize your user generated content site? - <AUTHOR>

Here's a hypothetical question... let's say you have a UGC site and so far everything on the site has been free but someone needs to start paying bills so you've been looking at various options. You can add advertising (like what many sites do these days), you can start charging for 'premium' features (the so-called freemium business model), or you can start requesting donations (wikipedia model).
Each of these different montization methods has its own pros and cons and each of them has a potential to piss of users and alienate them.
So the question that I have is: what is the best time to implement one of these features? Do you start charging/advertising from the beginning or do you wait for the community to grow on the completely free model? <comment><USER2> I think that in 99.5% of cases you should start trying to monetize from the very beginning, for three primary reasons:

1\. You're more likely to piss of customers if you introduce advertisements/donation requests/subscriptions later than if it is there at the beginning. People like to know what they can expect from a site when they first start using it, and they tend to get very comfortable with a given dynamic. I've been very surprised how offended/alienated people can become if you introduce monetization later...people don't seem to understand about hosting costs or time investments.

2\. You get the chance to see what is actually going to work for you before you go through too many iterations of your idea. Maybe your initial focus is not able to sustain itself...being able to adjust on the fly and experiment is a key component of internet sites and your monetization strategy is definitely something you can/should experiment with.

3\. People with something invested in your site beyond their content contributions (such as donations/subscriptions) are more likely to give you honest feedback about your site. You also tend to get more partner inquiries if there is a visible monetization method (versus 'labors of love'.)

<comment><USER3> 4\. If you put ads from the start, you get to design the Web site with the ads in mind rather than adding them later in whatever space that happened to be left empty.

<comment><AUTHOR> That's an excellent point. My follow-up question is: how easy/hard is it to find advertisers for brand new sites? I know that AdSense wants you to have 100K uniques (or something like that)...

<comment><USER4> Adsense and adbrite have no minimum traffic requirements and cost nothing to get started in. You just won't get a payment until you've accumulated $100, which may take a while.

<comment><USER5> Adbrite has a minimum payment of $5, I got a payment of $5.36 from them recently.

</comment></comment></comment></comment></comment><comment><USER6> Do what WordPress.com does - only show ads to people who come in from search engines AND don't have a "I've been to WordPress.com before" cookie. That way your regular users will never see an ad, but the people most likely to click on ads (external visitors in "search mode") will. Make sure your regulars know that this is going on though, or they may feel you are being dishonest with them.

</comment><comment><USER7> At a recent barcamp some bloggers mentioned something interesting: they treat their visitors differently with regard to ads: the feed subscribers only see ads on an article after a few weeks, whereas people hitting the blog through search engines see ads from the start. Not sure what the right mixture would be, but it's something worth to think about, I guess.

<comment><AUTHOR> That's very interesting! I find it interesting that you'd wanna show an ad to a person coming from Google. Would you lose a possible registration/lead if that person thought that there's too many ads on the site? What if you turn this upside down and show ads to people who are already 'hooked' to your product?

Definitely an interesting insight!

</comment></comment><comment><USER8> I faced a similar question myself and decided to try adsense and adpinions, I put up a little line saying basically if this pisses you off let us know. No one really has, but I'm sure some find it bothersome. I am thinking about doing the wordpress thing and not showing ads to logged in users. If you use hard stats(pagviews,uniques, etc) to get advertisers you may not want to use this method.

I think I am going to switch to a donation based way becuase people either really see the value in my site or they don't and just leave anyway.

Great Question, I am interested in seeing what other say as well.

</comment><comment><USER9> You could also think of other ways to monetize your site/idea. Can you sell an enterprise version to businesses? (i.e. Google Enterprise Search) Do you have valuable information that hedge funds or someone else might want to buy? (some of the specialized social networks do this.) Or anything else you can think of... definitely more work than putting up ads, but it could be where the real money is.

<comment><AUTHOR> Brian, excellent point. The gold is always in the data that you collect so trying to sell/license the data is an option. The problem is that you need a long(er) runaway to execute that strategy. You need some investment (maybe even a large one) to sustain you while you're in the red.

</comment></comment><comment><USER10> You ought to test all methods and go with what works. One of the beautiful things about the Web is that it allows us to do that easily.

</comment><comment><USER11> I was hoping to see much more discussion on this thred, but seems the thread died about a year ago. W.r.t. donations, do you think that could be a monetization biz model? Though, if I like a site, sometimes I buy their premium service, not exactly because I need it, just to support them. Do you think a site can be sustained on donation money like that?</comment>