Successfully managing software quality with growing, globally distributed teams

Recently, Sorin Zaporojan, co-founder of SFactory, provided insights into the various lessons his organization learned as they developed, redesigned and constantly improved their Mobile Smart Wallet. But what types of software quality management lessons can be learned from a project that is much more complex than a single mobile app? Ray Auge, a Senior Software Architect at Liferay, provided his insights about the challenges Liferay has encountered when managing growing, globally distributed teams, and how they adjusted their application lifecycle management processes to deal with those challenges.

"The most difficult lesson I've learned is that developers think they are omnipotent—that they can do anything. This may be true, but there need to be significant boundaries to that decision-making process. You have to look really closely at what you want to achieve. You have to push yourself to limit the domain that you're working on. When you do this, there are significant benefits. You maintain focus and have much less skew in what you're trying to deliver." Auge's advice is simple: "Do less and do what you're doing less of much better."

Let function inform structure for software and teams

The most difficult lesson I've learned is that developers think they are omnipotent—that they can do anything

Ray Auge, Liferay Architect

Furthermore, working on such a comprehensive project in an open sourced environment with a distributed developer base simply amplified the challenges that were faced. In the beginning, every contributor was on top of their game: transitions were nimble and team members could easily shift from one role to the next. But after the first few million lines of code were written, the original approach needed to change. Developers were focusing heavily on their piece of the pie, but there was always a worry that other areas of development might not be getting the level of oversight that was deserved. What might be considered ad hoc specialization made it difficult to meet the needs of all stakeholders, and after a critical mass was achieved, a reorganization was necessary.

"There's a saying that 'your application is structured like your organization is structured.' This was the reality for us. We had one large team that was continuously growing and we had one large product that was continuously growing," said Auge. "The two things emulated each other. We started to realize that, just to manage the people alone, we needed to fragment into smaller logical groups that were specific to certain areas of the product. When we didn't have software that was built that way, it was difficult to operate that way." This then led to the heavily modular approach to software development that has brought great product enhancements, performance and usability improvements to the portal.

The Liferay transition to a modular approach has been very rewarding. "By changing our structure, we can scale, improve quality, have real experts and vertical dominion. We can put our best efforts into each part of the product."

Be a lifelong learner

Software development is a process of continuous improvement. But on a personal level, it's also a process of continuous learning. It's not just technology that's changing—the people behind the technology are evolving as well. What lessons have you learned that altered your approach to development? Let us know.

You can following Cameron McKenzie on Twitter: @potemcam
You can follow Liferay's Ray Auge as well: @rotty3000