Comments (0)

By Mark Curphey, September 6, 2010

This post is #8 in a series 10 Crazy Ideas That Might Just Change the State of the Security Industry.

When Jason Fried of 37 Signals spoke at Web 2.0, most for the media picked up on a great meme proposing that web site owners should think of themselves as software curators. Instead of trying to pack in as many features as possible, it’s is the ‘collection’ of features that create an experience and what ultimately matters. During the talk he spoke about design driven software and used a few great analogies, one using a clear water bottle to explain why it’s easy to assess the quality of the design of a physical objects and then went on to discuss why software is so relatively hard. I recommend the video here and a talk by Ryan Singer the 37 Signals UX person here.

End users of most software are simply confused about security warnings and therefore generally ignore them. Security features such as authentication systems are privacy settings are complex and in general seem to be designed by and for developers. FaceBook had 4,000 comments in a week for privacy features that it claimed already existed.

Most security software is also nothing more than a hodge-podge of every possible feature every possible security person can think other users might want want. Security people have long ridiculed the desire to have a “shiny red security button” including myself many many times. The truth is that security is way too complicated for the majority of people and it has to be made easy. That wil only come by embracing Design Driven Security.

Comments (0)

By Mark Curphey, September 6, 2010

A simply great quote from Jeff Bezos read on Six Pixels of Separation Blog

“Before if you were making a product, the right business strategy was to put 70% of your attention, energy, and dollars into shouting about a product, and 30% into making a great product. So you could win with a mediocre product, if you were a good enough marketer. That is getting harder to do. The balance of power is shifting toward consumers and away from companies…the individual is empowered… The right way to respond to this if you are a company is to put the vast majority of your energy, attention and dollars into building a great product or service and put a smaller amount into shouting about it, marketing it. If I build a great product or service, my customers will tell each other.”

Comments (0)

By Mark Curphey, March 29, 2010

I used to always tell a story about Horatio Hornblower at security conferences. As the story goes one night at sea, Horatio awakens to find that a ship is in his sea-lane about 20 miles away and refuses to move.  Horatio commands the other ship to move starboard, 20 degrees at once.  The other ship refuses and tells Horatio that he should move his ship starboard, 20 degrees at once.  Next, Horatio tries to pull rank and size on the other ship, stating that he’s a captain and that he’s on a large battle ship.  The other ship replies, and it turns out it’s not actually a ship, but a lighthouse (the excerpt above was Taken from  JD Meier’s blog). I would deliver the punch line; 

“If this is how people communicate about matters of life and death how can we ever expect people to communicate clearly about good security requirements?” 

Of course security requirements are no different from any software requirements. If this is how people communicate about matters of life and death how can we ever expect people to communicate clearly about software design?. Today I attended an internal leadership conference at Microsoft and was lucky enough to stumble into a session by Stephen Young from Insight called “MicroInequities: The Power of Small”. The session was about how body language, intonation and cultural context can completely change a message despite the written words being the same. As well as providing pragmatic people management techniques the session was a great validation that software development requires face-to-face interactions. The demonstration that really re-ignited the lightbulb for me was this; the presenter put up the phrase “I didn’t say that she stole the book” and then using body language and intonation changed the meaning of the sentence completely no less than seven times. Each time the meaning of the sentence completely changed and each time the audience listening knew exactly what the presenter was saying. You have seen this all the time at work, (‘“I” didn’t say she stole the book’ meaning it wasn’t me that said it (although its true etc). Meaning is made up of a combination of words, intonation and body language. When we only communicate using voice or words (think conference calls or design documents) we loose around 80% of the meaning. That’s right, we loose 80% of the precision in the design or decisions we are trying to communicate. Some people try and compensate by creating thick documents or holding long meetings, the astute appreciate this just makes matters worse.

Summary

Software design is BETTER when presented and discussed face-to-face. It’s the meaning that matters and not the words!

Comments (1)

By Mark Curphey, March 27, 2010

A few weeks ago Marius (one of the PM’s on my security tools team) had the team participate in an exercise that he in turn had participated in at the NW Agile Conference back in February. It was such a powerful experience that I wanted to share both the exercise and the results.

Material Needed:

1. A large pile of plain letter sized white paper (allow around 50 sheets per person to be safe)

2. A pen for each participant (any pens are fine)

3. A set of small stickers (something like these are fine)

4. Something to time the exercise such as a stop watch or the software standard “kitchen-timer” (must be able to time in seconds)

The exercise is based around the team creating greetings cards from materials provided and runs in two parts. There is no need to explicitly tell the participants that the first part is a waterfall model and the second part agile although it is not a secret and soon becomes obvious.

Instructions are read to the group by the facilitator that are something along the lines of this (note: the details of the actions are important).

“We are going to produce greetings cards. The aim is to earn as much value as possible by producing as many cards as possible as a team in 2 mins. You will get one point for each card that is completed and shipped on time and on quality. We are actually going to do this twice, a little differently the second time but let me explain the rules for the first time around now. To produce each card you fold the paper in two. With the fold on the left you then draw a face exactly the same as the example [note: having an example card to reference is a very good idea] on the cover.

Open the card and on the right hand sheet write “Greetings from the software developers”. Turn the card over and in the top right hand corner with the fold facing upwards apply a sticker to represent a stamp. When the card is complete you place it in the middle of the table with the stamp facing skywards and to the right. This represents shipping a card. For each card shipped you will earn the team one point. The first time we are going to do this you must complete this exercise by first folding all of your cards, then completing all of the covers, then complete all of the inscriptions and then add the stamps and then shipping them….OK before we start production I need you all to estimate how many cards you will produce.”

Go around the group getting an estimate of how many cards they will produce and give each team member enough supplies to complete what they have estimated. Ensure there is a central place to get more supplies if needed.

Note: We had estimations ranging from 2 cards to 25 cards.

Count and note the number of total cards estimated and run the exercise timing the production run and providing a time check to the team every 30 seconds. Whilst it is running be sure to ensure people are playing by the rules and not taking short cuts. People get excited!

At the end of the first run take time to stop and discuss as a group what has happened. What is likely to have happened is this.

1. Some will have under-estimated significantly and been sat idle.

2. Some will have over-estimated significantly. As a result of a waterfall approach they will not have been able to complete any cards at all so not have shipped anything. For those that have over estimated and managed to ship be sure to check the quality. What normally happens is people will sacrifice quality to try and meet the initial (artificial) estimation.

In general there will be a lot of waste. Check the quality of all shippable cards and be sure to toss out any cares not meeting the quality bar. Pay attention to the side of the stamps, folds etc. Count the total number of points earned by the team and make a visible note to the team.

Now read the instructions for the second run.  They will be something like this;

“OK now we are going to do the same thing again but with some fundamental differences. Instead of doing the tasks sequentially we will use an agile approach and build a shippable card end-to-end before moving on to the next one. Fold the paper, complete the picture, complete the inscription, add the stamp and ship the card before moving on to the next one. Remember each shippable card earns a point.”

Before starting the clock for another two minutes get a new set of estimates from people. OK, go! After one minute stop the team (make sure they put down the materials) and announce a slight update to the rules. Instead of a straight line for the mouth you announce that requirements have changed and that the customer now wants a smiley mouth in the shape of a curve. The good news is that cards with smiley mouths will now earn two points! Cards with straight line mounts continue to earn a single point. Start everyone off again and complete the exercise.

When the time is up everyone will all immediately know what has just happened and be eager to get the results. Make sure you are fair, examine the quality of all cards and make sure the ship rules were strictly applied.

So what will you likely find?

First up in the second exercise there will be little waste. The only waste will be a maximum of a single card per person! In our case we had 6 incomplete cards as opposed to 26 in the first exercise. You will also find that the teams have produced significantly more cards and therefore earned significantly more value in its own right. Given that around half of the cards in the second exercise will have been worth twice the value you will see a significant increase in value from the increased customer value as well as the number of cards produced. In our case we earned around * 25 points in the first method and around * 150 in the second method.

[* we got so excited that I didn’t record the actual results after I left the room]

Yes that’s correct; a six times increase in effectiveness by applying agile process. We produced more cards, created wasted less and earned significantly more value from the customer. The results were better than most had expected and certainly very clearly demonstrated. Even the protagonists on the team understood the power!

I am sure there are many variations on this game but as it stands I highly recommend it as an incredibly valuable and fun exercise to demonstrate the fact that Agile process can significantly improve the amount of value that a team can produce.

I hope you enjoy the exercise as much as we did!

Note: Remember there is a real difference between being effective and efficient. This exercise shows that Agile development works to improve efficiency and effectiveness.

Comments (2)

By Mark Curphey, March 26, 2010

This is a direct copy of an email sent to me by Marius Grigoriu. Marius is one of the PM’s on the Information Security Tools team. I think it’s so valuable I wanted to post it so I can refer to it.

A few of us attended a mini-seminar in Seattle yesterday. It was a pretty good event that introduced practices and tools to keep quality high at the beginning and throughout the whole project. I’m leaving tool specific elements out of this summary, but these are the takeaways:

We have seen from our card making activity that Agile avoids a lot of waste that inhibits a waterfall project. It is also generally accepted that due to Agile’s frequent releases, the team and customers have far more chances to learn and apply new knowledge about their project and software. Not only does an early deployment create feedback opportunities, but customers can begin obtaining benefits much sooner. Rather than waiting a long time for a bundle of features to be released, customers can take advantage of a feature from the moment it becomes ready. Thus the payback period of the project begins sooner, effectively moving the investment payback curve up and left.

To get frequent releases they must be small, and the benefits of small releases result in far less risk to the project. Smaller releases are easier to plan, easier to test, and bugs –even those found in production—are less expensive to find and fix. Integration and testing is no longer done at the very end of a project but now included as activities in every iteration. But testing at the end of an iteration creates similar problems to testing at the end of a project, just on a smaller level. How do you pull testing forward and bake quality in so that it becomes a continuous process?

1. Define acceptance criteria in your user stories.

It is not the sole responsibility of the PM to clarify the acceptance criteria. The team, and especially testers, help the PM obtain the level of detail and clarity with examples and specific tests to get the story to the level of detail where a team can build off of it. Now the team and customers have a set of tests           

2. Automated Unit Test

Unit tests are the foundation of automated tests. They isolate the system under test and of all kinds of tests have the lowest total cost of ownership. Automating tests may feel like a pain at the beginning of a project, but begin carrying their weight several sprints later once regressions become a risk, especially as the code base grows and team members change. Unit tests are primarily the responsibility of developers writing code.

3. Test Driven Development

Much of the value of unit tests erode when written after the fact. Bugs in unit tests are a problem since it is assumed that the test works when it runs. Writing unit tests on pre-existing code is difficult because the original intention of the code can only be interpreted and may not be test friendly. TDD is a practice that helps developers  write code that is testable and write tests that work.

4. Automated Acceptance Tests

When developers write unit tests, testers are free to find more complex issues. Acceptance criteria are known at the beginning of the iterations so testers can start right away. Testers collaborate with developers to ensure that acceptance tests turn green, rather than wait for a drop late in the cycle.

5. Continuous Integration

Integration is a large source of project risk and just as early and frequent testing and deployment reduces much risk, so does integration. CI has two sides: the practice where team members check-in, merge, and validate code at least daily, and the tooling which runs a build on every check-in, runs tests, and generates a report. If the build breaks or tests begin to fail, developers know within minutes, rather than hours, days, or longer. By prioritizing a working build over all else, the team does not build up technical debt that impairs adapting to change. Pay now, or pay later with compound interest.