There is a misconception in non-product software development around getting things done; where accomplishing a given task only once is acceptable. The developers who fall prey to this most often are the ones who have never seen a unit test and whom “mocking” is akin to Daily Show jokes. I’m neither an expert at unit testing and couldn’t explain how to use a library like RhinoMocks properly if my feet were to the fire…it’s just an observation. However, getting things done for that one release, for that one build, for that one functional test is common in far too many shops. Mine is no different.
The failure to build tools isn’t just around software testing. It pervades other areas of the application life cycle; early research into a project, or, say, data transformation – reproducing a database is a big one. Other failures to build tools are build scripts, configuration repositories, post-build events, cache validators, deploy validators, version checking… and the list goes on. I won’t harp on the build process – I’ve done a lot of that in the past. However, the actual release process – that is another ball of wax, or, more like the soft underbelly of the software life cycle.
All but the simplest of applications require some level of configuration management. So, if you click and drag your way to better software the rest of this essay might bore the pants of you. Or if you write Visual Basic. That’s just a straight jab.
Applications are more than their code since any significant application written for business in the last 20+ years uses to some kind of data source. And that data source, usually, is not the same for the developers or testers as it is for the end user. Hence, this variable data needs to be stored somewhere. Simple enough then. Put it on disk. Somewhere. Modify it….at some point? The question is when and how – which leads to the the primary paradox of building or not building tools I’ll address.
As software developers, we are often faced with the situation to write a script to parse 20 odd lines of some odd piece of data. Additionally we often just need the data once, loaded up, or put into a CSV file. The angel on our right shoulder tells us to write a Python script to automate it so we can do it again tomorrow if necessary. The little red guy with horns on our left shoulder tells us to do it by hand; just crank it out, as we’ll be done in 30 minutes and can go home and play World of Warcraft or watch American Idol. Mr. Red doesn’t remind us that the last thousand times we cranked it out by hand it didn’t work out and we had to do it by hand a dozen more times. Hence, with limited cognitive abilities at our disposal, as we just write software not make cheese, we go with the choice of leisure: do it by hand.
If professional software developers, being us, often make the choice not to build the simplest of scripts for tooling, what do you think occurs with the folks in IT/QA/Systems? If you’re first answer is they find a big expensive software package that will do this for twice the hassle of everyone involved, you are right! However, as this is universally accepted and widely documented let us examine the second most obvious choice. Yes, they will hack out whatever it is that needs doing by hand.
Spending time with someone in IT working in a Windows environment is like must see TV. I consider it a cross of Lost and reruns of Friends. There is constant, really constant, clicking around. Click this OPEN, click that CLOSE! Drag files. Stop. Reset service. Click, click, click, click – ad infinity. If you are fortunate to watch these activities in the wild, like Lost, you’ll wonder what the heck is going on, and like the Friends reruns, feel like so much time is being wasted.
A software release process can get rather complicated; especially on the web. On the web, inevitably you’ll end up deploying, at the minimum, hundreds of files. In lots of cases it’s actually thousands of files. This is simply the nature of the web. Along with these application files, and their resources (html, images, video, pdfs) are their configuration files. And the configuration files required for the production release is not the same as the configuration files in your QA environment – still sound so simple?
Ok, probably in theory. But in practice it’s different, and when someone walks through the process and arrives at this point they understand the complexity, timing, and work required to pull off a release. But, sadly, the reason they see this is because there isn’t a tool built to abstract this away. A nice GUI tool for IT to use. And, when that doesn’t happen, it’s time for software developers to step up and take over. Because the failure to build tools isn’t with IT – it’s with us.