Maxim_Kazmin - Fotolia
Enterprise technology leaders who take a hardline approach to punishing their DevOps teams for failure risk missing out on valuable learning experiences, it has been claimed.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Speaking at the Lead Developer conference in central London, Kevin Goldsmith, CTO of online legal services marketplace Avvo, said enterprises should not fear failure because it often paves the way to creating innovative and inventive products.
“Innovation requires failure,” he said. “That’s what we do in software. We make hard things easy. We create new industries. We disrupt old industries and we find efficient ways of doing things, and it is hard to do something perfectly the first time. If you can, it’s probably not that novel.”
Despite the important role failure plays in the creative process, tech leaders are still too quick to punish teams responsible for creating products and services that do not hit the spot, he said.
Some of these punishments can be obvious, resulting in whole development teams being fired, or more subtle in nature. Either way, it is the teams that fail to learn from their mistakes that should find themselves in the firing line, said Goldsmith.
“Failure is the opportunity to learn. If you don’t learn from your failure, then you’re just wasting time. So don’t punish failure, but punish not learning from failure,” he added.
There is a tendency for developers working on less profitable projects to find themselves ridiculed by their peers, which is another form of punishment, which tech leaders need to stamp out because of how discouraging it can be, he said.
“The teams not making the money now are the ones that will make bigger money, hopefully, some day,” he added.
Areas for improvement
Goldsmith went on to concede that, while it not fun or pleasant to dwell on their mistakes, it is important for DevOps teams to evaluate their past work to pinpoint any areas for improvement.
For example, it could be down to the team having to take on new technology that they were not adequately briefed on how to use before embarking on the project, or not having the time to bring people into the project who knew how to use it.
After a period of self-reflection, it may come to light that their perception about what their customers want from the product or service they are creating was not quite right, said Goldsmith.
“We all create myths of who our customers are. Hopefully, those myths are actually informed by good things, like user research and reading forums, and Twitter, and app store reviews, and meeting them in person. But the fact is, you can’t know perfectly the souls of every one of your customers,” he said.
Read more about DevOps culture
- The 2017 State of DevOps Report highlights why supportive, communicative and visionary senior leadership is a must for agile software development to succeed.
- Cultivating a supportive and collaborative business culture is considered central to getting DevOps to take hold in an organisation. We take a look at what this entails.
“Even if you could perfectly know all of your customers today, it’s going to change tomorrow because you’re going to get new ones, and those new ones are coming with completely fresh eyes to your software.”
He said it is also important to hold similar post-mortems for successful projects and, no matter how uncomfortable it may be, to communicate what went well and could have gone better to other parts of the organisation.
“We do them for every project, because even the most successful projects have mistakes in them and things you could do better next time,” he said. “Learn from it and catalogue the learning.
“Create a shared depository for your whole company. Put all of them into that place, so everyone can learn from everyone else.
“Now, essentially, you’re putting your team’s laundry out for display, but it helps create a [supportive] culture if everyone’s willing to do that and lets you learn from others as well.”
The importance of knowing what customers want from the products DevOps teams create, and ensuring their views are factored into every stage of development, was touched on elsewhere during Goldsmith’s talk.
He used the introduction of Clippy, the much-maligned, paper clip-shaped animated character Microsoft introduced to help users complete tasks in Office in the mid-to-late 1990s. The feature was two years in the making, but it was only once Clippy was unleashed on the Microsoft Office-using masses that the company realised how much users did not like using it.
“Microsoft stopped shipping it a long time ago, but you know it because this is a failure that was so massive it crossed out of our industry and became part of popular culture,” said Goldsmith.
“But it wasn’t because the team was bad, it wasn’t because the technology was bad, it was because they couldn’t figure out that they were going to get it wrong because of the way we wrote software then.”
With the emphasis in modern software development on iterative improvements, delivered by cross-functional teams who use end-user feedback to inform every stage of the design, a misstep like Clippy should not happen again, he said.
“It is a totally different world. You can ship your website every time you hit ‘save’ in your editor if you really want to do it that way. You can ship your Android app every day. You can ship your iOS app multiple times a month.
“You can get your ideas to your customers extremely fast – much faster than we used to, so there’s no real excuse any more to wait and have this big failure rate.”