Sarah Allen’s reflections on internet software and other topics

Kent Beck updates the agile manifesto for startups and for what has been learned over the past ten years at at Startup Lessons Learned Conference.

Agile Manifesto

10 years ago the agile manifesto was a step forward, but it was a least common denominator of the people at the meeting.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Individuals and interactions over processes and tools

There was a day when people thought that if you had the right processes and tools, you could get any monkey to build the software, and it would come out exactly the same. As it turns out that is true. However, people matter. “Individuals and interactions” make a difference in creating the right software. However, valuing “individuals and Interactions” optimize the performance of the individual. Team vision and discipline is a more effective value. It’s not how good a job I can do, but how good a job we are doing.

Working software over comprehensive documentation

People used to believe you didn’t have to talk to people, you just had to open a book and read about it, but the docs were always incomplete and often out of date. Documentation is not as good as having working software, but the goal should be validated learning, which often doesn’t actually require any software at all. In a startup environment, it is not that you don’t know how to write the software — you can’t measure success by working software. In a startup, you start out with “almost impossible assumptions.” It is always the crazy ideas that work out that are the highest values. To succeed, you have to find out which ideas are really impossible and which ones will work out. Working software is a way to answer those questions, but it is better to create a way to learn before you have working software.

Customer collaboration over contract negotiation

Customer collaboration was a big step forward, but in a startup you don’t yet have customers, so what do you do? Focus on customer discovery.

Responding to change over following a plan

Old adage: “Plan the work. Work the Plan” Responding to change was a big step forward. It was not enough to follow the plan because things change too much. However, in a startup nothing is changing yet because nothing is moving yet. You need to create momentum. You need to focus on initiating change. If you don’t initiate change in a startup, you aren’t going anywhere… you need to be moving.

Lean Startup Manifesto

• Team vision and discipline
• Validate learning
• Discover Cusotmers
• Initiate change

The process “build -> measure -> learn” instead should be:

learn -> measure -> build.

I enjoyed watching this video interview of Eric Ries talking about “lean startup methodology.” It sounds a lot like agile development to me.

“a failure of an idea doesn’t mean the failure of the company”

I’m honored to receive am IMVU scholarship to Friday’s Startup Lessons Learned Conference. I am excited to spend time with a group of entrepreneurs who are pursuing (or at least interested in) this methodology. I have been hearing bit and pieces of this, but only recently did I realize how aligned it is with my own practice.

I am experienced in agile development methodologies and have been working to apply similar lessons to business development for both my consulting company, Blazing Cloud, which pays the rent, and my startup company, Mightyverse, which aspires to change the world by enabling cross-cultural and cross-language communication.

“The simplest thing that could possibly work” is a mantra of agile software development. Applied to my consulting business, I have deferred many of the trappings of a business until it was painful not to have them. For a small consulting business, it is easier: my metric of success has been whether I net a profit on each job. Applied to Mightyverse, it’s more complex since we’re investing in product development for longer-term revenue growth (along with non-monetary goals). Deciding to release the website and the iPhone app before we had something that we considered a minimally viable product was a tough decision, but we made it because we recognized that we needed more than software to have a viable product. With the website and mobile app out in the world, we can start building a community of contributors before we have a complete solution for either direct participation or consumption.

The key element of agile or “lean” methodology is to understand why you are doing what you do. When you understand your motivations and how you expect your actions to lead to your desired outcome, it can lead to unexpected and counter-intuitive decisions that are nonetheless effective.

Over the past year I’ve taught about a dozen sessions of Ruby language or Ruby on Rails programming classes. I’ve been using a combination of presentation, live coding demonstration, follow along with irb (Ruby’s interactive scripting environment) and test-first teaching exercises. I’ve reflected on what works well and experimented with curriculum and teaching style modifications for the sections where students struggled. I’ve found a sequence which works very effectively. I believe it could be applied to teaching any programming language, and perhaps to teaching anything.

1. Conceptual Overview A presentation of the concept: why it is important, what it can do, how it works. How it fits into the bigger picture (if applicable). Pictures and diagrams are great here.
2. Experimentation (Play) My goal in this section is to create a feeling of play… at best, with grown-ups, I think I’ve achieved a sense of experimentation or, perhaps, what the Talent Code calls “deep practice”
3. Demonstration of a Real-World Example A live coding demonstration that solves a real problem. I often use this as an opportunity to test-drive the example, which illustrates the concept from two angles: the test (expectation) and implementation.
4. Simple hands-on exercise Test first teaching examples where the student is given a test that fails and they have to apply what they just learned to write code and make the test pass.

This was the context of my talk tonight at the East Bay Ruby Meetup. I talked about teaching methodologies, demonstrated a test-first exercise, then talked about moving on to test-driven development.

Slides posted:

One year ago today, I wrote about attending my first SF Ruby meetup, where I met Sarah Mei, the only other woman in attendance. I wrote then that I hoped someday “to attend a meetup where I don’t personally double the number of women.”

I am pleased that my hope has come to fruition: I don’t think I have been at another Ruby event since then when I was the only or one of two women. My very next Ruby event had 6 women (out of 200) with as low a percentage, but Sarah and I decided to make a difference by teaching Ruby on Rails to other women and ever since I’ve enjoyed the company of many strong, technical women in the Ruby community.

My other remark about gender, one year ago today, was that “the guys treated me as more of a geek than a girl.” With an occasional high profile exception, the guys in the Ruby community are pretty welcoming toward women. We’ve never had to work very hard to recruit volunteers to help with workshops. I’ve often remarked that my experience this past year in the Ruby community is dramatically different than my previous experience in my ability to create substantive change with my efforts.

For the past twenty years I have worked toward gender balance in the field of software development. I’ve worked to recruit and hire women where I work and spoken to women’s groups and sought to encourage younger women to pursue careers in software development. In the past, my male colleagues have always encouraged me and told me that they were impressed by what I was doing. I always appreciated that support. This past year, I noticed a differences. Guys would come up to me and say “how can I help?” Men I never met in person would email me and say “can I paypal you some money to support what you are doing?” It is a whole new world. This different attitude set the stage to train over 200 women in the SF Bay Area in Ruby on Rails in less than a year. Together we created an environment where more women how up to the geek meetups and more women give presentations and there are more events for all genders. In 2010 we have a new initiative to make the workshops self-sustaining.

I believe that a lot of what makes the difference in the Ruby community is that it is an open source community. People are used to just pitching in where help is needed. People are used to giving back to make thing happen. But most of all what makes the difference is individuals who are willing to step up, who are willing to take the time to do work behind the scenes, who will do small, meaningful or seemingly trivial bit of work to make things happen. You know who you are and you are awesome.

I am proud and honored to have been part of the SF Ruby community for the past year. I look forward to finding out what happens next!

For my talk at LA RubyConf, I decided to share some truths about mobile development, in general, rather than focusing only on how it is different with Ruby using the Rhomobile platform.

The truth is that mobile development sucks. With Ruby, sometimes it sucks less. The unavoidable problem is that at the end of the process you still need to get your app on the device using cruddy development tools reminiscent of the 1990s. I likened mobile developers to people who like to get tattooed. Perhaps some are thrilled by the painful process, but most endure it to achieve the end effect. Mobile applications are compelling, wonderful expressions of some practical problem solved that you can carry around in your pocket. Despite the often frustrating and stupid steps that I need to follow to get things done, I love what I can build as a mobile developer.

Rhomobile is steadily normalizing some of the process to smooth out the cross-platform differences using tools and techniques from Ruby, which I discussed at the end. My talk reviewed the development process backwards, starting with the user experience, reviewing what it takes to distribute the app and build it for distribution, then finally reviewing the code (posted on github). I posted links to the app for iPhone and BlackBerry.

The key point on the user experience is that mobile apps should be different on each device, but those differences should be superficial. It is essential that your app use the common UI patterns that users of that device expect, but the core of your app has to do with the problem you are solving and that should be consistent across devices. For the RubyConf app, those device-specific differences were the navigation. On iPhone, there’s a tabbar across the bottom. On Android, there is also a tabbar that has a slightly different look and is positioned across the top. On BlackBerry, these navigation options appear in a menu. The user of each device would find the navigation expected, since it is consistent with how other apps look and feel on that device. Meanwhile, most of the screens are identical across the app. I didn’t discuss the map implementation which is almost the same across devices — of course, it always looks like a map with markers, but the markers have a different visual representation and the pan/zoom controls are different.

The other point about user experience, which is not expressed by the RubyConf app, since it is really a work-in-progress, is that your branding should be consistent across platforms. Mobile apps have more in common with web applications than they do with desktop applications. On the web, your brand is integrated into your application UI. I expect that to be the common pattern for mobile applications as well.

The process of building, signing and distributing the app is quite different cross-platform. It is really hard without actually doing it to get a feel for what it takes and how long it takes to do this on each platform. The documentation is scattered and hard to follow even for a single vendor. One of the goals of my upcoming book is to pull together this information and help people understand what is common across platforms and what is consistent. In this talk, I gave a lightning-speed overview of the process on iPhone, BlackBerry and Android.

The slides for the talk don’t really stand alone, but I am posting them here for reference: