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.
There Are No Bugs, Just TODOs
131–140 of 204 posts
Re: There Are No Bugs, Just TODOs
#132Earlier quoted context omitted.
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.
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 a…
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.
Re: There Are No Bugs, Just TODOs
#133Earlier quoted context omitted.
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.
> I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.
Please see my comment to allanniehuis.
Re: There Are No Bugs, Just TODOs
#134Earlier quoted context omitted.
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.
Don't confuse the waiter with the customer. If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request. It's a team effort.
Please see my comment to allannienhuis.
Re: There Are No Bugs, Just TODOs
#135The website theme is nostalgic. Does anyone know of jekyll theme that generates such simple website?
It's your browser's default styling. Only CSS I see is:
article {hyphens: auto;}Re: There Are No Bugs, Just TODOs
#136> 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 w…
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.
Re: There Are No Bugs, Just TODOs
#137Dont 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.
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 produ…
> 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.
Re: There Are No Bugs, Just TODOs
#138Earlier quoted context omitted.
The panic shifting thing is real, and for me way too many companies operate in permanent panic. I'm fine with responding to actual crises. But so much "urgent" work is really just managerial failure. Fake deadlines used to "motivate" people. Broken processes that people work around. Executives urgently need to look like they're doing something. Easily solvable problems festering until they become crises. Managers rus…
> people with power either don't care or have interests that actually work against getting things done quickly and reliably. This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus. I've also seen it arise a…
Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them.
I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning.
Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation
Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan.
As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.
Re: There Are No Bugs, Just TODOs
#139Earlier quoted context omitted.
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.
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 a…
there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.
Re: There Are No Bugs, Just TODOs
#140Earlier quoted context omitted.
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 produ…
> 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 f…
[deleted]