| |||||||||||||
Shell programmingShell programmingPosted Dec 6, 2012 3:16 UTC (Thu) by davidescott (guest, #58580)In reply to: Shell programming by dlang Parent article: Quotes of the week
> I once had a 20 line, ugly shell script that I wrote turned over to the software engineering department for "official maintenance" and to bring it up to "professional standards". In three months they re-wrote the 20 line shell script into a 200 line Perl script, with everything that actually did something being a system() call that invoked the shell commands that were in my initial script (long ; joined lines remaining intact). But this was now a "professional" program, it had lots of comments (none of which explained what any of the calls were doing, or why), every function was less than one screen, etc. It's the best example I've ever seen of how "coding standards" can make a program hard to deal with.
That is certainly dailywtf worthy, but its also a sign that you screwed up by not following coding standards from the outset.
You fixed a problem (yeah for you) and your boss was happy. He gets to say to his peers in other departments "I've got this hot-shot programming magician who can solve all my problems, and he's all mine NAH-NAH-NAH-NAH." So your boss gives you something else and asks you to hand the old script over to "software engineering."
Software engineering looks at it and pukes. 20 lines of undocumented shell. WTF are they supposed to do with that? They complain to their boss who knows that your boss loves you and will never let you go... so they just get ignored. Some poor smuck is now sitting in "software engineering" with 20lines of shell that do god knows what, but he has to bring it up to "standards" which means perl. He wife is pregnant and his home mortgage is eating 50% of his salary, so he can't risk his job trying to bring the sh*t you dropped on his lap up to standards, so he does the next best thing. He just wraps the whole thing in perl system calls. It does exactly the same thing as yours does and he doesn't have to worry that by replacing your sed with a perl builtin that he might introduce a bug through some esoteric incompatibility between perl and sed handling of unicode strings. If anything goes wrong he can demonstrate that the output is the same as your output so its the same program you gave them.
So the real WTF is why you gave submitted 20 lines of undocumented shell script to systems engineering team for long term maintenance when you knew it wouldn't meet their standards in the first place. It was quick and easy for you yes, but completely opaque to those who were actually in charge of managing it.
(Log in to post comments)
Shell programming Posted Dec 6, 2012 5:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
this wasn't just stuff thrown over the wall, this was a system automatin script, it could have been documented better, but that would not have added more than about 10 lines. It was not written to be managed by engineering any more than a normal chef/puppet/cfengine config snippet would be. After the script was written, management decided that it was incredibly useful, but they were on the swing of the pendulum that says that system administrators are not allowed to write any code, only 'professional programmers' are allowed to do so.
making each line (or at most every two lines) of a shell script into a separate function (and of course, each function needs a 10 line comment as a header, giving it's name, plus now there needs to be a main function to call all these other functions, etc) does not help anything.
This same engineering department had a bug report submitted to it that contained a 5 character change to another tool for a bug that was discovered during a production deployment, it was found and tested by the sysadmins during the maintenance window. But the bug took 18 months to close as the entire script was re-written (and it was originally written by the engineering team and did comply with the coding standards to start with).
These are cases of people who don't know what they are doing blindly clinging to 'standards' without any understanding of what the purposes of the standards are, and without any ability to read code and understand it.
Shell programming Posted Dec 6, 2012 21:03 UTC (Thu) by davidescott (guest, #58580) [Link]
My statement was intended to be tongue-in-cheek, although I think it is a real problem with shell because there are lots more people who have a solid understanding of python than have a solid understanding of unix command line.
Yours sounds like a really dis-functional organization, and it is clear that management is handing the responsibility of maintaining this software to a group that is not capable of understanding what it does. Either management needs to stop doing that and let you manage what you write, or they need to enforce some kind of standard that prevents you from writing stuff that others can't understand, [or they could fire the incompetent people and hire someone who knows what they are doing ... as if].
|
|||||||||||||