How many times have we been nudged into doing things we once would have pushed back on? Technology advances constantly shift our way of working and we, I hate to admit, are often the last to accept the new paradigms. As a friend once said to me “A good COBOL programmer can write COBOL in any language.” For those of you wondering what COBOL is … ask your parents.
So now our technology world is about delivering apps to that most personal computer, the one in our pockets. Mobile apps have made every consumer into a change and release manager. Each of, every day, make choices as to which apps we’re going to update and which we’re going to ignore. We are the final approver prior to deployment: an honor once only given to the most careful and thoughtful member of the release team.
For those of us developing apps for mobile devices we are facing new challenges and new pressures we have not seen before. Time-to-market is a serious issue with first-mover status having business making or business breaking impact. The competition evolves just as quickly as we do and staying ahead has created a new arms race.
The apps that act as portals to corporate data add a more impactful consequence. Behind the “glass” of the mobile phone is a massive infrastructure technology, platforms and systems that are serving up the information. Changing these apps requires exceptional co-ordination of changes from the mainframe to mid-range to desktop to the web and to mobile.
Earlier in the month this month I spoke with several hundred Federal Government app developers in Washington DC. The demand for citizens to on-line in a government app rather than in-line in a government office was overwhelmingly the direction they were getting from their agencies and elected officials.
So all this pressure is on. And the easy way out is to relax controls, limit testing and ship and see. And, as it turns out, this is exactly the right thing to do. And the “but” you are expecting is this … you have developed a methodology for developing applications that meets your business needs. You should think very carefully before changing those processes. But what you should do is overturn the reliance on those parts of the process that are utterly manual.
Let’s take this opportunity to automate all those parts of the lifecycle that can be automated. Moving the code to the test environments, to the staging environment and to the App Stores. Set up the infrastructure so that continuous integration has no manual involvement and continuous delivery happens continuously. Build out the automated test suite and generate failed tickets automatically delivered into the developer’s inbox.
By adding automation to every aspect of the development process we can shorten timescales, increase quality and address the needs of the business without compromise.