Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

Post reply on HN
Print view View original

111–120 of 356 posts

Re: We stopped roadmap work for a week and fixed bugs

#111

Post by k4rli »

pjmlp wrote: post #84
troad wrote: post #80

It's fairly telling of the state of the software industry that the exotic craft of 'fixing bugs' is apparently worth a LinkedIn-style self-promotional blog post. I don't mean to be too harsh on the author. They mean well. But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien…

That is why I stand on the side of better law for company responsibilities. We as industry have taught people that broken products is acceptable. In any other industry, unless people are from the start getting something they know is broken or low quality, flea market, 1 euro shop, or similar, they will return the product, ask for the money back, sue the company whatever.

Imagining that the software will be shipped with hardware, that has no internet access and therefore cumbersome firmware upgrades, might be helpful. Avoiding shipping critical bugs is actually critical so bricking the hardware is undesirable.

Example: (aftermarket) car headunit.

Re: We stopped roadmap work for a week and fixed bugs

#112

Post by zelphirkalt »

pjmlp wrote: post #84
troad wrote: post #80

It's fairly telling of the state of the software industry that the exotic craft of 'fixing bugs' is apparently worth a LinkedIn-style self-promotional blog post. I don't mean to be too harsh on the author. They mean well. But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien…

That is why I stand on the side of better law for company responsibilities. We as industry have taught people that broken products is acceptable. In any other industry, unless people are from the start getting something they know is broken or low quality, flea market, 1 euro shop, or similar, they will return the product, ask for the money back, sue the company whatever.

There should be better regulation of course, but I want to point out, that the comparison with other industries doesn't quite work, because these days software is often given away at no financial cost. Often it costs ones data. But once that data is released into their data flows, you can never unrelease it. It has already been processed in LLM training or used somehow to target you with ads or whatever other purpose. So people can't do what they usually would do, when the product is broken.

Re: We stopped roadmap work for a week and fixed bugs

#113

Post by silvestrov »

arkh wrote: post #107
kykat wrote: post #21

Earlier quoted context omitted.

Sometimes, a "bug" can be caused by nasty architecture with intertwined hacks. Particularly on games, where you can easily have event A that triggers B unless C is in X state... What I want to say is that I've seen what happens in a team with a history of quick fixes and inadequate architecture design to support the complex features. In that case, a proper bugfix could create significant rework and QA.

> Sometimes, a "bug" can be caused by nasty architecture with intertwined hacks The joys of enterprise software. When searching for the cause of a bug let you discover multiple "forgotten" servers, ETL jobs, crons all interacting together. And no one knows why they do what they do how they do. Because they've gone away many years ago.

plus report servers and others that run on obsolete versions of Windows/unix/IBM OS plus obsolete software versions.

and you just look at this and thinks: one day, all of this is going to crash and it will never, ever boot again.

Re: We stopped roadmap work for a week and fixed bugs

#114

Post by tonyedgecombe »

Uehreka wrote: post #54
ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. In my experience there are two types of low-priority bugs (high-priority bugs just have to be fixed immediately no matter how easy or hard they are). 1. The kind where I facepalm and go “yup, I know exactly what that is”, though sometimes it’s too low of a priority to do it right now, and it ends up sitting on th…

>high-priority bugs just have to be fixed immediately no matter how easy or hard they are

The fact that something is high priority doesn't make it less work.

Re: We stopped roadmap work for a week and fixed bugs

#115

Post by zelphirkalt »

BurningFrog wrote: post #36
Celeo wrote: post #19

Earlier quoted context omitted.

Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.

That's what I hear. I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for. I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)

micro-managing middle manager: "Are all your other sprint tasks finished?"

code reviewing coworker: "This shouldn't be done on this branch!" (OK, at least this is easy to fix by doing it on a separate branch.)

Re: We stopped roadmap work for a week and fixed bugs

#116

Post by joker99 »

jll29 wrote: post #104

From the report, it sounds like a good thing, for the product and the team morale. Strangely the math looks such that they could hire nearly 1 FTE engineer that works full time only on "little issues" (40 weeks, given that people have vacations and public holidays and sick time that's a full year's work at 100%), and then the small issues could be addressed immediately, modulo the good vibes created by dedicating the…

The unkind world we live in would see this role being abused quickly and a person not lasting long in this role. For one, in the wrong team, it might lead to devs just doing 80% of the work and leaving the rest to the janitor. And the janitor might get fed up with having to fix the buggy code of their colleagues.

I wonder if the janitor role could be rotated weekly or so? Then everyone could also reap the benefits of this role too, I can imagine this being a good thing for anyone in terms of motivation. Fixing stuff triggers a different positive response than building stuff

Re: We stopped roadmap work for a week and fixed bugs

#117

Post by tonyedgecombe »

RHSeeger wrote: post #57
BurningFrog wrote: post #14

This is weird to me... The way I learned the trade, and usually worked, is that bug fixing always comes first! You don't work on new features until the old ones work as they should. This worked well for the teams I was on. Having a (AFAYK) bug free code base is incredibly useful!!

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

>For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

I've seen that very argument several times, it was even in the requirements on one occasion. In each instance it was incorrect, there were times when a second page was reached.

Re: We stopped roadmap work for a week and fixed bugs

#118

Post by pmontra »

About stopping and fixing problems, did anybody have had this kind of experience?

1. Working on Feature A, stopped by management or by the customer because we need Feature B as soon as possible.

2. Working on Feature B, stopped because there is Emergency C in production due to something that you warned the customer about months ago but there was no time to stop, analyze and fix.

3. Deployed a workaround and created issue D to fix it properly.

4. Postponed issue D because the workaround is deemed to be enough, resumed Feature B.

5. Stopped Feature B again because either Emergency E or new higher priority Feature F. At this point you can't remember what that original Feature A was about and you get a feeling that you're about to forget Feature B too.

6. Working on whatever the new thing is, you are interrupted by Emergency G that happened because that workaround at step 3 was only a workaround, as you correctly assessed, but again, no time to implement the proper fix D so you hack a new workaround.

Maybe add another couple of iterations but at this time every party are angry or at least unhappy of each other party.

You have a feeling that the work of the last two or three months on every single feature has been wasted because you could not deliver any one of them. That means that the customer wasted the money they paid you. Their problem, but it can't be good for their business so your problem too.

The current state of the production system is "buggy and full of workarounds" and it's going to get worse. So you think that the customer would have been wiser to pause and fix all the nastier bugs before starting Feature A. We could have had a system running smoothly, no emergencies, and everybody happier. But no, so one starts thinking that maybe the best course of action is changing company or customer.

Re: We stopped roadmap work for a week and fixed bugs

#119

Post by tonyedgecombe »

waste_monk wrote: post #45
thundergolfer wrote: post #40

Earlier quoted context omitted.

This is the 'Zero Defects'[1] mode of development. A Microsoft department adopted it in 1989 after their product quality dropped. (Balmer is cc'd on the memo.) 1. https://sriramk.com/memos/zerodef.pdf

As opposed to the current 100% defects approach they seem to have adopted.

Balmer is no longer there :)

Re: We stopped roadmap work for a week and fixed bugs

#120

Post by arethuza »

triyambakam wrote: post #58
ChrisMarshallNY wrote: post #30

Earlier quoted context omitted.

Yeah, I’m obviously a terrible programmer. Ya got me.

I just find it so oversimplified that I can't believe you're sincere. Like you have entirely no internal heuristic for even a coarse estimation of a few minutes, hours, or days? I would say you're not being very introspective or are just exaggerating.

It rather depends on the environment in which you are working - if estimates are well estimates then there is probably little harm in guessing how long something might take to fix. However, some places treat "estimates" as binding commitments and then it could be risky to make any kind of guess because someone will hold you to it.
Post reply on HN