Rusty Divine

Live, Love, Learn, Teach

OWASP - Lincoln

Interested in learning more about making your software secure?


Drop me a line if you’d like to be invited to an OWASP meeting in Lincoln early next year.


OWASP is a global community that drives the visibility and evolution in the safety and security of the world’s software.


Rob Temple leads the Omaha chapter of OWASP and we would like to explore the interest level in Lincoln by coordinating a lunch-time meeting early in 2014.


Some example meetings topics from the Omaha chapter:

•Thu Jun 6, 2013 - Web Application Security - So many tools, so little time

•Thu Sep 12, 2013 - The OWASP Way: Understanding the OWASP Vision and the Top Ten

•Thu Dec 5, 2013 - Advanced Mobile Penetration Testing

Try, then Ask Rule

Matt’s “You Must Try, and then You Must Ask” rule reminds me of why I love working on a team.

I have worked remotely before, for a stretch of 4 years, and not only was I working from my house, but I was the only developer on a project most of the time. I also have good friends who are doing well as sole proprietors in software consultancy and have considered whether I should follow their lead.

I know I could do it again, but I would prefer not to. I enjoy talking with my team and having someone around to jolly me out of a funk. Learning is accelerated by seeing how my other team mates are structuring their code and talking about what frameworks they are interested in. Not being the only person on the hook if a deadline is missed or a customer is unhappy is an incredible relief.

At work, we’ve often repeated the mantra that if you get stuck, make sure to ask someone. We have a stand up each day that should bring anything seriously blocking to light – it forces us to be accountable to each other. What I really like about Matt’s post though is that he has dug deeper than the surface to give some solid advice:

  1. If you’ve hit a point of giving up, give it another 15 minutes.
  2. During those 15 minutes, you must document everything you’re doing so that you can tell someone else.
  3. After that, you must ask someone for help.

I like that the second step is to document what you need to do to explain it clearly. Often, I get wrapped up in something I didn’t expect and just confuse myself. When I call someone over to explain it, I end up figuring out the problem myself just by talking through it logically – so, this step can often save my team’s time because often it will be enough to solve the problem.

Disc Golf App’s Base Stories

We’ve created 20 user stories for our Disc Golf App, some of which will need to be broken down into smaller stories.

We’ve agreed that the solution should be a mobile website instead of an app. I need to do another post to justify this more, but in a nutshell: app stores take 30% of what you make and cost $100/year to keep open, and a large percentage of the proceeds go to a small percentage of very successful developers, and developing once and working everywhere is sometimes possible with tools like Phonegap, but maybe you should just learn objective C, etc.

We’re working on Iteration 0, which includes loading the product backlog, deciding on an architecture (Now researching SPA with Breeze, Angular, WebAPI on Azure), and doing some mockups (Balsamiq). I’ve even done a few Lean Canvas plans, which helped me think about the app from different angles.

The duration of Iteration 0 is open-ended at this point, but we’ve agreed to each put in 4 hours/week.

We’ll need to do some prioritizing of the backlog, which we’ve done conversationally, and then point some of it so that we can fill out Iteration 1. We’ll probably time box the iterations, but will need to discuss how long they should be. We’re used to spending about 60-70 hours between us on an iteration, which would be something like 9 weeks at our hobby pace – so maybe we’ll cut that in half and do one iteration per month. We’ll need to figure out our velocity, but having worked together on many projects before, that should be pretty smooth.


I recently changed jobs. The upside is that I am really enjoying the team I am working with and the project we’re working on. The downside is that I no longer work with my good friend Adam.

Today, I am happy to say, we have decided to embark on a side project so that we can continue to work together. Of a list of 15 or so ideas, we came back to the one idea we each separately had when we started working together a year ago – a Disc Golf app.


It’s funny that when thinking about a project done on my own time, my first tendency is to disregard any formal process and just git ‘er done. Why waste time on user stories and mockups – I know what I want, right? Do we need iterations, daily stand ups, and burn down charts?

Back at our former employer, we honed our process for gathering requirements and prioritizing them. We called this an Agile Assessment. For a nominal fee – enough to discourage anyone who wasn’t serious, but not enough to actually break even – we would meet with all the stakeholders we could in one 4-hour meeting. First, we’d lay out the agenda and ground rules. We’d then spend about 20 minutes to define a project objective that could be concisely written on our wall board. From there, we discussed some of the obvious users, and then started brainstorming features and recording them in the form of user stories with a title and conditions of acceptance listed for each one. Each of the titles would go onto a yellow sticky note, and the rest of the story would be recorded in a spreadsheet. When we had 20 minutes remaining, we’d ask all the stakeholders to take the sticky notes and order them from gotta-have to would-be-nice. After agreeing on the order, they would draw a line to separate what had to be there to make the most basic solution from the rest – everything above that line was in our Core Feature Set. Adam and I would then spend a fair amount of time researching and designing the solution (30-40 hours) and present the customer with a set of design documents and a fixed-price quote for the solution.

When we won a project, we broke it into two-week iterations and managed the stories and burn down using TFS. Each day we’d have a 5-10min discussion of the project and include the product owner via a phone call. There was a daily burn down chart emailed out to the team, and at the end of each iteration a demonstration of production-ready code was shared with the customer followed by a retrospective that drove continual improvement of our process.

We learned to love running projects this way and saw how product quality and team communication improved.

Going Forward

How much of this process should we bring forward into our side project? I don’t think we’ll be doing daily meetings – we both have young children and will be doing very well to spend 8 hours a week on this project. Having a product backlog and burn down seem like a good idea to me, but having a time-boxed iteration will need to be tested. We’ll need to find a new process that works for us, so we should definitely keep a periodic retro schedule.

Why are we doing this project? We both enjoy Disc Golf and we both enjoy learning and working together. This project will give us the chance to try some new technologies and approaches, and keep us interested in learning.

What’s next? My next step will be to look into opening up an account with Team Foundation Service to see if we can use an environment that we’re both accustomed to. We’ll create a product backlog and plan out our first iteration. Who knows where it will take us!