Subscribe

Share

Architect

Stumble into Skills

There are lasting lessons from things you’d rather forget.

By Bob Rhubart

March/April 2016

What have you learned along the path to your current role as a software architect or senior developer? Information gathered in classrooms and from lectures, labs, and textbooks certainly guides you in your work. But the hands-on experience you’ve picked up along the way is the catalyst that turns theoretical knowledge into the practical actions you take on a daily basis. An honest assessment of that experience will almost certainly reveal a long trail of mistakes and corrections. Show me someone who has never screwed up on the job, and I’ll show you someone who has an incomplete education.

If people don’t understand what it is you’re trying to achieve for them, you’re going to fail. ”–Phil Wilkins,
Oracle ACE Associate

Given the complexity of software development and information technology, failure is everyone’s constant companion. Throw fatigue and other human frailties into the mix, and it’s a wonder that anything ever works. But the fact that projects are regularly and successfully put into production is proof that those responsible for developing software solutions pay attention when failure teaches its lessons.

Whether or not people are willing to share those lessons is another question. But after putting out a call to community members, I was pleasantly surprised that a few people had the moxie to own up to wisdom gained through failure.

Oracle ACE Andreas Chatziantoniou, an independent consultant specializing in Oracle Fusion Middleware, confesses to a bungle he puts in the “me and my big mouth” category. When asked by a customer to look into an Oracle WebLogic Server configuration issue, his response was heavy on bravado. “Been there, done that, got the T-shirt,” he assured the customer. But he forgot to ask one important question. On arriving at the customer site, he learned that his extensive experience dealing with Oracle WebLogic Server on Linux was useless because this instance ran on Microsoft Windows. “The whole system behaved differently than I expected,” he admits. “And I didn’t earn any credential points.”

While Chatziantoniou’s credentials took a hit because he overlooked an important technical detail, technical perfection is no guarantee of a successful solution.

“Regardless of how referenceable a solution is, how well executed the development, how great the quality metrics are, if people don’t understand what it is you’re trying to achieve for them, you’re going to fail,” says Oracle ACE Associate Phil Wilkins, enterprise integration architect at Specsavers.

Wilkins was once involved in the development of a monitoring solution that would allow the customer’s operations team to quickly identify and fix issues. “The ops team had the facts to be able to challenge the delivery organization about quality control issues,” says Wilkins. On a technical level the solution worked, perhaps too well. “The ops team had a culture of wanting to be heroes in the eyes of the business,” Wilkins continues. “Ultimately the ops team switched the monitoring solution off because they felt it was undermining them.” So while the monitoring solution fulfilled all the technical and functional requirements, it conflicted with the ops team’s culture. The time and effort wasted on an unused solution can be blamed directly on the failure to grasp that situation. Another lesson learned.

The next entry in this collection of mistakes and missteps comes from Oracle ACE Rolando Carrasco, principal service-oriented architecture (SOA) architect and co-owner of S&P Solutions. As of this writing, Carrasco is involved in an Oracle SOA Suite upgrade. Along the way Carrasco and his team made a few hasty decisions that resulted in minor delays and a few headaches, rather than outright failures. But the cumulative lesson learned from that experience resulted in an excellent suggestion: document your mistakes—and your efforts to correct them.

“It may sound like a simple recommendation, but not everybody does it,” Carrasco says. “Your documentation should include screenshots and short descriptions, along with references to any Oracle Support notes, blog posts, or other resources that helped in resolving the issues.”

Carrasco’s suggestion gets to the heart of the overall lesson. It’s one thing to trip up and fall on your face. You may want to forget it ever happened. But the truly epic fail is not learning from that mistake.

Tell your story of failure and redemption.

Next Steps

 Listen to the latest OTN ArchBeat Podcast.

 Watch the latest 2 Minute Tech Tip video.

 Register for the next OTN Virtual Technology Summit.

 READ the Oracle Technology Network ArchBeat blog.

 SUBSCRIBE to the Oracle Technology Network ArchBeat podcast series.

CONNECT
 Bob Rhubart's Blog
 Bob Rhubart on Facebook
 Bob Rhubart on Twitter
 Bob Rhubart on LinkedIn