"Criticism is constructive, comparison is abuse" from The Rehearsal by Eleanor Catton.
When you have no other measure on the field, you just need to look into the object directly. But if there is any, you then stop looking at it and start to looking for difference only.
I happend to work on a project which rewrites legacy C++ code to C# component based code. And got a lot of feedback of comparison with old software. It goes like this.
'Hey, this new one does not generate output same as old one.'
'But does the new output cause an issue ?'
'No, but it is not what user have seen.'
'What should be seen ?'
'Don't ask me. Just make it same as before'.
Legacy code has its own reason of being put in such a way. And when it unearthed, it is not easy to see why it was shaped in such a way.
Not to burden the follower, when writing code, code should be clean and concise. And should show intention and possibly reasoning behind the code.
Though no matter how crystal-clear the code, better way is to leave a document. And when referred after 10 years, the document should tell what the software should do not what it does.
No comments:
Post a Comment