To explore advanced development practices, why not turn to dynamic tech companies tasked with delivering sought-after software for the industry itself? That was the thinking, anyway, when I recently agreed to moderate a panel hosted by the QA company Rainforest that featured representatives of Atlassian, GitHub, HackerOne, and Rainforest.
It was clear from the start that these companies saw themselves as part of the vanguard. For example, all four panelists claimed their company’s developers were immersed in CI/CD (continuous delivery/continuous integration), employed automated testing, and organized their dev organizations into small, semi-independent teams.
The putative theme of the panel was “deploying faster while mitigating risk.” But Derek Choy, VP of engineering for Rainforest, kicked off proceedings by laying out the real proposition: Delivering good software quickly is mainly about optimizing processes and properly organizing teams.
Keeping up the pace
Ever since the Agile Manifesto, developers have been encouraged to increase the frequency of delivery as they decrease time to market. But as Atlassian’s head of software teams Jens Schumacher asked, “would we not be creating bugs and problems if we didn’t move this fast?” Echoing Choy, he identified the lack of processes and collaboration as the chief pitfalls as opposed to speed, which actually offers benefits:
Moving fast I think actually enables you to get better, because the more often you do something the better you get at it. If you think about it in the past we released once a year. Now imagine if you do something once a year – I do my taxes once a year – I’m not very good at doing my taxes. Now that we do it daily, I don’t think we make as many mistakes deploying anymore.
GitHub product manager Cristina Fernandez turned that statement on its head: “I was going to make the opposite argument: That you could have really huge disasters from moving too slow… [We’re] not driving the engineering team into the ground, because that doesn’t make sense, but moving fast on getting small pieces out there and learning from it.”
Smaller, more frequent commits with integrated feedback from stakeholders has been the software development mantra for years. If you pledge to continually improve processes, optimize team dynamics, and articulate goals plainly, speed finds its own equilibrium and quality improves.
Building stellar teams
Small teams as a fundamental building block of development organizations has become common wisdom. HackerOne VP of product Soufiane Houri put it bluntly: “I always value the team more than I value the individual,” he says. “Yes, an individual might have a need for complete autonomy and working from a Starbucks or whatever,” he said, but that can’t be allowed to hurt the productivity of the team.
Every company structures teams differently, although autonomy was a common theme. Houri says HackerOne favors “squads,” which are “independent units in a way, owning a product area, and all the units can pretty much work on any part of the product. They have general knowledge of the solution, of the platform, and they can actually go and dig in deep in a particular area and actually drive a road map and as a team.”
Schumacher had a similar perspective, with an accent on leadership. “If the team works well together then everything works better. We’ve seen this a lot. The team is made up of more than just a triad, but we have a leadership triad that’s usually made up of a designer, an engineer, and a product manager, and lately an analyst as well. And it’s really important that leadership of the team is really well aligned.”
A mix of experience levels can help teams succeed, Fernandez noted. “Sometimes you’ll have all these people working on something and someone who’s a lot more experienced comes in and says, ‘oh, we solved this a million years ago,’ and in five minutes they solve a problem that you’ve been working on all day.”
On the flip side, recent grads venture to places experienced developers can’t or won’t go. “The things they come up with, the problems they tackle, are amazing,” said Schumacher. “The more experienced engineers who have been there longer are like: How did they come up with this? Why did they attack this? They’re so naive [they think] ‘that’s gotta be possible!’ But sometimes it’s because things have changed, and people who have been with the company longer just don’t see it.”
Securing the code
Security at the code level has become a hot topic, one to which InfoWorld has devoted considerable coverage lately (see Fahmida Rashid’s recent feature, “Want secure code? Give devs the right tools”). Rainforest’s Choy zeroed in on the key security challenge:
Security typically slows things down, because you have more that you need to consider, you have more you need to build in, and perhaps you need to test more. So security is always seen as a bit of a hindrance. Traditionally there haven’t been a lot of tools to actually help make that more efficient. My perspective is that...if you don’t actually think about security as part of your process, then adding that in at any certain point is going to be a big pain.
Houri noted that security tools for developers are not that effective. “They raise a lot of false positives,” he said. “For a lot of developers it’s a nuisance in a way. It’s about teaching developers and educating developers how to write more secure code—things to watch out for—and educating them about the vulnerabilities that can be found in software… Security is part of the software development lifecycle and starts early. It’s not something you do after the fact.”
At GitHub, Fernandez says the company’s transparent working style—where all activity is fully documented for the whole development organization to see—helps ensure security concerns are addressed from the start. “The security people, if they’re being really proactive can say, ‘oh that [project] has these things, let’s get involved,’ and they can help early on.”
Getting enterprises on the bus
Radical transparency, CI/CD, two-pizza teams, and so on aren’t modalities you’d normally associate with traditional enterprise development practices. But Schumacher says enterprise dev is evolving in that modern direction, though not across the board. “It’s in small pockets right now,” he explained. By way of example:
We always think banks have really strict processes and strict requirements, but the way they can move faster is by acquiring more agile processes to the parts of the system that are not as essential, that don’t require compliance. I’m always surprised to see how fast and how much of the modern process they actually use.
As far ahead as Silicon Valley likes to believe it is, the truth is that not only does everyone have access to the latest technology—through, say, GitHub’s endless open source repositories—but all organizations are free to copy and implement best development practices at will.
If there was a single message of this panel, it was that process trumps tech, and you have to keep experimenting to get it right. True, ingrained traditions and regulatory constraints may make adopting new models harder inside older enterprises. But team by team, it’s happening.