

Software: Immaculate, fetid and grimy - WestCoastJustin
http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-fetid-and-grimy

======
douche
I think the last point is the best one, and something that I'll try to keep in
mind

>

    
    
        And what do you do when that awful, black day arrives? Here’s a quick coping manual from those of us who have been there:
    
        Don’t pretend it didn’t happen — you screwed up, but your mother still loves you
        Don’t minimize the problem, shrug it off or otherwise make light of it — this is serious business, and your colleagues take it seriously
        If someone spent time debugging your bug, thank them
        If someone was inconvenienced by your bug, apologize to them
        Take responsibility for your bug — don’t bother to blame other subsystems, the inherent complexity of the software, your code reviewers, your testers, the community, etc.
        If it was caught before it was running in production, be thankful that a production user wasn’t affected by it

~~~
Plishar
Really? This is all second nature, stuff you should already be doing. Replace
"bug" with defect and it can apply to anything.

If you find computer work is stressing you out, maybe find a better job that
suits your interests?

------
greenleafjacob
> You may discover as you work in the subsystem that maintaining it is simply
> untenable — and it may be time to consider rewriting the subsystem from
> scratch. (After all, most of the subsystems that are in the first category
> replaced subsystems that were in the second.) One should not come to this
> decision too quickly — rewriting a subsystem from scratch is enormously
> difficult and time-consuming. Still, don’t rule it out _a priori_.

It's good to see this important trade-off mentioned. I've seen Spolsky's
infamous allegory about Netscape [1] that "[rewriting] the code from scratch
[... is] the single worst strategic mistake that any software company can
make," used to browbeat people in response to their quite justified opinion
that "maintaining it is simply untenable." While Spolsky does go on to nuance
his statement a little bit, advocating for a careful refactoring process with
lots of tests, I was happy to see the same advice formulated in a way that
precludes such cherry picking here.

[1]
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

------
Plishar
I usually skip articles like this. It's like saying biology is immaculate,
fetid and grimy.

No, but some of the people are. Happens in all fields.

Science is usually reduced to a list of facts. Emotions usually are not
related, but if it helps you, go for it.

I half-expect these types of articles to give this tidbit of advice: talk
nicely to the computer. It's your friend.

~~~
douche
I have to conclude that you didn't make any effort whatsoever to RTFA.

    
    
        I half-expect these types of articles to give this tidbit of advice: talk 
        nicely to the computer. It's your friend.
    

Yep, that's exactly the advice given:

    
    
        Run your change in every environment you can get your hands on, and don’t be 
        be content that the software seems to basically work — 
        you must beat the hell out of it

