News from the Worlds of Software Development and QA – November 2016

Welcome to this month’s look at a few interesting news stories from the worlds of Software Development and Quality Assurance. Last month, we covered Microsoft Teams – Redmond’s attempt to enter the enterprise social communication space dominated by Slack. November’s collection of news stories hopefully offers a few insights to apply to your daily work routine.

Without further adieu, here is the news!

Enterprises still struggling with Agile Software Development

An article in ZDNet from mid November takes a look at how enterprises are still finding it difficult to implement Agile as their software development methodology. The story is based off of a recent podcast between Santiago Comella-Dorda, Roberta Fusaro, and Gerard Speksnijder, all from the management consulting firm, McKinsey.

A main cause of problems is the large number of legacy systems in production at most enterprises. This makes it harder for their software project teams to be as nimble as required by Agile. Gerard Speksnijder commented on how this core issue isn’t present at startups or smaller firms.

“(Startups) don’t have the application-architecture legacy. There are no monolith applications. Everything typically is being defined in a pretty modular fashion, with lots of microservices, APIs, which allows you to make changes to the specific component of the application architecture. You can test it and release those features quite fast and without having lots of dependencies on other parts of your application landscape,” said Speksnijder.

The McKinsey analysts feel starting small, and using a product-based model, helps larger companies successfully implement Agile. They recently published a four-point program aimed at bringing Agile to the Enterprise. It is worth a perusal if your larger firm hopes to take advantage of this modern software development methodology.

DevOps is the Key for Success with Agile

Agile is definitely all over the IT news this month. CIO magazine published a piece describing the successful Agile implementation at Fannie Mae. A major factor in their success was an organizational structure based on DevOps.

A commitment to automation and a Continuous Deployment model for software delivery also played an important role. Using a racing metaphor, Fannie Mae CIO Frederic Veron described how DevOps helped his team achieve new benchmarks by doubling its software output over the last 18 months.

“If you do agile without DevOps, it’s like you’re trying to race with a tractor instead of a car. You can go and do the laps but it’s not going to go very fast, you’re probably going to consume a lot of fuel and it won’t be a lot of fun,” commented Veron. A software enhancement that used to take nine months is now fully implemented in 10 weeks using the Agile methodology, automated tools, and a DevOps organizational structure.

Needless to say, large and medium-sized companies need to consider switching to a DevOps structure at the same time they embrace Agile.

Well, this month’s post featured two valuable news stories from the trenches of the corporate software development world, as they try to leverage Agile for the purpose of faster software delivery. Starting with a small pilot program or completely restructuring your organization to a DevOps model raises your chances of success.

Stay tuned to upcoming editions of the Betica Blog for additional news and insights from the evolving world of software development. Thanks for reading.

Continuous Testing at the Speed of the Agile Modern Business

Relying on automation to execute whole test on large deployment, doesn’t mean the role of the QA engineer is going away. Learn why?

With more companies of all sizes embracing the Agile and DevOps methodologies, the speed of the software development lifecycle continues to increase. This reflects a competitive business world which operates all over the globe on a 24-7 basis. The days of the biannual release cycle appear to be obsolete.

Continuous deployment and other offshoots of Agile strive to make software enhancements a quick and painless process, so it stands to reason this “need for speed” would influence quality assurance. Enter continuous testing. We’ve mentioned this concept in a previous post, but this time out we’ll take a closer look at this emerging QA trend.

Preventing QA from becoming a Bottleneck

Companies embracing continuous delivery leverage automation to make various aspects of the SDLC faster. This includes automating builds, migrations, and other related tasks. While a need for manual software testing still exists, especially when it comes to validating usability and interfaces, companies are taking advantage of automated tests as part of a continuous testing model.

Continuous testing requires extra effort to be spent on developing these automated tests. This concept applies when it comes to determining whether or not to deploy the software into production after the test run is complete. Business stakeholders need to work closely with QA engineers to determine the criteria for a go/no go decision; factoring in performance, reliability, and security issues.

Additionally, many continuous testing programs involve QA personnel at the beginning of the lifecycle, with the hopes of validating design work before development takes place — the extra cost of handling bugs later in the SDLC still matters in this scenario. The scope of testing includes automated API tests, unit tests, as well as system and integration tests. Security and performance testing is also performed when relevant.

Managing the Continuous Testing Process

Relying on automation to execute a whole range of tests as part of a larger build and deployment process doesn’t mean the role of the QA engineer is going away. We mentioned earlier about the importance in properly developing automated tests able to determine whether or not to deploy a release. It is also vital to involve QA personnel in the management of the entire automated testing process, including performance monitoring and defect analysis.

Many QA tools and applications now include support for continuous testing that goes beyond simply automation. These typically provide a robust mechanism for authoring tests in addition to the real-time defect reporting and performance features needed to truly take advantage of CT.

Resources for Learning more about Continuous Testing

A wide range of eBooks and other material covering continuous testing are available if you are interested in learning more about this topic. SOASTA, known for their performance analytics software, offers an eBook on Continuous Testing in an Agile World. IT managers interested in the subject need to check out Parasoft’s book aimed at technology leaders.

In short, continuous testing needs to be considered by any organization hoping to truly take advantage of Agile or DevOps.

Keep tuned to the Betica Blog for further dispatches from the wide world of QA and software development.

Transform your Organization with the Inverse Conway Maneuver

As the process of software development continues to mature in the modern business world, the organizational structures of companies engaged in application design struggle to keep up. This is largely due to the tendency of these firms to produce software architectures matching their current structure, which can lead to outdated and lower quality products, especially in this era of Agile and DevOps. This behavior is known as “Conway’s Law,” named for the computer scientist, Melvin Conway who first made the observation in 1968.

Tech pundits recently formulated a technique known as the Inverse Conway Maneuver, which involves restructuring a business organization to more closely match a desired software architecture. In an ideal case, business and technical teams become better aligned and ultimately produce higher quality work. Let’s take a closer look at the Inverse Conway Maneuver to see if makes sense at your company.

A Closer Look at Conway’s Law

Way back in the nascent computer age of the 1960s, Melvin Conway noted that committees tended to build systems that matched their business structure. His basic thesis for Conway’s Law is straightforward and was first made in the article How Do Committees Invent published in 1968 in Datamation Magazine.

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

Conway’s Law can be applied to a whole range of scenarios beyond software development as noted in the thesis. Its counterpoint, known as the Inverse Conway Maneuver, involves reengineering the structure of an organization based on a desired software design.

DevOps and the Inverse Conway Maneuver

In the modern development era, the DevOps methodology serves as a partial example of the Inverse Conway Maneuver with teams merging and evolving to reflect increased collaboration between the programming, QA, and network administration roles. Following a DevOps organizational structure is typically necessary for companies to be able to break down older, entrenched mindsets that won’t work at today’s speed of business.

Jason Bloomberg of Intellyx feels the rate of technology evolution in today’s business world is actually “reversing the Inverse Conway Maneuver.” Instead of companies making structural changes ahead of time in the hopes of reaching goals like DevOps or continuous deployment, the transformation is actually happening in the opposite direction.

“Technology change is driving changing customer preferences and behavior, which in turn are driving organizational change across increasingly software-driven enterprises. The causality question behind Conway’s Law, therefore, is less about how changing software organizations can lead to better software, but rather how companies can best leverage changing technology in order to transform their organizations,” says Bloomberg.

No matter what triggers this organizational transformation, there is no denying modern software businesses need to evolve to produce a better end-product lest they get left behind. The competition remains fierce. It is fascinating to note a “law” first formulated in the late 60s still holds so much weight in the software industry today.

Stay tuned to further installments from the Betica Blog as we dive deeper into the worlds of software development and QA.