Repeatability
Repeatability. It’s the essence of what computers are supposed to be able to do - it’s what makes them better than people, right? It’s why they’re used to take measurements, perform operations on numbers, send people to the moon and run everything from sewerage plants to nuclear power stations.
Computers are also programmable. They’d be pretty useless if they weren’t. We can program computers to do almost anything we care, if we work within the constraints of the hardware we have and don’t trivialise really complex problems (like understanding vision) and attempt to solve them with limited compute power.
So why do I see, again and again, people producing complex software and then reducing themselves to wholly manually procedures for the fabled "last 10%" of a software project - namely the testing and deployment of applications?
To not have an automated suite of tests built alongside the application itself should be downright heresey in 2008. If you start to write unit and functional tests when you write the software in question you can always be sure that your fundamentals work, no matter how much crap and how many workarounds you pile on top as your codebase grows and changes over the years. Automated test tools exist for just about every popular lanuage in use - why on earth would you not start out using them?
Instead software houses seem to think that manual testing, and hiring (and paying!) bodies to sit there day after day testing software is the right way to go. Apart from being hugely expensive and slow, people testing software are as falliable as the next person. Why not automate the testing for the most part and leave the good bits to the humans? Presentation logic, new code functionality, GUI intuitiveness - not whether the ORM on your customer details model class is still working correctly despite the changes and patches in the last 3 versions.
Take this graph from Agitar Technologies (a company with which I have no affiliation):
In short: once your code is in production it cost you a huge amount of money to fix any problems. You can greatly reduce this cost by building tests that will prove, in all but the most of the edgy of edge cases, that the code you wrote before is still working as intended, no matter what you do to it in the future.
The second area where I see software houses blindly throwing people at manual procedures is the deployment and production phase. Quite simply, it’s not only a stupid waste of money to have people reproducing multiple steps to get new code into production, it’s downright dangerous. If you screw something up during development it doesn’t leave the company. You can bitch and moan and do all the overtime you want in the world to fix a mistake, but once the code is in production your audience is now your bill-paying customers. Trust me when I say their tollerance is even lower than yours to wasted time and sums that do not add up.
You should have a cast-iron automated way of getting your code into production, with multiple steps of verification along the way. If you do not do this then you are doomed to failure. Script it, check your return codes, and have the system back things out automatically if something goes wrong at any step along the way. Use Ant, use Capistrano, or pick something else from the list - use a shell script or some Perl, but use something. In the Java world deployment to production should be some CVS/Subversion/Git hooks, Lunt Build hooks, a bit of Ant and some shell scripts. That’s it.
You should not be:
- Tweaking configuration files in multiple locations before a deployment to production. You should have one authoritative location for every configurable that has been signed off before deployment by the various parties involved, and that should ideally hardly change between deployments.
- Deploying bespoke code for a single client.
- Making changes for your production environment because your pre-live testing environment is not identically. If this is the case then you’re really testing in production and you’re doomed to failure again. Do your clients know that you’re testing in production? Would they be happy about it?
- Rushing untested changes, let along purely human-tested tested changes into production.
It has never been easier, as a small-to-medium software development house, to take advantage of these basic principles of modern software development. The free tools exist, and they are easy to use. The best in the business are doing it, and doing it right - that’s why they’re the best. The IBMs of the world have been doing it for a long time. The real serious people in software development have been doing it for years.
To quote Charles Fishman from his excellent article:
Software is everything. It also sucks. "It’s like pre-Sumerian civilization," says Brad Cox, who wrote the software for Steve Jobs NeXT computer and is a professor at George Mason University. "The way we build software is in the hunter-gatherer stage." John Munson, a software engineer and professor of computer science at the University of Idaho, is not quite so generous. "Cave art," he says. "It’s primitive. We supposedly teach computer science. There’s no science here at all."
Let’s at least use what we have to make things suck a little less.
