Release cycles for mobile apps development projects are getting shorter. How can software teams cope with the tighter...
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. I hate to admit it, but we 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 the most personal of all computers, the one in our pocket. Mobile apps development has made every consumer into a change and release manager. Each of us, every day, makes 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 given only to the most careful and thoughtful member of the release management team.
Those of us involved in mobile apps development are facing new challenges and new pressures we have not seen before. Time-to-market is a serious issue, which can make or break a business. Our competitors evolve just as quickly as we do, and staying ahead has created a new arms race.
The apps that act as portals to corporate data are the most challenging in this regard. Behind the face of the mobile phone, mobile apps rely on a massive technology infrastructure of systems that are serving up the information. Updating these apps requires exceptional co-ordination of changes from the mainframe to mid-range to desktop to the Web and to mobile.
Recently I spoke with several hundred federal government app developers in Washington, D.C. They said they are seeing growing demand from agencies and elected officials for mobile apps for citizens. Overwhelmingly, that's the direction things are headed in.
So all this pressure is on for release management teams everywhere. The easy way out is to relax controls, limit testing, ship and see what happens. And, as it turns out, this is exactly the right thing to do. But -- and of course there's always a but -- you should think very carefully before changing a methodology for developing applications that meets your business needs. What you should do is automate the 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 requires no manual involvement and continuous delivery happens continuously. Build out the automated test suite so failed tickets are automatically delivered into the developer's inbox.
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result. Continue Reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts. Continue Reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.