As you point out, we're all guilty of being on both sides of this. Just recently I took ownership of a project for a couple of months while it was transitioned between companies. I found myself in the curious position of being aware of being the scapegoat. It made me really aware of defending the previous team as I knew full well there would be code I'd written that would get bad mouthed if that culture was created. It was suitably humbling.
I often find that even when looking back on my own projects from just a few months ago - projects that are 100% my own creations - I'm often horrified at design decisions I made.
There really is something to be said for the advantage of having the complete picture laid out in a working implementation over crafting something from scratch with only abstractions to work with.
I've grown to greatly respect projects that do what they're supposed to do regardless of their whacky and inelegant implementations. Sure I could rewrite it to cut out half the bloat, but so could the guy who wrote this version.
I find the same thing sometimes. Though I usually use that as an opportunity to ask, why it is so bad, and what it would look like if it was done properly. Refactor from there if I have the time. If I don't have the time to refactor, at least write a comment explaining the nasty part - that way it should be easier to comprehend the next time.
I skimmed it honestly, it didn't hold my attention long enough but your opening paragraphs were good and I definitely agree with what the article was saying.
Also the current dev has no idea what the old dev's payment was like either and I feel like this could be a huge deciding factor in the quality of work provided by the old dev.
Sometimes the previous developer really is that bad.
I inherited a colleagues work after she left. One cron Job to launch a Python script - auto-everything.py. Which in turn spawned new shells to launch a load more scripts. One script even launched itself with new arguments. So trying to work out where stuff was failing was a nightmare, before I even got to look at the code.
Then the fun really began. Functions within functions, not to anything smart - just because she hadn't bothered to work out how the module system works. Few comments which were fairly useless "#Open file" above an open file statement (what the hell is contained in the file??? Add that to your comment). 'Indexes' and 'indexes' used as variable names in that function. Big nested hash structures with no explanation to its structure, or what it was for.
The thought expressed in the post reminds me of Norman Kerth's Retrospective Prime Directive [1], [2]:
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass."
[1] 'Project Retrospectives: A Handbook for Team Reviews', Norman Kerth
At my last company, I was working on a Java EE Struts app. After a few months of despairing over how bad it was, I realized that it was built by database people. That's why most of the logic was in sprocs, and they had no clue of what thread safety was, or how to build a HTML widget and menu system that consistently worked. Thank goodness that they knew about parametrized SQL.
9 comments
[ 2.4 ms ] story [ 29.5 ms ] threadAs you point out, we're all guilty of being on both sides of this. Just recently I took ownership of a project for a couple of months while it was transitioned between companies. I found myself in the curious position of being aware of being the scapegoat. It made me really aware of defending the previous team as I knew full well there would be code I'd written that would get bad mouthed if that culture was created. It was suitably humbling.
There really is something to be said for the advantage of having the complete picture laid out in a working implementation over crafting something from scratch with only abstractions to work with.
I've grown to greatly respect projects that do what they're supposed to do regardless of their whacky and inelegant implementations. Sure I could rewrite it to cut out half the bloat, but so could the guy who wrote this version.
Also the current dev has no idea what the old dev's payment was like either and I feel like this could be a huge deciding factor in the quality of work provided by the old dev.
I inherited a colleagues work after she left. One cron Job to launch a Python script - auto-everything.py. Which in turn spawned new shells to launch a load more scripts. One script even launched itself with new arguments. So trying to work out where stuff was failing was a nightmare, before I even got to look at the code.
Then the fun really began. Functions within functions, not to anything smart - just because she hadn't bothered to work out how the module system works. Few comments which were fairly useless "#Open file" above an open file statement (what the hell is contained in the file??? Add that to your comment). 'Indexes' and 'indexes' used as variable names in that function. Big nested hash structures with no explanation to its structure, or what it was for.
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass."
[1] 'Project Retrospectives: A Handbook for Team Reviews', Norman Kerth
[2] http://www.retrospectives.com/pages/retroPrimeDirective.html