Insanity: Building Software Like We Always Have
Feeling a little crazy? Try these simple, but effective, Agile tips to get your team out of their rut, and back to being uber productive.
Join the DZone community and get the full member experience.Join For Free
Albert Einstein had a lot of bright ideas, but his definition of insanity — “Doing the same thing over and over again and expecting different results” — has a particular relevance when it comes to software.
Since the dawn of computer programming, code has mostly been developed in the same old, expensive, flawed way: build, test, deploy, operate. That sequential model builds in all kinds of disadvantages that can hardly be avoided. Teams spend most of their time waiting for their turn to write code, test code, integrate code, deploy code. That’s hours upon hours of expensive, wasted time. Disadvantage 1: cost.
Add to that the fact that 80 percent of teams experience delays in development and QA due to unavailable dependencies, costs, or system availability constraints. It's become a question of too much work to do and too little time. And so, the time crunch inevitably leaves little time for functionality and user testing, which in turn leads to flawed or poorly integrated software. Which, in turn, leads to poor customer experience and lost market share. Disadvantage 2: poor quality.
We could go on, but the point is that companies have been repeating these same mistakes forever. Under Einstein’s famous definition, it’s insanity. But as Regan Walker, director of DevTest solution presales at CA Technologies, explained in a recent webinar, there’s a better way for organizations to meet customers’ growing demands.
Meet Expectations to Maintain and Grow Market Share
Enterprises today, more than ever, must serve up apps that meet or exceed customer expectations. Walker says 94 percent of executives face increased pressure to release apps more quickly, and two-thirds face the demand of higher-quality releases. And, as we all know, nearly 80 percent of users will abandon you — either give up or delete the app altogether — if their first experience isn’t up to snuff.
“You have to meet their expectations to maintain market share,” Walker says. “This is where continuous delivery comes into play.”
With the right tools, many companies are finding success by making their entire Software Development Lifecycle (SDLC) continuous. That is, they are always developing, testing and releasing newer, better iterations of their apps. At CA, they’re calling it a “modern software factory,” and it’s built on three pillars:
- Rapid, continuous development: Implementing an Agile development methodology can improve delivery times while driving down costs. Add to that Service Virtualization tools that allow you to eliminate development constraints and the broadest possible set of test cases to avoid unhappy surprises later.
- Continuous testing: Beyond virtualizing dependencies, it’s necessary to automate testing to maximize the number of tests while eliminating manual mocks and stubs. Engineers have higher-order tasks to focus on. Synthetic data generation, possible through Service Virtualization, also carries benefits for compliance and security.
- Continuous releases: A key benefit of a Continuous Delivery ecosystem is the ability to automate everything, from start to finish. This saves loads of time and allows for a greater number of releases so you can focus on continuous feedback and improvement.
The net-net is that your apps are of higher quality, hit the marketplace faster, and are less expensive to produce. You’re suddenly driving innovation at a fraction of the cost.
At the heart of this effort is Service Virtualization, which facilitates automated tests by making test data management and test environment simulation possible. As Walker describes, SV can be assembled with other tools that do everything from automating tests and releases to creating APIs and measuring performance — all in one seamless cycle.
“The one thing I always say to people is that testing at this point should no longer be an event,” he says. “With Service Virtualization, there shouldn’t be a line item in a project plan four weeks after the project starts. You should be testing continuously, testing daily, being able to test immediately, not just from a unit test perspective, but also functional and performance testing, and testing throughout.”
Check out Walker’s free webinar for all the details on how companies are doing it.
Published at DZone with permission of Michael Joseph, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.