4 ms·

I wrote this essay. I linked the Reddit thread because there are some good thoughts there, but I'd also love to hear what HN has to say! https://www.reddit.co

by sandal 11y ago

I wrote this essay. I linked the Reddit thread because there are some good thoughts there, but I'd also love to hear what HN has to say! https://www.reddit.com/r/programming/comments/3z1pfp/the_sad_graph_of_software_death/ https://www.reddit.com/r/programming/comments/3z1pfp/the_sad...

dang 11y ago
It looks good, but we changed the URL from https://www.reddit.com/r/programming/comments/3z1pfp/the_sad_graph_of_software_death/ https://www.reddit.com/r/programming/comments/3z1pfp/the_sad.... HN prefers original sources.
pajtai 11y ago
Looking forward to the suggested answer. Guess I would delete all issues except for the most critical bugs and any remaining critical mvp features, and then I would say that from that point on you can't add any feature requests without completing something - that is you can only add a feature ticket after completing a bug or other feature ticket.... for sprints I'd say 3 to 1 bug to feature ratio and no more than 1 feature at a time in progress / in sprint at any time. Then if normalcy returns I'd ease up. I'd also make sure there's one lead dev in charge long term on the project instead of just having whoever has "some time to do it." Not sure if this is ideal, which is why I'm looking forward to your answer.
- sandal 11y ago
  This is pretty close to what I ended up doing. I've repeated this process elsewhere too, both for other companies and on my own projects... though the example shown was among the most severe. In the essay, I'll try to be a bit more precise though, because in practice you might have a hard time with getting buy in on "Delete the issues" and an easier time with what I actually did on this project: "create a priority queue that only the product owner and CEO can touch, treat that as the new official backlog until the crisis is resolved, put a bunch of rules on what gets in there and how much it can hold, then track progress actively" More details will be shared in a couple days, can't wait to hear responses. :-) If you want the followup essay in your inbox, sign up here: https://tinyletter.com/programming-beyond-practices https://tinyletter.com/programming-beyond-practices
  - Torn 11y ago
    Right - the important thing is recognizing that their development processes (or lack of them) has lead to this situation. Treating the symptoms is no guarantee they won't end up in the same situation in the future.
- mikekchar 11y ago
  I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current implementation. The difference is that in a feature, nobody expects the functionality to exist. In a bug, people expected the functionality to exist (either because it existed in a previous version, or because it was thought to have been implemented and it turns out that it wasn't). People react badly to bugs because they feel it is a result of a mistake -- developers broke something they shouldn't, or they didn't do a good job in a previous implementation. The feeling is that a bug has the highest priority, but in reality, there is no such connection from "previous mistake" to "important now". If the only difference between a bug and a feature is that a feature is not expected to already be present, as soon as you discover a bug it becomes a feature request -- we now know that functionality is not present. It should be prioritised in exactly the same way. The key to solving the problem posed by the article is fairly clear. Get a list of all the things the you are not going to implement. Remove them from the list. Done. Whether these are bugs or features is irrelevant.
  - joepvd 11y ago
    I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.
    - zer00eyz 11y ago
      This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.
  - sandal 11y ago
    Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.
x0x0 11y ago
Since you may find it amusing: I was in a similar situation at a previous company selling high end ($25k minimum price; $80k average price; labs typically bought 5 or more at a time) scientific devices. The dedicated salesperson / account manager was forcibly told to triage bugs / assign priorities. He spent an afternoon assigning every bug as critical/priority 0.
- laurencerowe 11y ago
  Everything is always critical to the person making the feature request. The trick is to ask them to order their tickets by asking which ones they need first.
  - x0x0 11y ago
    Oh trust me, we tried. Even when he would order them, he demanded them all to be done. It was fundamentally inconceivable to this person, and to the founder who was relatively unfamiliar with software, that software can take time. And what is hard often isn't obvious to someone who isn't an engineer. They did shit -- and the memories are coming back! -- like build multiple versions of the hardware that fixed different problems. Guess what they didn't do? Create any fucking way to query from the computer side what version of hardware you were talking to. Until rev 8 or 9. I spent probably a cumulative month figuring out (usually) non-destructive ways to guess from different faults which version of hardware a computer was talking to. And there was fun stuff like the servo motor with no hardware stop (used to move a lens closer/further from a laser) and different gearing ratios on different revs that could do $10-$20k of damage to lenses if you didn't know exactly what you were talking to. Because all you told the motor was degrees to rotate the shaft, but the aforementioned different gearing meant you could ram a lens into a laser because later revs traveled 3x as far per rotation. One thing that solved lots and lots of problems for us was I finally harangued the ceo into just shipping our own computers with the machines. We used nidaq cards to acquire data; nothing was as fun as attempting to remotely figure out driver conflicts/issues or NI licensing issues or what to do when someone didn't buy the right type of card. Often with a not particularly computer literate bio grad student on the other end. Just shipping our own computer with daq and software pre-installed and refusing to support anything but our own computers ($600 dells) got rid of a class of problems and replaced them with just one: the NIDaq card was jarred out of its slot during shipping. Reseat it. Or eventually, have the factory screw it in then glue it to the motherboard.

by sandal 11y ago

dang 11y ago

It looks good, but we changed the URL from https://www.reddit.com/r/programming/comments/3z1pfp/the_sad_graph_of_software_death/ https://www.reddit.com/r/programming/comments/3z1pfp/the_sad.... HN prefers original sources.

pajtai 11y ago

Looking forward to the suggested answer. Guess I would delete all issues except for the most critical bugs and any remaining critical mvp features, and then I would say that from that point on you can't add any feature requests without completing something - that is you can only add a feature ticket after completing a bug or other feature ticket.... for sprints I'd say 3 to 1 bug to feature ratio and no more than 1 feature at a time in progress / in sprint at any time. Then if normalcy returns I'd ease up. I'd also make sure there's one lead dev in charge long term on the project instead of just having whoever has "some time to do it." Not sure if this is ideal, which is why I'm looking forward to your answer.

sandal 11y ago
This is pretty close to what I ended up doing. I've repeated this process elsewhere too, both for other companies and on my own projects... though the example shown was among the most severe. In the essay, I'll try to be a bit more precise though, because in practice you might have a hard time with getting buy in on "Delete the issues" and an easier time with what I actually did on this project: "create a priority queue that only the product owner and CEO can touch, treat that as the new official backlog until the crisis is resolved, put a bunch of rules on what gets in there and how much it can hold, then track progress actively" More details will be shared in a couple days, can't wait to hear responses. :-) If you want the followup essay in your inbox, sign up here: https://tinyletter.com/programming-beyond-practices https://tinyletter.com/programming-beyond-practices
- Torn 11y ago
  Right - the important thing is recognizing that their development processes (or lack of them) has lead to this situation. Treating the symptoms is no guarantee they won't end up in the same situation in the future.
mikekchar 11y ago
I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current implementation. The difference is that in a feature, nobody expects the functionality to exist. In a bug, people expected the functionality to exist (either because it existed in a previous version, or because it was thought to have been implemented and it turns out that it wasn't). People react badly to bugs because they feel it is a result of a mistake -- developers broke something they shouldn't, or they didn't do a good job in a previous implementation. The feeling is that a bug has the highest priority, but in reality, there is no such connection from "previous mistake" to "important now". If the only difference between a bug and a feature is that a feature is not expected to already be present, as soon as you discover a bug it becomes a feature request -- we now know that functionality is not present. It should be prioritised in exactly the same way. The key to solving the problem posed by the article is fairly clear. Get a list of all the things the you are not going to implement. Remove them from the list. Done. Whether these are bugs or features is irrelevant.
- joepvd 11y ago
  I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.
  - zer00eyz 11y ago
    This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.
- sandal 11y ago
  Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.

x0x0 11y ago

Since you may find it amusing: I was in a similar situation at a previous company selling high end ($25k minimum price; $80k average price; labs typically bought 5 or more at a time) scientific devices. The dedicated salesperson / account manager was forcibly told to triage bugs / assign priorities. He spent an afternoon assigning every bug as critical/priority 0.

laurencerowe 11y ago
Everything is always critical to the person making the feature request. The trick is to ask them to order their tickets by asking which ones they need first.
- x0x0 11y ago
  Oh trust me, we tried. Even when he would order them, he demanded them all to be done. It was fundamentally inconceivable to this person, and to the founder who was relatively unfamiliar with software, that software can take time. And what is hard often isn't obvious to someone who isn't an engineer. They did shit -- and the memories are coming back! -- like build multiple versions of the hardware that fixed different problems. Guess what they didn't do? Create any fucking way to query from the computer side what version of hardware you were talking to. Until rev 8 or 9. I spent probably a cumulative month figuring out (usually) non-destructive ways to guess from different faults which version of hardware a computer was talking to. And there was fun stuff like the servo motor with no hardware stop (used to move a lens closer/further from a laser) and different gearing ratios on different revs that could do $10-$20k of damage to lenses if you didn't know exactly what you were talking to. Because all you told the motor was degrees to rotate the shaft, but the aforementioned different gearing meant you could ram a lens into a laser because later revs traveled 3x as far per rotation. One thing that solved lots and lots of problems for us was I finally harangued the ceo into just shipping our own computers with the machines. We used nidaq cards to acquire data; nothing was as fun as attempting to remotely figure out driver conflicts/issues or NI licensing issues or what to do when someone didn't buy the right type of card. Often with a not particularly computer literate bio grad student on the other end. Just shipping our own computer with daq and software pre-installed and refusing to support anything but our own computers ($600 dells) got rid of a class of problems and replaced them with just one: the NIDaq card was jarred out of its slot during shipping. Reseat it. Or eventually, have the factory screw it in then glue it to the motherboard.