Submission + - Frequency and use of Unix executables
Johnny Mnemonic writes: "I help Sys Admin a Linux setup. It has a several hundred end users, spread out in many locations and time zones. Our users often write their own bash/python/perl scripts to help with their daily duties, and other users often invoke those scripts directly from the author's home directory when they have proven interesting and useful. Also, we have perhaps a dozen directories in which reviewed scripts can be located. Some of the scripts can be quite sophisticated, and grow to multiple hundreds of lines.
We have found that when a script is useful, our users expect it to work all of the time--regardless if the original author of the tool has quit, if the code breaks, or it doesn't scale up to being used by hundreds of users due to poor design. When that happens, we are put in the awkward and frustrating position of supporting a script that was poorly designed and/or poorly documented--and often the first time we are even made aware of it is via the trouble ticket for the tool breaking. So we are in mad scramble to understand the tool, and understand why it broke--and the users that have come to depend on it are breathing down our back.
The Sys Admin team would like to know all of the scripts that these users might be using. We care less about executables that have been written but aren't actually being used--so it's not really useful to just look for files which are +x. Our users are a clever bunch, and the utilities that they build themselves serve their needs well--we generally encourage this tool creation process. We encourage this kind of self-help, so we can't simply disable the ability to run arbitrary executables altogether. We just want to know about them when they build those tools, so we can better support them should they become popular with other users and useful to the business.
How are you aware of all of the scripts and tools that your users build for each other? How and when do you accept support responsibilities for home grown tools? How do you require users who just want to get the job done to accept coding conventions and best-practices? We have tried to mandate that the user base accept these from the outset of their development--but have found that strictly enforcing good code hygiene from the outset actually results in them talking to us less, not more--and makes the problem worse, not better.
Thanks!"
We have found that when a script is useful, our users expect it to work all of the time--regardless if the original author of the tool has quit, if the code breaks, or it doesn't scale up to being used by hundreds of users due to poor design. When that happens, we are put in the awkward and frustrating position of supporting a script that was poorly designed and/or poorly documented--and often the first time we are even made aware of it is via the trouble ticket for the tool breaking. So we are in mad scramble to understand the tool, and understand why it broke--and the users that have come to depend on it are breathing down our back.
The Sys Admin team would like to know all of the scripts that these users might be using. We care less about executables that have been written but aren't actually being used--so it's not really useful to just look for files which are +x. Our users are a clever bunch, and the utilities that they build themselves serve their needs well--we generally encourage this tool creation process. We encourage this kind of self-help, so we can't simply disable the ability to run arbitrary executables altogether. We just want to know about them when they build those tools, so we can better support them should they become popular with other users and useful to the business.
How are you aware of all of the scripts and tools that your users build for each other? How and when do you accept support responsibilities for home grown tools? How do you require users who just want to get the job done to accept coding conventions and best-practices? We have tried to mandate that the user base accept these from the outset of their development--but have found that strictly enforcing good code hygiene from the outset actually results in them talking to us less, not more--and makes the problem worse, not better.
Thanks!"
