You are here

You are here

Lean software development weighs in: How to put your mobile code on a diet

Christopher Null Freelance writer

In modern software—particularly on mobile devices—simplicity rules. What greater frustration does the typical smartphone owner encounter than downloading a seemingly simple app, only to discover it consumes hundreds of megabytes of space, crashes frequently, and requires a near-constant stream of updates?

Fortunately, not every app suffers from app bloat, and the reward of simplicity is one of the many promises of lean software development.

Software development gets lean

Lean software development was a natural outgrowth of lean manufacturing strategies that emerged in the late 1980s, primarily in productivity-obsessed Japan. Lean manufacturing popularized the elimination of waste—in the form of both unnecessary materials and labor—as a means to increase efficiency and decrease the costs of production. Many software developers quickly jumped on the bandwagon, adapting these principles to an environment where there wasn't any physical waste, but where inefficiencies often ended up being passed on to the user in the form of a bloated and buggy piece of code.

Largely popularized over the last decade, lean software development (sometimes abbreviated as LSD) focuses on reducing coding errors, eliminating non-critical features from the code base, and streamlining programming. The goals of successfully adopting lean software development principles include more stable software builds and more finely tuned code in which everything in the finished app feels like an intentional part of a single, cohesive product.

But historically, lean development has not been a priority in many organizations—and that's a mindset that's still prevalent today. Is lean development fundamentally at odds with modern design approaches like agile? When development takes place in a cyclical system with user feedback informing evolving specifications in real time, how do you keep software compact and focused when the direction may change from day to day?

To answer these questions, we spoke to developers in the field who are successfully reconciling these principles and creating streamlined software quickly and efficiently.

The aspirational reality of lean development

Jonathan Christensen is CEO and cofounder of Wire, a Swiss company that develops an eponymous cross-platform messaging app that has been described as almost aggressively minimalist. Christensen previously worked at Skype and Microsoft, and he knows a thing or two about how apps can rapidly bloat out of control.

Christensen describes his approach to lean development as part of a system that borrows from a number of development methodologies. "I'm not an adherent to any specific methodology," he says. "I borrow best practices from XP, scrum, and the higher manifesto of agile about trusting teams and keeping teams small."

Jack Hirsch, VP of desktop applications at Evernote, says that lean is "an aspirational ideology" and that "it's not always possible to operate in a purely lean development. Sometimes, you can find the principles in opposition to one another. For example, lean discourages slow communications and development. But if you're building quality in, you're probably refactoring as you go. To some, that can feel slow, repetitive, and wasteful, but it's often necessary to ensure quality."

In keeping the Wire app suite lean, says Christensen, "the lesson that I learned over and over again is to avoid investing in big-milestone, multifaceted releases. It's a bad movie, but somehow we have to watch it over and over again." Christensen is talking about swing-for-the-fences updates that are released as a matter of course during the standard development cycle. Instead, he says the smart move is to keep "work in progress" (WIP) updates extremely focused and the cycle time very short. Development teams only work on one, two, or at most three items on the WIP list for each release, so the risk of feature creep and app bloat is minimized.

"When you have an open landscape of possibilities, you have to retain that mantra and discipline to enforce that high-level WIP philosophy across teams." Christensen says he asks his teams regularly, "Are we adhering to this approach?" He keeps the WIP list very short and serialized so that features are developed one at a time, to the extent possible.

Lean development doesn't mean eschewing periodic big releases, but Christensen says that development of these releases should be made independent from the day-to-day development process. "It's OK to invest in big things that take a long time," he says. "Sometimes those things are groundbreaking. But the milestones are bigger and they take longer to reach"—and they're kept separate from the WIP road map.

Christensen points to two key factors that influence lean development. The first is a ruthless devotion to daily stand-ups. "Everyone clearly states, 'This is what I'm working on today. By tomorrow I'm going to deliver this.' That's at the small group level and at the higher level. It takes work to keep it rigorously enforced, because not everyone wants to participate or they may think it's a waste of time, but it's worth the investment."

Slimming down on stakeholders

As a bigger factor, Christensen points to his product team. Or rather, he doesn't, because he doesn't have one. "We have design and we have engineering and we don't have a product organization. It didn't start out as a philosophy...but I've found it's a lot more effective to have design sit in cross-functional teams with engineering and discover the art of the possible together," he says.

"A lot of the time you see the product team request a feature that's not feasible from an engineering or a design perspective, and it gets way down the road before anyone realizes it can't really happen," Christensen says. "We don't have product people and find it's more direct to fit iterations around that structure in real time with design. It's been a really nice and clean way to get things translated from concept and execution without a lot of unnecessary iteration."

Evernote's Hirsch outlines three principles that resonate with the company: "Empower the team, decide as late as possible, and build quality in."

Evernote is unusual in that the app doesn't work the same way on every platform. That's due to the empowered team design, says Hirsch. "Evernote's teams are organized by platform and combine design and development resources. Each team is empowered to determine and deliver the best experience for their platform irrespective of the development successes of other teams. This means that we don't always have feature parity across platforms, but that the experience is the best it can be for any given app."

Quality-first comes from the top down

"In our overall development process, we believe in having a plan, but we also believe in gathering requirements until the very last possible moment for the best results," Hirsch adds. "Having said that, we try to resist the urge to let anyone parachute in at the last minute with brand new requirements that could derail timely delivery of a product or feature. Building quality in and allowing time for refactoring are aspirational parts of true lean development. We're moving in that direction, but it's very difficult to retroactively build quality into a mature product. It has to be done gradually to avoid grinding new feature development to a halt."

Ultimately, Christensen notes, a "buck stops here" mentality at the top of the organization is essential to ensuring all of the above remain intact. "Somebody has to be responsible for how you spend the resources. We set the broader themes for the teams very actively and we don't just do things—or try not to—for the sake of doing them. We try to be ruthless about cutting things out that don't absolutely need to be there."

Keep learning