5 ms·

Second advice. If you want to pretend that quality matters, move to aerospace, finance, or any critical systems. Third advice. It's not enough to fix bug, ever

Second advice. If you want to pretend that quality matters, move to aerospace, finance, or any critical systems. Third advice. It's not enough to fix bug, everyone MUST know that you fixed that weird bug that customers were complaining about for years and noone could understand the cause.

adrianN 9y ago
> If you want to pretend that quality matters, move to aerospace, finance, or any critical systems. The important word here is pretend. If the system is safety critical you'd think that quality matters. It doesn't. What matters is following the process laid out in ISO 26262 or whatever standard applies to your field. Whether or not that improves quality is not important (it does, but only a little). The important part is that you have reduced/no liability for accidents if you can prove that you did everything by the book.
- andai 9y ago
  andai.depression++;
- daemin 9y ago
  Yep, part of the quality standard for medical devices is to have processes, and also processes to improve and change the processes. So theoretically there shouldn't be any doubt as what to do in a given circumstance when something fails, and that standards would rise as development matures. But in reality it's just a bunch of paperwork, and as far as the software is concerned, standard practices of unit and integration testing, code reviews, and strict compiler settings are more than adequate already. Edit: It's all about documenting that those things have been done and signed off on, so keeping track of paperwork.
  - user5994461 9y ago
    Testing, review, history of changes... many things that are completely unheard of in the average small development shop.
- tzahola 9y ago
  Exactly. A prime example of this is the “quality” software at financial companies.
  - user5994461 9y ago
    They care about loosing money and risking to lose money.
- cr0sh 9y ago
  I'm on the last few pages of this book: https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_People_Think%3F https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_Pe... ...where he talks about his role and questions regarding the Challenger shuttle disaster; I don't know if things have changed much since then at NASA, but I suspect they haven't, given Columbia and such.
- wott 9y ago
  Mmmyes, but the process implies a heavy chain of verifications. So even when there has been an idiot and a lazy guy, at some later stage in the process, it has to go through someone who cares at some point and it gets fixed at that point. After all, that is the point of those heavy processes: manage to product something fairly reliable despite the acknowledged presence of morons and shitty managers. The process does not try to eradicate those people, it works around them with some kind of redundancy. Having been one of those 'concerned' people, I must admit it is exhausting. You know that if some work comes from this guy, or that company, it will be 90% shit and you have to explain them again and again what is wrong and how to fix it, or do it yourself when you are really fed up. So basically you do your job + the slackers' job. That is how the system works. As a system, the result is not too bad. As far as individuals are concerned, however...
metaobject 9y ago
And make sure to record it so that at the end of your yearly review cycle, and before the raises are decided, you can remind your upper management of your notable accomplishments.
- 77pt77 9y ago
  Either it's easily perceived as bringing value or it won't have any effect. If you have to remind people of it, it's as good as not existing in the first place.
  - taejo 9y ago
    I disagree. A year is a long time, and a valuable, difficult achievement in February may raise your prestige for a while, but by December that's faded to background levels. I even forget my own achievements from nine months ago, never mind those of a dozen other people on my team.
    - 77pt77 9y ago
      The question is always: > What can you do for me or have done for me recently? Services provided so far in the past that need to be reminded are at best irrelevant and it can actually hurt you to bring them up. I'm not saying that it is nice, only that humans behave individually and (even more collectively) according to this.
      - taejo 9y ago
        So at my annual review in December I should only be assessed on work in the last quarter? I guess I'd better save my best work for November.
        webmaven 9y ago
        Depending on the attention span of your particular managers (and their managers as well, most likely), this can indeed be a viable strategy. You might also carefully consider your company's culture when deciding how to split your efforts between new (user-visible) features, preventive maintenance, and bugs affecting end users (especially any VIP end users that have your managers' ears). For example, a 'Hero' culture rewards last-minute, late night, death march efforts, whether to fix an urgent problem, or to add that one feature that is (supposedly) needed to land a specific high-value customer/sale.

adrianN 9y ago

> If you want to pretend that quality matters, move to aerospace, finance, or any critical systems. The important word here is pretend. If the system is safety critical you'd think that quality matters. It doesn't. What matters is following the process laid out in ISO 26262 or whatever standard applies to your field. Whether or not that improves quality is not important (it does, but only a little). The important part is that you have reduced/no liability for accidents if you can prove that you did everything by the book.

andai 9y ago
andai.depression++;
daemin 9y ago
Yep, part of the quality standard for medical devices is to have processes, and also processes to improve and change the processes. So theoretically there shouldn't be any doubt as what to do in a given circumstance when something fails, and that standards would rise as development matures. But in reality it's just a bunch of paperwork, and as far as the software is concerned, standard practices of unit and integration testing, code reviews, and strict compiler settings are more than adequate already. Edit: It's all about documenting that those things have been done and signed off on, so keeping track of paperwork.
- user5994461 9y ago
  Testing, review, history of changes... many things that are completely unheard of in the average small development shop.
tzahola 9y ago
Exactly. A prime example of this is the “quality” software at financial companies.
- user5994461 9y ago
  They care about loosing money and risking to lose money.
cr0sh 9y ago
I'm on the last few pages of this book: https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_People_Think%3F https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_Pe... ...where he talks about his role and questions regarding the Challenger shuttle disaster; I don't know if things have changed much since then at NASA, but I suspect they haven't, given Columbia and such.
wott 9y ago
Mmmyes, but the process implies a heavy chain of verifications. So even when there has been an idiot and a lazy guy, at some later stage in the process, it has to go through someone who cares at some point and it gets fixed at that point. After all, that is the point of those heavy processes: manage to product something fairly reliable despite the acknowledged presence of morons and shitty managers. The process does not try to eradicate those people, it works around them with some kind of redundancy. Having been one of those 'concerned' people, I must admit it is exhausting. You know that if some work comes from this guy, or that company, it will be 90% shit and you have to explain them again and again what is wrong and how to fix it, or do it yourself when you are really fed up. So basically you do your job + the slackers' job. That is how the system works. As a system, the result is not too bad. As far as individuals are concerned, however...

metaobject 9y ago

And make sure to record it so that at the end of your yearly review cycle, and before the raises are decided, you can remind your upper management of your notable accomplishments.

77pt77 9y ago
Either it's easily perceived as bringing value or it won't have any effect. If you have to remind people of it, it's as good as not existing in the first place.
- taejo 9y ago
  I disagree. A year is a long time, and a valuable, difficult achievement in February may raise your prestige for a while, but by December that's faded to background levels. I even forget my own achievements from nine months ago, never mind those of a dozen other people on my team.
  - 77pt77 9y ago
    The question is always: > What can you do for me or have done for me recently? Services provided so far in the past that need to be reminded are at best irrelevant and it can actually hurt you to bring them up. I'm not saying that it is nice, only that humans behave individually and (even more collectively) according to this.
    - taejo 9y ago
      So at my annual review in December I should only be assessed on work in the last quarter? I guess I'd better save my best work for November.
      - webmaven 9y ago
        Depending on the attention span of your particular managers (and their managers as well, most likely), this can indeed be a viable strategy. You might also carefully consider your company's culture when deciding how to split your efforts between new (user-visible) features, preventive maintenance, and bugs affecting end users (especially any VIP end users that have your managers' ears). For example, a 'Hero' culture rewards last-minute, late night, death march efforts, whether to fix an urgent problem, or to add that one feature that is (supposedly) needed to land a specific high-value customer/sale.