Scriptors need to learn from Developers....

The rant on this one was pretty good...Check it out on Podcast 04...

Let's start off by explaining the difference between scriptors and developers.  Both write code to complete a task and they use functions, loops and if/then statements.  So what really separates them?  

Scriptors write to solve a problem they are having right now.  They don't think that what they do will have any long term effects or purpose.  They think that what they write will never be re-factored, enhanced, or reused.  Scripting is quickly solves the problem today and leaves you to worry about tomorrow's problem when it shows up. Scriptors don't waste the time commenting the code, because they are the only one that will ever need to understand it.  They don't need to know anything about no stinking Version Control and they most certainly don't need to build a suite of scripts they can reuse.  There never is a need to write their own frameworks and test suites, because readable and reusable code is crazy developer speak.

Developers write code and scripts with a purpose.  They always want a well a defined end goal.  Their code is written with the expectation it could be reanalyzed when they realize what they wrote yesterday doesn't work for what they need to do tomorrow.  A useful tool often used are version control systems. This allows the developer to reset and try again when they realize they were wrong.  The very best of them prefer to write in a tests style format. Why? Because they have more than once changed a single line of code and had it blow up in their face.  This leads them to build or use frameworks because they understand that re-writing the same basic stuff over and over is a waste of their time and talents.  Thus "Standing on the shoulders of giants" for them means they can sleep at night.

How do I know all of this?  Because I am a reformed scriptor.  I have been supporting developers for more than 17 years.  Working along side some of the best and worst developers I was able to observe what made the good ones great.  During our lunches, I would let them school me on why I was doing it wrong.  While developers aren't perfect by any means they tend to be more thorough, but that's a subject for a different blog post.

There are normally three factions inside an organization, developers, operations and tool owners.  For this discussion, people like DBA's and IT security personnel fall into the operations grouping.  Tool owners are generally in one of the other two factions when the topic of being a scriptor is concerned.  As a general rule, operational staff are the majority of scriptors.  Developers who act like scriptors tend not to last very long as developers.  The rest of this article will show why they should be more like developers.

In the IT world both sides, developers and operations, want the same end state.  We want happy customers and if at all possible no calls at 3 am about silly production problems we should have fixed before it got to production.  While writing a quick script at 3 am may resolve the incident, it almost never fixes the problem.  Having been there and done that, I understand the thinking behind it.  What I have learned though is that taking a little more time the next morning to write a better script get's me back in bed faster or keeps me from being awakened at some point in the future.

OK, so you take more time the next morning and write a better script; how does that make you more like a developer?  Honestly it doesn't.  What it does is after some rest I can usually think through the problem more clearly.  I can look at the whole problem and determine if I have already written something better by looking through my GIT repository of scripts.  Even if I don't have the exact script I need, I often pull a bit of code from this script and that script putting it together to make an even better one.  That's something I can't do easily if my scripts are spread across 100 servers.  I have also lost more hours of scripting time than I care to think about because I didn't keep track of it centrally.  Then there is the time I have lost work because I didn't backup a script before changing it.  This is why I now put every script, no matter how trivial into at least my personal GIT repository.

When tackling larger problems and trying to eliminate menial tasks, I used to just keep copying and pasting the same code over and over into my scripts.  This worked great right up until I learned a new way to do something.  Let's say I found a way to take 10 lines of code down to just one.  Maybe I found a way to speed up the code significantly.  To repeat this change I would need to go to every script that used it and change it.  You can guess how many times I have re-factored a change like that into my older scripts.  That's why I have started building libraries of commands I can source in or import into my scripts. Now when I make a change to something I use all the time for a more stable or faster version and all of my scripts benefit, not just the latest one.  This is all there is to building a framework.

The only problem with my frameworks have been that I don't have time to test all of my scripts that use them every time I make a change.  This is why I now try to write test scripts that make sure everything still functions as expected after a framework change.  It's really not that hard even for Bash scripts.  You end up with a file or series of files that calls each script and checks the output for what you expect.  Doing this for every script I write isn't practical or a good use of my time.  Since you wrote the code you have to make a reasonable judgement call on when to do it.  I will warn you that this one thing I have learned from developers is kind of addictive.

Some problems are just to big to handle on my own.  Things like managing a cloud infrastructure or writing scripts that effectively manage configurations and files on 100's of servers.  This is where I stand on the shoulders of giants.  I regularly use and advise customers to use tools like Fabric, AnsibleWorks, Puppet, Salt, Chef and oVirt to speed up and generally make things more stable.  As with anything, there is a learning curve with each of these.  That time spent learning them will almost always be shorter than the time to implement your own solution.  Another thing is that all of these projects are built by teams of people.  Most of them have a company or group of companies that will, for a fee, help you solve your problems with them should one arise.  So you are not the only expert on these tools.  The best reason to use them is that you don't have to write all of the documentation about how to use them.  You only have to write a few to explain the how and why the configurations are the way they are.

So if you are a scriptor I hope you see that being just a little bit more like a developer can make you better at your job.  There is nothing wrong with a quick script to solve an incident, but there is something wrong with thinking and acting like a scriptor when you are trying to solve a problem.