The Society of Rugged Developers podcast focuses on how software developers can participate in the rugged software project. Co-hosts Matt Konda, Lance Vaughn and James Wickett discuss and define the “rugged” term and philosophy.
We are hunting for rugged truths. This is a pragmatic journey for practitioners. We invite you to join us on our journey!
August 26, 2014 – 13th Episode
Rugged Software Attributes Overview
Podcast Episodes:
Episode 13 – Featuring Ken Johnson, Chief Technology Officer at nVisium, Computer Network Security
Episode 12 – Featuring J. Wolfgang Goerlich, VP, Consulting Services at Viopoint, Inc.
Episode 11 – Intrusion Detection and How It Fits Into Rugged, Featuring Matt Johansen, Manager of Threat Research Center at WhiteHat Security.
Episode 9 Features Matt Konda, one of the well known and highly respected consultants heavily involved in Agile Software Security and the rugged movement.
Episode 8 – Features Wendy Nather, who is one of the well known and highly respected individuals heavily involved in the rugged movement.
Episode 7 – Discussion with Josh Corman, who was one of the founders of the rugged movement and a co-author of the Rugged Manifesto. Josh discuses a variety of initiatives in which he is engaged.
Episode 6 – Failure and Transparency as a component of Rugged “You can’t defend against what you can’t detect.”
Episode 5 – Featuring Jeff Williams, co-author of the Rugged Manifesto.
Episode 4 – Rugged Attributes as it applies to industries other than software development. Twitter account @RuggedDev announced.
Episode 3 – Explore examples of natural ruggedness as described in the Rugged Handbook.
Episode 2 – Hosts James Wickett and Lance Vaughn describe the rugged developer as open, transparent, collaborative, and seeks to learn from others.
Episode 1 – Hosts James Wickett and Lance Vaughn introduce the Society of Rugged Developers, and begin exploring how to define “Rugged Software.”
Society of Rugged Developers 
Is it valid to suggest that from a Rugged perspective, we should say that All Software is Security Software? Meaning that, because of the interconnectivity of everything, every piece of software will either help, or hinder security. If a product has security holes, it undermines security, but if it is as secure as one could make it, it stands as a bulwark against incursion, and is therefore no different than an IPS or firewall. It also signals the cultural aspect regarding the responsibility of programmers; that their software could be used against us (if we use it) or against the firm who deploys it. And no one would want to be the person who allowed that. (Hopefully).
This comment is in regard to how one rolls out the concepts of Rugged. It is not specific advice but I want to draw on an experience that may suggest possibilities. Years ago my firm had implemented Lotus Sametime as a chat feature. The technology group had just relocated a far distance from our user base and we needed ways to foster communication. As I showed instant messaging to most technologists, the overwhelming response was “why would I need that?” Undaunted, I continued to show it to people, but it wasn’t until I showed it to the Administrative Assistants did I hit paydirt. They realized they could reach out and get to people who were logged in, whether they were at their desks or in a remote location. I never had to show it to anyone else after that. They told the people in their groups they had to be on it so they could be reached in the event their managers wanted them. It took off.
The lesson is that an idea explained to the right person can have a profound impact; explained to the wrong people, and it falls flat. Finding the people or person for whom Rugged would be a personal thing is a possible lesson. That might be a business owner whose software was compromised, or a CEO whose company breach was a public event. Because Rugged isn’t about security only, but about software being “rugged” in the vernacular sense, business owners would probably respond to the idea that their software should be rugged. And given what Rugged (capital “R”) wants software to do, and the people who write it to do, it would be hard to believe that any user would want software that was not Rugged. They often do not know to include security and rugged characteristics into requirements because they assume that no one would ever build something that was flimsy and insecure. Selling Rugged to business owners is telling them they need to be specific when expressing their user “requirements” that the software must be as bulletproof as one can make it.Their only surprise may be that they are being asked to actually specify it. But when you detail how they should specify Rugged (with the manifesto, written as requirements), and that they can also specify that if there is any failure, that they as users require that the team join together to understand what happened and disseminate their findings to avoid that problem from recurring, or to alert others to check for the same defect. Technologists may push back, claiming that it will add to the cost. But I suspect the users will look at them like they arrived from Pluto. It would be like arguing that you want to build flimsy software and that if it fails you have no intention of taking responsibility for it. That perspective will probably not last long and a cultural revolution may have begun. Maybe. But maybe is good enough for now,no?
Thank you for your comments, Perry. Like you, I believe all software must be secure and reliable and maintainable or it is quite simply bad software. More than just standing up to the course of time, good (rugged) software will resist penetration, manipulation and misuse. Unfortunately, our world will always be littered with bad software just as it is littered with cheap (inexpensive and poorly made) toys. I like your comment about responsibility. At the end of the day, this all comes down to a personal and organizational sense of responsibility and commitment to quality.
I believe I have an approach to create accountability. Here is the situation: Security considerations compete with economic considerations. Security programming issues are arcane and difficult to explain to executives and it may account for there not being enough emphasis on training to code securely. What needs to happen is to flip this on its head. The recent Heartbleed event may be the model. Jaimie Hoyle and Filippo Valsorda produced a plug-in that warned people away from sites not remediated for Chromebleed. A similar plug-in is needed for the current 25 identified vulnerabilities thought to be the most egregious errors since they were discovered long ago, and their solutions are known. Imagine if a commercial website were marked as a danger because of one of these vulnerabilities. It would change the entire economics of security on its head. Executives would demand that programmers were trained, software was tested and patch cycles shortened. Year-end lock downs to protect revenue would be unlocked very quickly if a site suddenly appeared behind police lines that told everyone to stay away. Verizon’s recent report stated that executives think poorly of security people. I believe because they are seen merely as an impediment to commerce. Imagine if commerce could not occur without them. How things would be different.