There Is No Bad Code

Your bugs? Nothing wrong with them. The code simply does the wrong thing. It was not intended. But that’s what it does now. <blockquote> What will you do about it? </blockquote> Some don’t ship it. They understand that it’s not functionally doing what is expected, and so take the time to revise it until it—at least seemingly—does the right thing. If someone ever knows what it actually should do. When they do (think they) know, they might add tests, or even use a test-driven approach, to get to that state in which they have confidence that what is shipped is what is expected. Some ship the code. They might know that it does the wrong thing. Maybe they hope no one will notice. Sometimes no one does. Some are forced to ship it. They are not measured by outcome but by output. They spent their X number of hours. Time’s up, boys and girls! Fuck it, ship it. The task/scrum/scum master has spoken. The whip has been cracked, and so has the will. Word is bond, ye slaves, and nothing is more sacred or more bondaging than story points and “burning down” at an increasingly heart-racing pace. If a forensic psychologist would come in, pyromania would have been declared long since. Some let the customers find the problems. This is fine if the loop is monitored and automated (et cetera, yada yada…). But that’s not the persona I’m thinking of. No, these are the truly despicable bad guys who let the customer feel the pain and have no automation to alert on turds hitting rotary fans. No—they let them call in. That’s the sign of a true, loyal customer—the one who dares to struggle with Customer Support. For free, with nothing material gained from this ordeal. A true Customer™. One all organizations are in awe of. One to be proud of. Such customership is forged in agony. How do you make customers if not through menial oppression? <a href="https://betterprogramming.pub/there-is-no-bad-code-5198fb8a58c2">Read More</a>