Category Archives: technology

What Does Your Team Need? Girl Power!

By Hillary Johnson

Last weekend, Chris and I attended a marvelous event called Dare 2B Digital, aimed at addressing the gender gap in computer science careers, and at which 7th through 10th grade girls got to play at writing code, crafting business plans, and other techie things.

We held a session called "Teamstorming," leading a group of enthusiastic students in a series of the same learning games we use to teach teams of software developers on big, important enterprise projects to work together collaboratively.

We were completely blown away. The girls weren't just good: they were great. This was the most quick-witted, productive, outgoing and naturally cooperative group of individuals we've ever had the pleasure of teaching, by a significant margin. Chris and I have both mentioned to several people now our experience of finding the teenaged girls smarter, stronger, faster and sharper than their elders of any gender, and have heard a few theories about why this might be, the top three being:

They are unspoiled.
They are female.
They are female and unspoiled.

We laughed, too. But each of these notions has some merit. First, there is the unsullied youth theory: It seems patently obvious that many adults have a great deal of wariness, and weariness, to overcome before they are open to participating freely in a game-based exercise. Our teaching style is based entirely around games and simulations, and the younger a student is, the closer she is to the memory of learning almost entirely though play. It is not, however, particularly true that children are born collaborators, as any parent whose pre-school has a biter enrolled can tell you.

As for the gender question: Are females, by nature or nurture, better collaborators and problem solvers than males? To whatever extent our temperaments are deterministic, my hunch is that girls would respond better to the collaborative exercises, and the boys to the competitive ones. There is research-based evidence that there are gender-based differences in learning styles, but the same research indicates that the variation between individuals is greater than the variation between the genders.

So yes, the girls may benefit from being both female and unspoiled, but this doesn't mean they are superior to the male and the spoiled, it just means they're naturally suited to collaboration and have nothing to unlearn as they encounter collaborative situations.

But by adulthood, we are all engaged in activities that may or may not speak to our true natures. Girls don't tend to play with toy cars, but they grow up to drive real cars in the same numbers as men. And if you believe insurance companies' actuarial tables, they grow up to be the better drivers. On the flip side, I think this means that boys can grow up to be fine collaborators, as good as or better than their female counterparts, despite their greater inclination toward competitive styles.

I am not a big fan of determinism. Things do come out in the wash, and in the long run, even unlearning can be a productive process. As Chris will tell you, part of the reason he values Agile so much is that teamwork and collaboration do not always come naturally to him–he was once a boy who played with cars, after all. He has enjoyed being in a traditional leadership role, and can remember exactly what it was like to resist the urge to "help" a team, instead letting them solve their own problems through self-organization. Which is why he is good at teaching Agile techniques, especially to people who have a lot of un-learning of traditional top-down management styles to do.

The clear outcome, to me, is that the gender bias in the field of software development that persists today is entirely bogus. If boys have an edge when it comes to math–hence their delight in code–and girls have an edge when it comes to collaboration, then it seems stupefyingly clear to me that you're most likely to have a high-functioning team if you have both styles well represented, with plenty of room allowed for something even more important: individuality.

Share it!

What I learned at Startup Weekend SF: Agility is the state of nature

What's a good mother/son spring break activity? Why, going to Startup Weekend and spending 50 hours building a company with ten total strangers. Perfect because my 17 year-old vastly prefers the company of adults to that of other teenagers, and because he's been on the high school treadmill for so long that I thought it would be nice for him to see what the light at the end of the tunnel might look like–that the world of work can be a rather thrilling place.

Several years ago, I visited the very first Y Combinator class of college-age founders when they were only six weeks into their startups and was astounded at the number of fully functioning products. Turns out six weeks is an eternity, way more time than you need to build and launch a startup!

This weekend, 150 of us crammed into a giant room in Microsoft's Market St. facilities. We were given lots of food (thanks to Sana of Women 2.0) and very little direction. After a free-form round of idea-pitching, with coaching from the lovably dyspeptic Dave McClure (our team-member Han Pham describes his style here), we were cut loose to self-organize into teams.

Tyrone and I were interested in Connor Lee's idea for a venue-rating site for event planners (easy to build in a weekend), and Julian Bryant’s pitch for a site that would allow people to interact around pending legislation. As it turned out, Connor, who had legislative experience Tyrone and I all joined Julian, along with developers Marcus Phillips and Philipp Pfeiffenberger, SEO/Social Media/Web Marketer Aris Vlasakakis, marketing gurus Sherbeam Wright and Mariam Ishpahani, journalist Han and a couple of others who came and went over the weekend. Julian emerged as the natural leader, as well he should being a former Senate intern and Georgetown Law grad with a startup around language learning.

I have worked as an employee or long term contractor on three tech startups, one VC funded, one angel funded, and one bootstrapped. This team outshone them all in terms of raw talent, intellectual horsepower, organization, distribution of skillsets, commitment and efficiency. And we were not alone. In all, 23 teams had working demos or prototypes to share on Sunday evening, and a couple had actually launched fully functioning products (I was using Snoozemail in my gmail inbox before the evening was out). There could be no better demonstration of the power of self-organizing teams than this display of exponential creativity and productivity.

Marcus and Philipp–both Y Combinator alumni if I'm not mistaken–were curious about Agile, and we talked about it a little bit, but there really wasn't time to talk about anything but pushing our product out the door. What I found enlightening was that their native values, instincts and practices were inherently Agile. Being Web 2.0 guys who work in Ruby and Python, they have never been exposed to Waterfall. (The only team that did anything resembling a Waterfall process was the one team that had absolutely nothing to show on Sunday, having spent all their time creating specs.)

This makes me think that perhaps the best way to promote Agile is to take a cue from crime prevention and literacy drives: don't focus on reforming those who have already been "lost" to Waterfall methods; focus instead on preventing the destruction of our talent pool in the first place!

Our team, christened "Democlarity," divided rather quickly into two right-sized sub-teams (also quite Agile). Tyrone went with the bus dev side, working on business planning, market research and content creation, while I went with the development side–the first time I've ever worked on a project and not been the writer/editor. I did some HTML wireframing, then turned my attention to CSS styling while the devs blasted in the functionality.

We had technical difficulties here and there–the wifi broke, version control broke, my host account where I was hosting images while designing went down at a critical point. Marcus and I paired on merging the disparate html files, then Philipp and I paired on some last minute CSS (he is 10x faster than I am, so my main contribution was saying things like, "Can you make that greener?").

Everything  got done, and Aris and Marcus had time to practice their demo pitch. We weren't live online, but we were certainly way too cool for powerpoint, and were able to show a site with functionality and an amazing amount of depth.

Aris and Marcus rocked the demo, with Phllip driving the mouse so they wouldn't have to break their patter, and we disbanded feeling like we'd accomplished something fairly spectacular and been a part of something pretty important. The Democlarity team is looking forward to a reunion in a month, and plan to continue developing what we started in an open source-ish sort of way. In the meantime, a demo of our site should be up on www.democlarity.com fairly soon.

Tyrone went back to swim team practice today, and I'm back at work too. But I learned more about teams and teamwork this weekend than I did in the previous year–and that's a year in which I wrote an Agile training manual and helped organize the Orlando Scrum Gathering's Open Space Conference. I'd highly recommend the startup weekend experience for anyone who is seriously committed to working on or with software teams–the pressure of an insane deadline like that compels you to strip everything down to the purest, simplest form: communication, decision making, work flow, product features, everything, and conversely, it also leads one to discover the enormity of one's own personal resources. We were like those people who, in a crisis, lift a car off of a person. Heady, empowering stuff.

This weekend was Startup Weekend World, with 50 cities participating. There will be another soon enough. Hope to see you there!

Share it!

.NOT

I occasionally still get calls to do software development. Recently, a potential client indicated that they would like a Windows shell extension created in C#. I’ve never built a shell extension, nor done any C#. Before meeting with the client, I decided I should take an hour or two to see how hard it would be for an old-school C++ and COM guy like me to get up to speed.

I downloaded the ‘Express’ version of C# and started playing with it. Pretty quickly, I had a command line app that worked like Eliza, but got the response text from Google searches. Fun!

Next I searched MSDN for information on using C# to create shell extensions. I found this article, which starts out like this:

This article illustrates the process of creating custom shell namespace extensions using C# and the .NET Framework. The author dispels some myths about the difficulty of writing such extensions, and shows that it is easier than it was before .NET.

Sounds good!

Until you get to here:

Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario.

Doh!

Reading up a bit more it seems that COM, not .NET is really the right technology to use. It’s nice to see that my C++ and COM skills aren’t obsolete yet.

Share it!

Paper Prototyping

LinkedIn has a cool feature that let’s you ask a question of your whole network. This morning, someone in my network asked this question:

Tools for visualising interactive prototypes? What do you prefer?

Powerpoint, ConceptDraw, Omnigraffle, Flash, Ruby on Rails?

We are reviewing the tools we are using to help visualise interactive storyboards and concepts for our clients. What are other people using? How important is it that the tool supports experimenting with real data and conditional branching in order to explore with the development team the consequences of their design decisions?

My reply:

Consider Paper Prototyping.

It is low cost, easy to do, and will quickly teach you how a real user will react to the system. With a paper prototype, a human acts as the computer, so your prototype can support some very sophisticated logic without the need to create code. Modifications are trivial, encouraging experimentation, discovery and improvement. I was skeptical at first, but after using it a few times I have become impressed with the power of this tool.

Photo courtesy of
Nertzy

Share it!