3 ms·

Blaming is the least productive thing when it comes to these things. Maybe the developer wrote that at midnight after a long day of work, and at that time it so

Blaming is the least productive thing when it comes to these things. Maybe the developer wrote that at midnight after a long day of work, and at that time it sounded like a good solution...

Klathmon 9y ago
I've found most times it's not even that, but that the "bad code" was in most cases the best possible code that could have been written within the needed constraints. You need a fix for problem "x". You can either write the ugly hack by next weekend knowing that it's going to be replaced by the big rewrite you have coming up in 6 months, or you can spend 1 month refactoring code to make a "proper fix" that will last another 5 months until the code is rewritten... Of course when you have an audience, they get to read into this however they feel. Some will point to the hack as an example of how awful the codebase is and how bad the developers are, others will point to it and proclaim (wrongly) how dirty hacks are never a bad thing if they work, still others will talk about how much better their idea their idea would have been even though it didn't fit your exact constraints. In my experience, very very few successful developers are "dumb" or "bad at programming" or whatever insults you see thrown around all the time. Most of the time it's just someone making the best of a shitty situation weighing several constraints while still keeping the product working.
- hinkley 9y ago
  You don’t identify the party to shame them, you identify the party as part of the Five Why’s. And then additionally to reassess your trust level when someone says they are “done” or offers you advice. Developers bank a lot on this kind of trust and shutting down these so-called “blame” exercises blinds the team. Don’t. People who don’t at least try to write better code every chance they get have a pretty poor understanding of “best” in a given situation. They will grow very slowly if at all, and their best isn’t good enough. And if it turns out you were the negligent party, don’t you want to know that? Don’t you want to recollect how you rationalized that piece of work and adjust your behaviors? Above all else, don’t count on a rewrite. It is a Once in a Blue Moon affair and if often goes wrong. It’s the worst kind of crap shoot. The worse things are the less likely the rewrite will work. Rewrites require you to recall the entire featureset and if the project is off the rails then nobody knows all of them, so any part you touch is likely to miss something important. Edit: the rest of a thought

Blaming is the least productive thing when it comes to these things. Maybe the developer wrote that at midnight after a long day of work, and at that time it sounded like a good solution...

Klathmon 9y ago

I've found most times it's not even that, but that the "bad code" was in most cases the best possible code that could have been written within the needed constraints. You need a fix for problem "x". You can either write the ugly hack by next weekend knowing that it's going to be replaced by the big rewrite you have coming up in 6 months, or you can spend 1 month refactoring code to make a "proper fix" that will last another 5 months until the code is rewritten... Of course when you have an audience, they get to read into this however they feel. Some will point to the hack as an example of how awful the codebase is and how bad the developers are, others will point to it and proclaim (wrongly) how dirty hacks are never a bad thing if they work, still others will talk about how much better their idea their idea would have been even though it didn't fit your exact constraints. In my experience, very very few successful developers are "dumb" or "bad at programming" or whatever insults you see thrown around all the time. Most of the time it's just someone making the best of a shitty situation weighing several constraints while still keeping the product working.

hinkley 9y ago
You don’t identify the party to shame them, you identify the party as part of the Five Why’s. And then additionally to reassess your trust level when someone says they are “done” or offers you advice. Developers bank a lot on this kind of trust and shutting down these so-called “blame” exercises blinds the team. Don’t. People who don’t at least try to write better code every chance they get have a pretty poor understanding of “best” in a given situation. They will grow very slowly if at all, and their best isn’t good enough. And if it turns out you were the negligent party, don’t you want to know that? Don’t you want to recollect how you rationalized that piece of work and adjust your behaviors? Above all else, don’t count on a rewrite. It is a Once in a Blue Moon affair and if often goes wrong. It’s the worst kind of crap shoot. The worse things are the less likely the rewrite will work. Rewrites require you to recall the entire featureset and if the project is off the rails then nobody knows all of them, so any part you touch is likely to miss something important. Edit: the rest of a thought