NASA Science Case Study - Part II - Design and Development

Now that we had picked our technology, it was time to start in on the design.

The ideas! They burn!

One of the funny things about taking on a large project is you either have a group with no ideas at all, or way too many. We had the latter. As someone who was on the project from the beginning, it started to feel like we had a new idea for the look and feel of the site every week. We had dozens of comps and wireframes that all had things we liked, things we hated, or things that, well, we had no idea how we felt about them.

IA

Designs aside, we also had ideas for the content. SMD had a lot of information, and in order to make a site for them, we had to get our heads around what they did. One of the funny facts about NASA is that it is very good at talking to itself, but sometimes forget that it's audience includes people who are not astrophysicists. We used ourselves to play the ignorant public, reframing their information in ways that would make sense to an everyday user.

We got into information architecture in a big way.

The first question we asked was how information was usually presented, and could we do something new and cool? Normally, as kids, we're taught about the planets: size, location, color, maybe a feature or two. But what use was that? Winning questions on Jeopardy?

Instead, we chose to present data in the context of missions and questions. What were we doing, and why? Why bother to look into deep space? Are we doing it just for pretty pictures? Why send a satellite to look at Saturn, or a Rover to Mars? One of the edgier, early IA's had no traditional context, but had the site completely based off of missions and questions. Other IA's had the questions and missions, but still used some other more traditional groupings (Our Solar System! The Stars! Our Planet Earth!). A last one mimiced the internal structure of SMD (Earth, Sun, Planetary, Astro).

Usability

You'll notice we had a lot of questions at this point, and few answers. This is where usability stepped in.

We had all become so close to the IA's and designs that we couldn't see them without seeing the debates, the tweaks, the moments of irrational design by committees or bad ideas that snuck in because we were too tired to kill them on sight. We decided to do some usability testing.

We chose a few designs and a few IA's, then a couple dozen willing victims. The testing came in three parts:

1. Answering questions about a functional design
2. Attempting to complete tasks on a fake site
3. Evaluating several designs on various attributes, such as font and color usage, or look of professionalism or crediblity
4. A card sort, where they sorted similar information into categories and then labeled them
   

We got to watch in a dark little room behind one way glass, which, while cramped and a little muggy, was an excellent and sobering experience. You get to see the things you loved, the precious darlings of the designs, get ripped apart without sympathy. You get to watch your grandiose ideas that were going to revolutionize the web get frowned at and cast aside. It sounds painful, but really, it brought us all back down to earth. It also brought our customer, who was dead set on some design matters, to see the light.

The card sort also illuminated a lot of things for us. For one, people didn't want a strange new order for their information. They wanted planets grouped, things about the sun grouped, things about earth grouped. Every person came up with almost identical IA's of their own (something I duplicated at the last Plone conference).

We ended up picking the most popular design from the study, and going with an IA that mimicked SMD's internal structure. But wait, isn't that a bad idea? Usually, yes. However, SMD's internal structure mimics its science: Earth, Planetary, Sun, and Astrophysics. We simply lucked out, that way. This way, each division had a place to call home and exert their will, and users could still find their way around.

Train the designers

Now we had a design and a technology! All we had to do to get the two talking was to hand it over to the designers, right?

Well, not quite.

Our shop was mostly filled with Photoshop experts who knew little about the inner workings of CSS. Previously, they had created sites in various Adobe or Macromedia products, exported, then uploaded. This method wouldn't work with Plone. The CSS had to be tooled by hand, as did the HTML and javascript.

Boy, did they love us.

What we ended up doing was turning our designers into developers. They resisted at first, used to their cycle of design in Photoshop, export, upload, then move on to the next project. Instead of beating them with tools, however, we showed them the beauty of what we were giving them.

• Version control. How awesome is it to have every version of every image you've ever made at your fingertips?
• We got the site loaded on their machine. This way, they could make minor changes and see them right away
• SVN updates. They could update our machine! No emails necessary! It just happened!
• We taught them TAL, and showed them some cool tricks they could do, like styling things zebra-style, or hiding or showing things as they wanted

One of the most important things we did, however, was find ourselves a CSS guru by the name of Bill. He really cinched the design for us, translating the comp and our many ideas into one site. We love Bill. We'd hide bodies for him. If you have a design group like we had, get a guru as early as you can.

So, what were the developers doing?

Our philosophy in the early days was to have a different content type for every kind of item we were going to have in the site. So, we ended up with some crazy UML that looked like this:


We also spent a lot of time stressing about how we were going to handle getting slashdotted. Our customer (and some people on our contract) were unaware of the roaming DOS attacks known as Fark and Something Awful.

It was a hectic time for us all. A year of development, shifting requirements, and a schedule that we couldn't nail down lead to some crazy weekends and some seriously frayed spirits. We prepared more for that site than one does to prepare for a new baby (I know. The site development and my second pregnancy were parallel events). But finally, on [DATE], NASA Science 1.0 deployed, and the team just about fell over in a heap of tired developer and designer flesh.

Some details about what we had:

• 4 Zope Instances
• 1 Zeo Instance
• Varnish
• Apache
• LDAP
• Parts of many, many Products
• A few Products used in toto
• One monstrous custom Product
  

We were now in maintenance mode.

(Part I and Part III)

NASA Science Case Study - Part I - Why Plone?

Back in 2008, Pydanny and I presented at the Plone Conference in DC on NASA Science, the Science Mission Directorates' outreach site. In case you didn't know, we did it in Plone, and everyone seemed to want to know why and how. We decided to tell the world with a presentation, and not long after, were asked to write up a case study.

Dear god, Jon Stahl is one patient man. Finally, here it is.

Part I - Why Plone?

But first, some history!

The last time the SMD website had been updated, structure-wise, was back in 1999. While it had won awards for its design and content in the day, it was long overdue for a major overhaul.

The original site was 90% HTML with the occasional Perl script thrown in. There was no database backing it, save for a few 'mini-apps' that didn't talk to each other. Over time, the original look of the site gave way to dozens of mini-sites, each of which had a completely new look. Data had to be updated deep within the HTML, and god save the poor soul who had to do so without the original tool. I had to do it a few times, and the HTML those things churn out are NOT pretty.

The content needed some serious updating, and so did the look. The little black kid on the front page? He was from a stock photo, and by 2006, he was everywhere. Stock photos are evil. The overall style had aged poorly. The sub-sites confused users. And the search? Well, when you use Google rather than your own native search, you know you have a problem.

Selling a CMS

The first thing we had to sell was using a CMS for the site, rather than just doing another HTML monstrosity. Developers, of course, love CMS's, but the only way we could sell it was to show the customer what they would gain... and respect what they would lose.

What they gained:

• Sharing content: content could be shared between sites, pages, even applications
• Reuse of content: content could be used in more than one place, and even used to create more focused mini-sites if needed
• More complex interactions with data and display, like images that update automatically, or cool reports of data
• Easier to change the layout and look if we were using centralized templates and CSS

But what did they lose?

• Instant updates. As long as they had the same designer, they designer could run an update through their software and upload the site all over again. Even without it, it was just munging through bad HTML. Painful for us, but a short wait for them. Now, some updates could be done instantly, but others would have to wait for a release.
• Fast development. They saw a comp one day, a site the next! The magic of export! Now, they would have to sit through our development cycle
• Small team! Before they had a designer, maybe a content editor part time, and that was it! Now, they had a team of developers and a designer or two
  

We were fairly open about what they would lose, but they could see that what they gained far outpaced what they were losing. Whenever they had doubts, we pointed them back to the mess the old site had become, and how painful it was to update it, and impossible to redo.

So, we now had the okay to use a CMS. But which one? We had many sections to our contract's shop: .Net, ColdFusion, Java, and there was the Nasa.gov CMS...

Notice what was missing?

No official Python shop.

We had people who loved Python, and had used it on several projects, but we weren't grouped together. We wanted Plone from the start , but how did we make the case for it with no group to hand it off to? First, slay the other monsters.

HTML: Yes, there were still those that wanted to do the site in pure HTML and upload it.

Pros:

• Fast
• Small shop
• No dev cycle
  

Cons:

• No search! We'd have to make and tweak our own.
• No dynamic grouping or associating of data. No tags, no reports, no 'other things of interests' that wouldn't have to be done by hand

Cold Fusion: We had some eager ColdFusion developers. Why not use them?

Pros:

• They're already in house! No need for hiring!
• They wanted to do a CMS from scratch. That's always easier than learning something, right?

Cons:

• Writing a CMS from scratch is deceptively hard. It takes teams of people from all over the world to make ones that aren't too hard to learn, and actually adheres to a few standards out there
• The leading ColdFusion CMS at the time was Farcry, and it wasn't 508 compliant. Being 508 compliant (accessible to those with disabilities) is a must for any government site, so out it went
• Crufty URLs unless you do some serious Apache configuration
• What SMD had started to want was more modern than the current batch of CF apps had to offer

.Net: What about .Net? We had a .Net shop, after all. Why not use them?

Pros:

• Staff already on hand
• Sharepoint, a .Net CMS, already existed, and there was already some support for it at NASA for other sites

Cons:

• Our .Net shop was small, and already burdened with work
• Sharepoint is reportedly as complex as Plone when it comes to its innards, if not more so
• The designers I knew who worked with Sharepoint hated trying to customize its interface
• The final nail: the .Net developers were concerned about the scalability of Sharepoint

eTouch: NASA.gov uses a CMS. Why not use theirs?

Well, that one is actually a bit stickier. Though NASA.gov deployed first, the SMD site actually started development first. By the time NASA.gov and eTouch came about, we were almost through with development, and dealing with design changes.

Also, in the government, one must always be concerned with what pool of money work comes from. Though we all look like one big happy, people get very, very testy if you start taking from their honeypot.

Plone!

We settled on Plone as our driving technology. Why?

• We had a local resource in the form of the DC ZPUG. There, we could find people interested to work with us, pick brains, and get to hear a little about the trends of our chosen platform
• One of the older CMS's, it was extremely stable
• Active. Even though it was one of the older CMS's, it was definitely still being worked on
• We found it easy to use. One install, and we could already get it doing all sorts of things.
• It came to us 508 compliant, which saved us a LOT of time
• And a host of other reasons, which boiled down to the developers really, really wanting to do something big in Python, and in a shiney new CMS

The customers bought in, and we were on to actually making the site...

(Part II and Part III)

Why you should date a geek

Back at my last job, I was having lunch one day with two female co-workers with some men-trouble. One wanted to be married (and pronto), while the other had a talent finding nice guys who quickly morphed into scrubs. They'd bemoan their issues over our Lean Cuisines (another side-effect of man-issues).

I recommended dating a geek.

They scoffed. Why date a geek? These were Cosmo-reading girls who knew what their purses' brands were without looking, practically the opposite of 'geek.' How could a geek be their soul mate?

So I wrote up a list.

They can fix your computer

You know those snarky shirts and bumper stickers that say "No, I won't fix your computer"? Those apply to casual friends, co-workers, parents, grandparents, and mysterious cousins that come out of the woodwork when they can't get their cracked copy of Half-Life to run. In general, they do not apply to wives and girlfriends, unless your aura causes boot sectors to crumble. At that point, they'll likely just have you get a Mac.

They always come home

One thing that amazed me was the complaint of co-worker #2 about how her boyfriend at the time hadn't come home for three days. There had been no fight. There were no relationship issues (besides the glaringly obvious ones). This was apparently fairly common after a 'night out with the boys.'

Geeks will always come home. You have their stuff. Main computer, backup server, server that they blow to bits once every few weeks, laptop, Eee PC they toy with, XBox 360, Manga collection... They don't really travel light when it comes to their prized possessions. At the very least, even if things start to go south, they'll come home to sort it out and get to their things before you rev up the eBay account.

They like couple time

In general, though, you don't need to hold their stuff hostage in order to get them to come home. They like couple time! Every geek I've ever dated has liked having together time at the end of the day. Watching TV, playing video games, having dinner: all things they enjoy rather than endure so that they might get some sex later on.

Note: Sometimes geeks will want you to get into what they like. You need to be broken in easily. I recommend Star Trek: Voyager, the new Doctor Who, and some of the classic 80's fantasy movies.

They're incredibly loyal

Geeks will come to blows over their programming languages of choice. They will defend a poorly aging OS rife with flaws to their dying breath. They have fanatical devotion to their text editors.

What do you think they'll do when it comes to a lover?

They're all romantics

Look at every major sci-fi and fantasy film or book that's come out since the turn of the century. Almost every one of them has one thing in common:

Romance.

I'm not talking 'hot chick that the lead gets to bang at the end of the movie.' I'm talking real romance. Courtship. Long, flowing protestations of love. Pining after the love interest. Devotion. Most of the time, the lead doesn't even bang the girl during the movie, but it's implied they have a nice wedding and settle down properly.

It's not even a side story. It's usually the main focus of the story, or, at the very least, inexorably intertwined with the main story.

Many of them like kids

Sure, many of them complain about kids, but mostly, they're talking about the mall brats that orbit around oblivious parents and tear up everything in their path. Most geeks, when offered children who are not descended from the mongol hordes, take to kids rather fast. Geeks don't have a lot of shame when it comes to making a kid laugh. They're not going to worry if it makes them look 'un-cool.'

They'll also buy the kid stuff. Sure, it may be Cthullu dolls or weighted companion cubes, or big fuzzy twenty-sided dice, but it'll be stuff for the kid, and I bet the kid will love it.

One warning: Geeks breed geek children. The genes are strong. Keep that in mind.

So really, geeks are awesome to date. I've dated on both sides of the fence, and I've always reflected more positively on the geek side rather than the non-geek side.

This is all about guys! What about geek women!?

Geek women generally know their worth. We can be f'ing evil.

So guys: feel free to print this up and hand this out at the next occasion you're being forced to mingle. Maybe even make it into a keen iPhone app you can hand off, when you feel you need someone else to vouch for your virtues.

Katie reads so you don't have to! (Inmates are Running the Asylum)

In a new occasional series, I'll be covering some of the content of the books I read on usability and design principles. Why? Well, to start off, these are awesome books. You read them, and you start to rethink how you do your project plans and interfaces. They're full of gems that can be applied immediately.

They're also, well, books. How many of us have books on our bookshelf that we swear we're going to read when we have the time? How many of us have picked up a book, gotten a chapter or two in, then gotten distracted by the nearest shiny object like a new video game, a pesky deadline, or the need to eat?

These are not book reviews. There are reviews out there on these books. This is a post covering a particular gem in a book and my take on it.

Today, I want to talk about The Inmates are Running the Asylum by Alan Cooper. This is a book that is both very useful, and that many developers will likely hate. That's not because it's boring, full of manager-speak, or tries to be too cute. Developers, you would not like it because it has one pretense:

Don't let developers design your interface.

Once drilling that home, they talk about how to do interface design, and the tricks their company uses. My favorite so far? The Personna.

When you read through use cases, you often catch mentions of 'the user.' Exactly who that user is stretches infinitely. In one use case, the user is a rather savvy power user who doesn't mind five or ten steps to properly encrypt, upload, and check a file. Sometimes, the user is your gran, who finds computers terrifying and needs everything one click away. Sometimes, it's a designer wants every feature to have a clever icon rather than a text label.

This will not do.

Cooper, in his consulting business, constructs concrete personnas that will use their application. They have names. They like certain kinds of foods over others. They like to dress in certain ways. They have physical ailments. They have specific experiences with computers. They're stereotypes, but they're supposed to be. If you can make that personna happy, you can satisfy a huge chunk of your market.

Let's say I'm going to make a new application. I could just assume that everyone that will be using the software will be as snazzy as me, willing to learn interfaces in order to get software to do what I want it to do. I'm tricky enough to just make shortcuts to the parts of the application I really want, and ignore most of the keen navigation.

If only this software was just for me.

Realistically, this software is going to be used by people who are not computer geeks who can keep the interfaces of their favorite programs in their head. It will be used by secretaries or lit majors or computer haters. There may be some geeks, but you want to go after the lowest common denominator. Make them happy, make a LOT of people happy.

So you make a personna, and get into their head.

I get a request to make a new file sharing site (something I'm actually doing at the moment). All sorts of people are going to use this site, but I'm going to make a personna who is my lowest common denominator. If I can make him happy with my system, then I can make anyone happy with it.

Let's call him Bill, if only because I don't know any Bills personally at NASA.

Let's make Bill an Earth scientist. His job is to review proposals for new satellites from everywhere: companies, other sections of NASA, universities, think tanks. Two decades ago, when he started doing this, it was in the form of dead tree sent by post to HQ. He'd lock them in a cabinet, and when he wanted help reviewing them, he'd call a meeting and they'd all review them together. One copy. No one else saw them unless they could get in the building, find his office, find the filing cabinet in the mess of his office, and procure a key.

It was simple, and it was secure. There was no ambiguity.

Then came the damn internet.

Now, everyone wants to share things online. He tried email, but they couldn't keep the versions straight. Sometimes the files were too large. Sometimes, they were full of sensitive data that wasn't to go through unsecured lines. He's used the shared drive, but he can never tell who can see the files, and those outside of NASA certainly can't get to the shared drive.

We're making this app for him.

The first idea we had, to have lots of customization available, went out the window. Would Bill want to take tons of time to tweak folders at every level? Not likely. It would just frustrate him and have him using us at every turn to tweak and recheck the configurations.

So we went from having tons of customization to having a few stock options that could cover 90% of all requests. The last ten percent could be covered by experts.

The old system had admins making all the boxes. Would Bill want to wait? No. He never needed someone to set up his locked filing cabinet. He'd just make a new folder and put everything there. So we'd have to make it simple enough so that he could make the box on his own.

And as for who could access them, that had been easy. Whoever he gave a key to, or whoever he invited to his meetings could see the files. He knew who could add files (whoever had a key). So, we want to make this information readily apparent to him every time he uploads a file. Who can see the file, and what else they can do, is everywhere.

As a mental trick, I find that it's helping us streamline our designs. It takes some practice, but it keeps your apps from being a bucket of functions with nothing to hold them together, a thing that could only satisfy an elastic user.

Designers: Break your Design

Developers, as a rule, hate comps. Now, I appreciate the need for them. When a designer has to come up with a design, sometimes you need something to guide your vision. Something fast that moves as quickly as your idea. Photoshop works well for this. You can come up with a pretty design and tweak it into place in no time.

Developers just hate it when that's what's delivered to them to implement.

There's all kinds of reasons why, but I'm going to focus on one particular problem here:

Comps are perfect.

They're the perfect site. The perfect amount of text. The perfect number of features. The perfect images that in no way clash with your design, but instead bring out its subtleties. The titles are never too long, the captions are the right length, no long words are used, and no one has tried to pervert a feature to do something completely different.

Sure, if the content of a site were done completely by designers, I'm sure they'd be anal retentive about making sure the design was never broken by silly things like 'ugly feature image' or '1500 word article.' However, content is rarely handed over to designers. It's handed over to content editors who have suppliers who don't understand why they might have to choose a new picture or tighten up a press release. Who cares if it came from the press secretary?

Color schemes

You picked the perfect images for your comp. Now pick the worst. What is, reasonably, the worst image that could be put on the front page of your design? NASA is chock full of beautiful images. We also have some very, very boring images that pertain to amazing advances in technology and scientific knowledge. Anything to do with possible planets in other solar systems? Man. Hope you like monotone.

We also have images that are full of all sorts of colors. Nebulae have a way of picking some strange color palettes. Not very considerate of them.

Yes, no color scheme is ever going to compliment every image out there. The point is to see how badly your design is broken.

Content Wells

What happens if your client hires the grandson of Toltzoy to be a staff writer? He likes long, windy tracks of text. He never turns in an article under 2500 words. He can't conceive of 'blurbs' that are only 500 characters long.

Twitter is his anti-Christ.

What can Johnny Tolstoy do to your design? Does it grow elegantly? Does it deal with long words with aplomb, or does it get that weird justification issue where you end up with words spaced out an inch apart?

If there's issues, you can actually solve this two ways: make the design 'growable,' or force only a certain number of words per page, making use of 'next' pages. If you go with the latter, make sure the developers know. Really know. Don't tell them. Put it in big red letters on the comp, so every time they look at it, they remember that requirement.

Oh, and be prepared to hear their groans. Most geeks that I know HATE the 'next' feature.

The other kind of person your client can hire is someone whose muse is e e cummings. Simplicity in all things, he never writes more than a paragraph or two. What does that do? Is your navigation three times the length of the article? Is the main content well pushing everything out, so that when it collapses, the site becomes a mishmash of divs with no real order? Have you braved your design for "Simplicity, simplicity, simplicity"?

Blurbs

Blurbs are a popular feature of websites today. I'm betting you've included a few in your designs. I don't blame you. They add more interest than just a bunch of titles and links, and are fun to style around.

Blurbs are also a great place to hide implicit requirements, or bring out a new place to break your site.

What do I mean by implicit requirements? Those are the fiddly little things that you want, but don't state directly. Like, a blurb box should only have four lines in it. Do you know how variable four lines can be? Different browsers will use slightly different fonts. Different OS's will use completely different fonts. Sure, they'll look the same, but they'll be just different enough to mess with you. One day, it'll be four perfect lines. The next, it'll be five and a half.

Magic. And proof that the god of fonts hates you.

So put too much text in a blurb. Put too little. Consider selling the devs on making something that will auto-concatenate your blurb if some content editor gets cheeky.

Degenerates are going to use your design

Really. Content editors are a bunch of sneaky degenerates when it comes to site designs. They'll take the features for which you had a specific set of ideas for, and they will use it for their own purposes. I've seen them do things to views that would make your skin crawl. They suddenly need a news section? They grab the thing that looks closest to it. They'll try to make all the cool widgets do what they need them to do. It's going to look horrible.

What's the worst thing they could do to your cool features? Should you consider adding a few more, or making them more modular, to keep the mongols at bay?

Damn users and their poor eyes

There's nothing that will break a design faster than pressing Control - + or -. Man, users love to change the font on a page. Sure, your site may have the perfect font size for all users, but if the site before yours used teeny tiny fonts (or honking huge), you're screwed.

So, if you really want to wow people, make that site grow gracefully.

Why can't all users have an awesome monitor like mine?

We do a test in our group, started by Pydanny, where we look at the header of a site and put our fingers up to it, the count how many fingers some glorious header pushed down the page content.

You're a designer. You have this huge, wonderful screen. The finger test probably seems really odd, when your screen is thirty fingers high or more. We poor souls on laptops only have twelve fingers at most. If your gorgeous header is over four or five fingers high, You've now, along with tool bars and such, taken up half our screen. Every time we load a new page, we have to scroll down to get any content.

Sure, we may think 'oh, pretty header' the first time we load the page, but trust me, four or five clicks in, it morphs into 'god-damn header.'

So, break your design by grabbing someone's 12-inch MacBook and seeing how your design looks on their screen. Hell, if you want to get really adventurous, try an Eee PC! If you can look good on the big monitor, the laptop, and the netbook, you've reached some designer-geek nirvana.

Argh! Too many!

It can be a lot. I've had designers in the past tell me the above things are a technical issue, not a designer issue, and developers should be solving them, not them. Technically, yes, they could be solved by a developer.

Go and look at how your developers dress. Decorate their cubes. Design their own websites. Ask them about what design should be (we'll answer quickly. We're opinionated little f'ers). Look at the sites they think are designed perfectly. Feel your soul atrophy in their stark landscapes.

Do you really want them un-breaking your design?

Thoughts on Podcasts

I attended a neat BOF at PyCon, where production of podcasts were discussed. Really, I went to find out what podcasts were being made by Pythonistas, and to see if there were any lessons learned that I could take to NASA. I came away with a few realizations.

An hour? Really?

Even when we are at our most lovey-dovey, in general, we do not want to listen to one person speak for an hour. Even two people are hard to listen to. This is why radio shows have guests. After the first fifteen minutes, the mind starts to wander, especially if there's no visual stimuli. The only people who make their livings talking for an hour straight end up getting an HBO Special.

Are you that good?

My favorite podcasts that are done casually are done in no more than fifteen minutes. They're fast, focused... like popcorn. Filling in small amounts. Check out Writing Excuses or Grammar Girl for examples.

What's your focus?

Don't say 'programming.' You are not writing a text book that you're hoping will be adopted by some level one undergrad course. You are trying to pick up a geek hottie in a bar. "Hey baby, want to come to my server farm and see if my Python scales?"

C'mon. Be bold.

Archive or toss?

There's some podcasts that are always relevant. RadioLab is one of them. You can listen to any show in the last few seasons, and it will still be interesting and relevant. Others are shows that are old if you listen to them the next day. Don't mix the two.

What's your take?

You have to have an angle. What's your hook? Are you super funny? Have unique experience in the field? Have an extremely narrow focus that's of interest to a surprising number of people? Do you have a super sexy voice?

We will listen to Guido ramble off his recipe for biscuits, hoping to decode the mysteries within ("He uses a pinch of cornmeal? Maybe he's talking about C encoders. Quick! To the compiler!"). You? You'd better have something off the bat to keep me there. And no, cunning background music isn't it.

Cunning background music

Oh dear lord. Are there no depths that we will not dork to?

Is your name Jerry Holkins or Mike Krahulik?

Then you'd better put your stuff out on a regular schedule. The Penny Arcade guys are awesome enough that, if they only put out a show a few times a year, I'll stay subscribed anyway. Some guy jabbering on about his favorite framework that can't seem to stick to a regular schedule? The first time I start cleaning up podcasts, out you go.

I don't post this to keep anyone from doing a podcast. I want more people to do podcasts! I just don't want any more that make me want to take an ice pick to my poor iPod.

Dancing under the waterfall

I've been interviewing quite a bit recently, and in the interviews, I've had to explain what our development cycle is like. My response:

"NASA is a waterfall shop. We're an agile group."

Some of the more fascinated interviewees have broken out of the interview vibe to ask how that's done. Enough have done so that I've decided to write up how you get your group to be agile when everyone else wants to do waterfall.

What is Waterfall?

Waterfall is something that is best used when you want to make sure that components of a shuttle aren't going to fail. Sure, things can always go wrong. But you want to prove that at every point along the way that due diligence was given to all the details.

In essence, there's a bunch of steps, and traditionally, you have the engineers and developers at every point. Steps are completely done before moving on to the next step. There is no iteration. You get one shot to get it right. As a system goes, it should work, until you get people involved. People don't like saying 'Okay, we're done. On to the next bit,' especially when their buy-in group is large. There will always be one last thing to add.

You need a magician

If you're in an organization that's bought into Waterfall, it's not going away any time soon. Millions have probably been poured into the people that crafted it, the people that maintain it, and the systems that support it. So, to the larger organization, you need do some slight of hand.

It is a magic trick. The large organization is the audience. One person plays the magician, going along with the flow of the waterfall, making everything appear as if it's going along as it always has.

The developers are also an audience. To them, it should appear that they are working in an agile shop. Their development cycles are short, requirements are tightly controlled, and they stop coding on the day they thought they were going to.

You need a spokesperson

The waterfall method assumes that everyone will be available during all parts of the process. It assumes that developers are absolutely vital to requirements gathering and design, as well as the QA after implementation.

No geek I ever met has ever loved requirements gathering. If you want to punish a geek, don't take away telecommuting or the cappuccino machine. Tell them they have to sit in on requirement and design meetings. Just don't blame me if it ends in a envelope opener to the carotid.

You need someone that's technical to be the spokesperson to sit in on these meetings. They need to have the ability to be quizzed relentlessly about the capabilities of your system, and answer quickly and accurately. No "I'll take it back to my team..." Next time, they'll just ask for the team to come.

You need to forget

One disadvantage of dancing under the waterfall is that once you're done coding, you don't deploy quickly. There's lots more paperwork and testing to go through before you hit the build button. So the build procedure that you have at the end of the development cycle needs to be flawless... because you're not seeing it again for a few weeks. For our group, it can be up to six weeks before we actually do a build for any release.

The developers must come to terms with this. It's not elegant, it kills the momentum, but it's as good as one can usually get under waterfall. There's good news though!

Keep 'em busy

The biggest trick to keeping everyone under an agile system is being able to think about three releases at once. Why do you have to do this? Because while you're gathering requirements for one release and following the QA on another, they're writing a completely different release.

So, let's say we're working on NASA Science 2.1.

2.0 is in QA and being prepped for deployment.

2.2 is the release I'm gathering for.

Once 2.1 is done, they immediately get the next set of requirements, coded into tickets that are ready for work.

Sound like a lot of work?

Well, let's just say it's good that I'm dancing under a waterfall. One can get pretty sweaty.

Requirements and Dead Cats

Gathering requirements and executing them is not as simple as getting the requirement, then having someone code it. It's like Schrodinger's cat. That's the problem where you have a cat in a box, and you don't know if it's dead or alive. Theoretically, the cat is both dead and alive at the same time.

If you wait long enough, the question answers itself. The cat will always croak.

Every time a requirement is touched or thought about after its creation, it changes. Instead of the cat being dead or alive, we're not even sure if it's a cat. Maybe someone put a chinchilla in the box. The req is perverted in ways that, at the end of the development period, are beyond human comprehension. Ironically, the simpler the requirement, the more perverted and complex it becomes. A two-line requirement, I swear, will become something that can bring down the very foundations of our society if we ponder it too long.

Note: this is the true goal behind agile development: to keep us from thinking too long on any requirement, lest we all be destroyed.

Longer requirements are perverted less, but not because they are more exact. We simply do not like thinking about them. Put them in a ticket, and it's guaranteed that we will not open that ticket until week six of a six week development cycle.

This is a real problem in large buy-in groups like mine. We have lots of people who like to touch tickets all the time and think about them and morph them from dead cats to live ones and back again. Here are some of the ways tickets are perverted:

• Comments on tickets


• Comments on the comments on tickets


• Comments on the comment on another ticket


• Conversations had in meetings, dutifully noted by the meeting note taker


• Conversations had at desk side, sometimes followed up by a confirmation email


• Conversations had in the hallway, where one person is pensive and filled with ideas, and the other really, really has to pee


• Alternate universe conversations, in which one person has one conversation, and the other person has a completely different conversation


• Imaginary conversations, in which one person will swear they had a conversation with another person, and that person swears it never happened

So, what do we do?

Well, we're getting better about it, for certain. And I'm trying to introduce some things that will make the perversions cause fewer fist-fights at the end of a dev cycle, when I'm calling for a tag to be cut, and buy-in people are screaming for an extension.

Fewer requirements

At first, this seems counter-intuitive. Wouldn't more tickets give more of a buffer to the poking and prodding of any one ticket?

In fact, part of the perversion that goes on is due to people having so many tickets to touch. They touch one, then run off to touch fifty more. By the time they've returned to the first ticket, they've forgotten how they changed it the first time, then change it again.

Having fewer tickets means giving people the chance to actually remember what they wanted the first time, and keeps the developers from having to change code in fifty places every time someone decides to walk through the requirements again.

We do not talk in N-Space

If a conversation isn't recorded in a sensible location, it did not happen. I do not care if the President of Burundi is willing to vouch for you: those words were never said.

What's a sensible place? Oddly enough, it's not 'the wiki.' 'The wiki' might as well be synonymous with 'the trash pit' or 'a teenager's bedroom,' the way most people treat it. It's not 'the meeting notes'. No one refers to those things unless they want to prove you wrong about something. It's on the ticket where the requirement is. If you have a conversation, record it there. Not in another ticket. Not on a new wiki page. Not in an email that no one else will see. Not in some word document on the server.

On. The god-damn. Ticket.

Vicodin

As I said in the previous post, requirements getting perverted happens. Most of the time, the differences are minor. A satellite is not going to fall out of the sky because the navigation on a web page isn't indented quite enough.

When a requirement isn't quite hitting the peg for that release, and not everyone who has buy-in is loving it, don't hit the pause button. Momentum is a thing that's hard to rev up, once stopped. The second you hit the 'OMGWTF' button, the entire group's memory starts to decay, and, as they review the tickets that were closed until now, requirements get even more perverted.

Take a pill. Sometimes you just have to try again.

Cut a tag and try again

If your cat is indeed dead and smelly, cut a tag and start working on the next cycle. Non-developers don't know this, but cutting a tag feels good. It's like the feeling you get when walking into a fresh hotel room. The sheets are fresh, the soap is wrapped, you've got little bottles of shampoo, and everything is clean and shiny.

Give your devs a new hotel room. Cut a tag, and start over fresh, rather than hoping to squeeze one last change into a beleaguered release. Because if you look at the requirement too much, it does bring about the end of all things.

Why I almost did a sys.exit()

I almost quit programming.

It was back in the late nineties, early aughts, when I found myself working at a start-up. We provided hosting and VPN solutions, and I was employed partly as a customer service person and a programmer. I was thrilled. After doing cookie cutter code in school and projects that were never seen again, I was finally going to do some code that would be used in live environment!

Our desks were arranged in x's, with one person in each section of the x. There were no barriers, as cubes were both evil and very expensive. As a result, we chatted a lot over the top of our monitors.

I got placed with some other developers, all male. We were discouraged from wearing headphones, as that meant we were passing up learning opportunities, so I got to hear everything the guys talked about. This was in the midst of the *nix wars, and these guys were sworn enemies on that front.

Every day, I got to hear about what was better: SuSE? CentOS? Red Hat? Solaris? Pure, unadulturated Unix dug up from Bell Labs? They had lots of ammunition, too. Which kernel compiled faster. Which had more updates. Which performed slightly better. Why the other person's bench tests sucked. Why the other person obviously didn't know what the hell he was doing if he had to recompile his kernel all the time. Why certain *nix distros cause cancer.

It was so. F'ing. Boring.

Being hormonal and under a deadline (I was about seven months pregnant), I did finally threaten to find all the burned *nix disks, break them into shards, and stab them into their eyeballs. That moved the fights into email. At least the heated glares I could ignore.

When most of us were laid off some months later, I seriously considered whether I wanted the rest of my life to be sandwiched between two long-hairs that can't agree to disagree. I loved programming, but did I love the people enough?

After a long side-jaunt, I came into a job at NASA via pydanny. It wasn't a programming job. I was simply to be a requirements gatherer and needs analyzer. I was happy in that capacity, and probably would have stayed in that track had it not been for one thing:

Plone.

Say what you will about Plone, ye lovers of other frameworks, but of all things it may do right or wrong, it did one thing very right:

It got me back into the fold.

Pydanny was hot to use it for something, anything. We won approval to go ahead with using Plone for a new website. I was the requirements gatherer. Danny was the coder. After a while, he encouraged me to pick up Python so I could join him in coding as well. I did so, and loved it. Adored it. Got scolded because I was stepping outside of my career path. I didn't have to worry about all the piddly discussions about kernals or whether one algorithm was a smidgen faster than another. I could just code. And make things work.

Maybe this should be called "How to get more women into Python, part II." The sentiment of 'why are we arguing about this crap' has been fairly universal when it comes to the women I've spoken to. They've been willing to learn new things, learn best practices, but one thing they have not been willing to do is argue about which module is slightly faster. We just want to get our work done. Because, lord knows, there's more to life than code.

Arguing isn't a bad thing. But if it's all you do, if the arguments span mealtimes, perhaps it's time to step back and think about if the energy the fight is taking isn't just getting in the way of doing cool stuff, and getting others to do cool stuff as well.

How I learned to love hockey (and what that has to do with programming)

Growing up, I was not a sports fan in the least. I didn't enjoy watching them, I had no interest in learning the rules, and I had NO interest in playing any of them. In gym, I was so accident prone that I had to sit with the asthma kids, and I was damned happy to do so. I preferred playing SET to kicking a ball around.

I dated a few guys that were into sports. In the interest of being a couple, they'd try to teach me the rules while watching a game on TV. Liking systems, I'd try my best to learn. Football was the first attempt. I'd post some of the repartee, but honestly, it bored me so terribly, I can't even dredge up the few things that I did manage to pick up. What I came up with could probably fit on a 3x5 card, and have room for my Superbowl Dip recipe.

Fortunately, I married a guy who, while interested in sports, understood that I had no interest in watching or understanding them. I thought that would simply be something I'd never get into.

Then came Jim.

Jim, a friend of mine, has season tickets to the Washington Capitals, and invited me to join him for a game. Really, I was just interested in a night out rather than learning about hockey. For the first few games, I was just there to BS with Jim. He even joked about how I didn't know what the hell was going on.

Jim (watching me trying to look attentive): So, you know what they're doing?

Me: Oh, sure!

Jim: Okay. What team is our team?

(Long, painful pause)

Me: They're... in... white?

Jim: You know, you can ask if you don't get what's going on.

No, no, I was good. I was just there for the company and the Boardwalk Fries. I don't think I learned a damn thing that first season.

At least, that's what I thought.

The second season, I again joined Jim for weekend games, but I noticed something different. I was beginning to understand the game. I could tell when something bad happened. When the Caps were playing well. When they were having a rough night. When a player seemed 'off.'

Now, keep in mind, Jim hadn't explained any rules to me. I hadn't read anything. There wasn't anything I could think of that would have given my an understanding of the game at all. So, where had it come from?

I paid attention to the next few games, and started to get clues as to where this implicit knowledge had come from: the crowd. The crowd was filled with people who did, in fact, know hockey. They knew what a bad call was, they reacted to a team that was on fire, and a team that was tired and run down. In general, there's a buzz during games: people chatting, moving about, coughing, shuffling between seats. When things happen, that buzz turns to shouts... or silence. The changes in volume snap my attention to what was going on. I'd subconsciously replay the last few seconds in my head and try to map that to the sound.

I tested my implicit knowledge on my expert. While I was still very fuzzy, I was on the right track. With this in hand, I actually started looking up some of the rules that interested me, like penalties.

So what does this have to do with learning?

Rules are boring

They really, really are. I don't know many people who find rules interesting. Some people do become rule dictionaries, but I guarantee, the interest came first. People don't learn the rules first: they find the interest.

So when it comes to programming, why do we focus on the rules first? Loving computers and, more importantly, loving code should come first. However, every class I've ever been in has started with data structures and variables and syntax and, well, the rules.

Why not show them the buzz first? Take them to a users group in your area and let them see people talking about what they do. Most coders are more than happy to talk about their work, and are excited to talk about whatever neat thing has their attention at the moment. If you have someone you're really interested in seeing excel, see if you can get them to a conference. It's one thing to look at code and understand what an if statement is. It's another matter completely to understand the community that goes with it.

Rules are a good resource

Does this mean we should eschew rules completely? Of course not. They're a good resource. Once I was in love with hockey, I wanted to know more about the sport. While I'm no rulebook, I do know what the penalties are, the types of players, and some of the strategy behind the game. Hell, this year, I've even learned about standings, and will sometimes check up on other teams to see what their chances of overtaking us are.

As a coder learns more he/she will want to know more. They'll want to know more syntax, or how to make their code more efficient. They'll look at new frameworks and languages. They'll become an evangelist. If all we ever make are cube-rats, all we'll ever get is loveless code that does barely what it's supposed to do, and never anything more.

And by the by... Go Caps! Southeast Division Champs!

Developers need hugs too

I'm about to get a little crazy here, so bear with me. I just had to let people in on this way out realization I had:

Developers are people, too.

Now, developers, I know that you already knew this. This post is not for you. Go read the archives of XKCD or something. Those emotionally close to developers probably expected the above, so you can probably skip this post, too.

Who, then, am I writing to?

I write to those that have to work with developers. Specifically, I'm speaking to those that have to deal with evaluating the work of a developer.

Let's say your significant other asks for a cake. Great, you think, I know how to make a cake. I have all the ingredients here. This shouldn't be any problem. So, you collect your flour and sugar and vanilla and milk and eggs-- Oh, wait. Eggs. Have to go get eggs.

So you go to the store to get eggs, and start cooking. Except you can't remember how much flour to use, and you can't remember where you put that one recipe from Southern Living back in 87. A few hours of searching later, you've found it, only to discover that you need sour cream as well. You debate substituting some old creamer in the back of your fridge, but, remembering you actually love your significant other, you go back to the store.

Now with everything in hand, you start cooking. An hour later, you're covered in flour and sugar and egg bits, but the cakes are in the oven. You start to clean up, but by now, you're dragging, having been running about for most the day for a stupid cake. You are considering an existence without cake. A nocaken?

The cake finishes, and you icing it, then present it proudly to your significant other. And he/she frowns.

"But I wanted chocolate."

Want to know how the analogy maps?

We get requests all the time that start with a basic need. "I need a way to share files through a web interface." Great! we think. We have a CMS that does that out of the box! This will be sooo easy.

Easy until we discover that the servers are all already taken, and we have to beg for another one. Once we get the server, we find out we're out of licenses. Once we have a license, we discover there's issues installing the proper decoders onto our flavor of *nix, and we have to find a special buildout recipe. Finally, we get everything to build consistently, and we hand over something we've been working our butt off on for weeks, if not months.

"But I wanted it to have a preview function."

Cake is so much more satisfying to throw at someone than code.

"But I hear devs critique each other ALL THE TIME!"

Well, yes. But see, we're not in the same role with each other. We're peers, and some amount of critique/pissing content is expected. We even invite it. If Alton Brown came in and said, "Darling, that cake should have been chocolate," I would have been rushing off for some cocoa to make everything alright for ALTON FREAKING BROWN. My husband just gets cake shoved somewhere improbable.

So, what to do?

Take a deep breath. Perhaps the requirements were misread. Perhaps a major part of the requirement was missed (more on how that happens later). Perhaps hallway conversations and after-meeting asides perverted the requirement over time. It happens. Humans wrote the requirements, humans passed them along, humans implemented the requirements, and humans QA'd them. That's a lot of space for error.

There's things you can do in the future to help, but for now, getting spun up over the difference between chocolate and vanilla is going to do nothing for anyone. You might win a quick victory by slamming on the coders, but in the end, you'll end up hurting your team more. Is it worth killing the team's momentum for that?

Do you really want to have them throw the cake in your face and walk out the door?

Don't stop everything due to the cake being the wrong flavor. Go ahead and eat it, and make a note to ask for chocolate next time.

Web Two point Buh

We all know what Web 2.0 is by now: separation of form and content. The current batch of CMS's out there do a great job of doing this: databases and templates are kept in nicely separate environments, allowing data to be reused without having to pull data out of heinously formatted HTML files.

Bravo. Good job, all. But we're not where we need to be yet.

After working on NASAScience for two years, I've come to the conclusion that we need more walls than just between form and content.

We need a wall between the developers and designers.

Theoretically, we have that. In practice, we're not even close. Many of the people who design CMS's have never had to sit in meetings with designers in the midst of a crazed fit of inspiration, or with a interface expert who's trying to nudge things to be just right. They want to make changes to the sites they have to manage. They want ultimate freedom.

They want the right to have a better idea.

After a week off from my usual job, I have to say, I have a bit more sympathy for them. I can see the appeal for just doing a site in Flash, though it still makes my soul hurt. Flash, they can control. They don't have to wait for developers to get through their most recent agile cycle to deal with their needs. Six weeks is short for developers. For a designer, that is nigh on forever.

Inspired and refreshed, I sketched out an idea for giving designers much more control over the visual aspects of their websites. Some features:

Lots of views

Instead of making tons of content types, make a few that cover many cases.

1. Flash object pages


2. Image pages


3. Image galleries


4. Text heavy pages


5. Video pages

Note: there's a few more, but I'm on the train and can't pull out my notes, which are on 11x17 sheets of paper.

We shouldn't restrict where objects should be put. They should be able to put new page types wherever they need. Updating the structure of the website shouldn't have to wait for a developer to be free.

The secret to just a few content types is to have lots of views. Give the designer lots of options, and make it easy for them to update these views if they need, or add some new ones. Don't make them drudge through the ZMI. For ghu's sake, who wants designers going through the hell that's the ZMI? Or poking at ambiguously named admin functions. Do you want your site deleted?! I've almost had dev vets of 20+ years delete my site. What do you think a designer would do?

CSS on demand

Sometimes you need to tweak the CSS. Sometimes, you just want a bit of CSS to do something you need. Why should you have to wait for a new deployment? However, you don't want them adding CSS inline, as that's impossible to find later. Instead, give them a slot to add chunks of CSS. Then, at the end of your dev period, you can do a report that pulls up all the new CSS chunks and incorporate them into your master CSS.

Customize everything on demand

Everything should be up for customization. The header image. The navigation. The footer. Elements that should be on every page, but a use case has come up where a widget needs to go away. Let them do it. Let them make a special page with pink ponies in the middle of the site, if that's what they've discovered they need to do.

Parts making up the whole

Sometimes, you have things that, in the initial design, are 'whole'. Headers are a good example. Normally, there's a nice, long header image. Give the designer the option to break that whole thing into parts. In our case, I'm adding two more elements that they can plug images or html or whatever they want into it, adding visual interest as needed.

Designer friendly

Sure, sure, this is usually all very doable in most CMS's without having to make huge fuss about the interface. But think about what a designer would have to do in order to affect most of these changes. They'd have to troll through dozens of dangerous, application killing options that are all speaking geek to find the option that will let them do what they need. This should all be exposed on the page they want to edit. Want to modify a template? There you go. A button will take you the the right screen with a warning that this changes -all- templates of that type. Want a new template? There you go. New template, and I'll even add it to the view options for you. Have some CSS for me? Why look, I have a box for that right here.

Why go to the bother?

Yes, this looks like a lot of work, and I'm sure it will be. I'm sure my devs are going to HATE me when they get back into work today. But in the end, I think we all do our job better when we don't have to worry about waiting on other people. I love my designers, I really do. I think they're awesome, creative people. I'd just much rather be playing Zombie! and talking about video games with them, rather than arguing about why we can't make the site like they need it right now.

Stage fright

I'm notorious for not getting stage fright. Since I was still in saddle shoes, I could get up in front of any number of people and spout off about pretty much anything. Impromptu, structured, slide-laden, scripted: none of it has ever been a real problem for me.

Then why do I get stage fright when it comes to posting code?

In my line of work, I write a lot of small, helpful scripts to take some of the monotony out of certain parts of my job. There aren't many functions I have left that don't have at least one py scrit associated with it.

At PyCon, I mentioned that I had written a library for Trac that printed out reports. It started out as someone wanting a listing of what had happened to my tickets over the past month. True, one can simply do a query against the database, but there's something quirky about the Trac database:

It's done in sqlite.

Sqlite SUCKS when it comes to date functions.

All dates are in unixtime. There are no functions for dates. You can't subtract a certain number of seconds from a unixtime date in a query. You can't call some cute function that gives you a date range. You have to work out the unixtime on your own and input it.

Sqlite people, I love you for making a lightweight database. I HATE you for this one oversight. Really? You didn't think people would care about time? Developers are cool, but not so cool that we've ascended the space/time continuum and live on a plane where all times are now and therefore irrelevant.

Anyway, after discovering this oversight, and getting tired of using online converters (no, I cannot do unixtime in my head), I decided to write a program that would do it for me. It hit against trac.db and got me all tickets for a month based on milestone. Even printed me a nice report.

After discovering how to do that, I got more requests for Trac reports. Over time, the library grew, function by function.

Anyway, the fellow Pythonista asked if I could share my code with him. Being the gregarious sort I am, I said sure! Upon returning home, I actually looked at the code, and began to panic.

Oh, crap. Now I knew how all those people who hated public speaking felt. Unfun. In order to stem the tide of dread, I started to analyze what had me so concerned.

Organic

Most of the need for small scripts grows organically out of a particular need. This leads to some strange code building strategies, like making functions too large, or forgetting to add docstrings. Or making functions -too- specific (I have several that make SQL queries and return the results. Surely this could be streamlined?).

It's the way of cubeland: someone catches on that you have a fast way to do one task, and you have people testing you with every variation of that task they can come up with.

Unique to me?

Is the code I write really useful to anyone else? I mean, I had a very specific need. Who else could possibly need a report that spits out all tickets that have been touched in the past ten days? Are other people really that obsessed with the Trac database? If there are, is there a support group I can join?

Can anyone else even understand this crap?

This fear came over me with my first programming class my sophomore year of high school, and has never really left. Can people understand the crap I write? Most of my work scripts are never meant to see the light of day. They sit quietly in a jumble, waiting for me to pop in and feed them some data, then get out. They're like the red-headed stepchildren of lore. Good for doing chores, but don't take them to the ball.

But it's just 300 lines!

Three hundred lines isn't a lot. I'm not sure how many lines make up the major frameworks that are about today, but it's sure as hell more than 300. Three hundred lines of code really rank their own Google code project?

At the end of the day, I decided to toss those worries aside and post the code. When I do public speaking, my last thought is often "What's the worse that could happen? Someone shoots me on stage? At least I'll end up on TV." What's the worse thing that could happen if I post some code? Someone ends up not using it? At worse, I get told what's wrong with the code, and I get a chance to learn and fix it up.

So the red-head is going to the ball. I encourage everyone else to take out their own step-children and see if they can do some other people some good.

Why aren't there more women programmers?

I just returned from PyCon, and one question that was put to me several times was "Why aren't there more women programmers?"

I'm no expert on the matter, but I do know what I encountered growing up as a geek with two X genes rather than one.

Who was the computer geek in the house?

While I believe that children model both parents when it comes to behavior, there's more than a little evidence that they model the parent of the same sex as them more than the other. Could be biology, could be socialization, it's probably a lot of things that are outside the scope of this post.

In my house, it was my mother who was the programmer. My father was a logistician who detested computers. While my mother had no great love of them, she would talk about programming and be the one to fix someone's ailing PC if needed. When she took me to work she showed me what email was and let me play with any spare terminals lying around. She taught me the program for using the color printer and let me entertain myself with your tax dollars. She even let me write a few small programs at her terminal, and taught me what databases were.

My dad showed me spreadsheets. And the snack bar.

I had a unique situation, though. Most young girls that are of my generation grew up in a house where the father, the former electronics geek, did the computer fiddling.

Friction

If you're going to do anything outside what's seen as 'normal' for your sex, you have to be prepared for friction. There will be people who will give you crap for being a girl who likes computers more than literature. If you're a guy who wants to go into nursing, you get just as much crap, I'm told.

Attention

I have never felt ignored as a woman interested in computers. If anything, it's gotten me more attention. It's human nature. I looked different than anyone else in the room, so I was often noticed first. Being something of an attention whore, I've rather enjoyed it. Being as how geeks aren't always known as the most social of creatures, I can see where this can be intimidating. I knew an introvert who refused to join the chess club at his college because he was too good: he'd stand out. That horrified him.

Cluebat: geek girls can be just as shy as geek guys.

Eyecandy

There's some cute guys in computers. I think the situation is getting radically better every year. However, in my formative years, computer guys were... a bit rougher around the edges. Their uniform was an ill-fitting t-shirt, often with the odd wear hole and unbleachable stain, baggy jeans, gray hoodie, and a patina of poor hygiene.

Imagine being a girl and walking into that particular after-school club.

Yeah, I'd go see if there were any open slots in the Model UN, too.

Note: I don't know who popularized showering in the past decade, but thank you.

So what to do?

I think things will get better with time, but if you want to really push the curve, here's what I'd do:

1. Geek guys: make sure to breed with geek women. I'm married to a geek, and we have two very geeky children. If you breed with a non-geek woman, you run the risk of ending up with a mother who limits their time on the computer. This will not do.
2. If all geek women are taken, try to convert a potential geek woman. I recommend starting off with Star Trek: Voyager (the Trek for your girlfriend) and The Sims. Do not start with World of Warcraft until AFTER you have cinched breeding.
3. If you have geek children who are male, start primping them for snagging the attention of potential geek girls. I recommend cool jeans, artsy t-shirts, a guitar, and excellent shades.
4. In your fellow geek males, do not accept slovenly ways. Beat them until they buy better clothes and can affect an air of cool disinterest that chicks totally dig.
5. Men of Python Calendar. We have a year until the next PyCon, so start working on your abs.

As we tempt more women with eye candy and careers that do not smell of sweat and Coke, women will become less a strange site in the industry, hence reducing friction and attention. Though I will not get as much attention as before (sob), I will accept this as a consequence of diversifying our trade.

So, guys, get on it.

Get some awesome jeans. Us girls need something to ogle.