Code Softly

Did I Just Spot CSS In a Tron:Uprising Episode?

2013-01-15T02:45:33Z

I’m pretty sure I just saw a mysterious fragment of CSS show up on a cyber-train door in the computer-generated cartoon Tron:Uprising. I’m not sure why it’s there.

First, a few confessions:

I watch Tron:Uprising on the Disney XD channel. I knew it was on Disney XD because I saw the commercial for it during an episode of Doc McStuffin’.
I DVR the show so I can watch it alone, because nobody else in the family is interested in what goes on in The Grid. Ever.
I pay VERY close attention to how code is depicted in films and TV shows. I tend to notice it whenever it shows up.

All of this culminated three days ago when I was watching a DVR’ed episode, “Welcome Home”. The characters are in a train, and as the car doors slide open and closed, I noticed a flash of what looked like CSS below the number painted on the door.

Rewinding and freezing the frame proved me correct. On the door is what appears to be at least a fragment of CSS style rules. Here’s the closeup:

My theories on how it got there:

It’s an easter egg, put there by the show’s artists, who are maybe also web nerds. This was my first guess, but looking at the CSS, there’s nothing terribly clever about it. It doesn’t cry out “I’m from the TRON homepage!” or look like something from Flynn’s Arcade website.

It’s an artifact of how the text was put on the door in the show’s graphical tools. I have no clue if this is legit, but maybe the tools that put text on 3D computer-modeled stuff uses CSS to style that text, and the artist didn’t close a style tag? I have a hard time believing that’s the case. I mean, I doubt Pixar has to worry about web-fonts.

Someone copy/pasted the door text from something that had style rules. In a classic case where the clipboard carries over style information, someone was careless and yanked the door number from some other source, pasted it, and didn’t get around to deleting the style text

Needless to say, I have no confidence in any of these explanations, and web searches are turning up nothing for me, so please have a look and help me out.

I Was at CodeMash BEFORE It Was Cool

2013-01-09T23:45:34Z

I’ll admit it, I was at CodeMash WAY back in the day. Before it filled up the whole conference center. When you could get a ticket.

While most of the team is at CodeMash this week, I’m reflecting on the value of such conferences. In no particular order:

Renewed Motivation - being surrounded by nerds facing similar problems is always good for morale. You are not alone.
New Ideas - One good thing about CodeMash is that it is inclusive and language-agnostic. It’s surprising what you can learn from other implementations,. Even more surprising is learning what you have in common.
Networking - You’ll meet people. Good people. These are folks that you’ll tweet, email, and Link-in. This is a good thing.
Fun - part of the appeal is having fun with people who make money doing the same thing as you. The nice benefit of programmers is that they tend to genuinely enjoy their work, so it’s not too far of a stretch to get along.

Breaking It All Down: Simplify Solutions

2013-01-01T15:30:50Z

I think there are some creative ways to break up seemingly monolithic features into bite-sized, achievable, and incremental steps. Here’s a few questions I often meditate upon when facing a largish feature request (pro-tip: they can usually be combined):

1 - Can we hardcode it?

Take a page from the Test-Driven Development playbook. If your feature is big because of complex computations that need to take place, see if there’s a way to hard-code the behavior for the most popular flavors. Ignore the other ones for now.

An Example: For a route-planning application, instead of writing logic to calculate a nice bike route between 2 arbitrary locations, show a map that lets the user pick the routes from the center of town to the ten most-popular bike destinations.

2 - Can we just do one?

Similar to hard-coding, doing one is nice when you have a feature that needs to work for a large and diverse set of items. In these cases, you might get a lot of bang for the buck by picking the simplest item or class of items from the catalog, and do your feature just for that one.

This lets you side-step some of the complexity of crafting a solution that works for the entire population. You can learn what a really good implementation takes in the simplest case. You can also hedge risk by getting the feature in front of customers early, so you can decide if it’s even *WORTH *all the extra effort to expand to the rest of the catalog. On top of that, you can get some good numbers around how long things will take: “It took us fifteen days to build it for that one product, and there was a lot of hard-coding, so let’s say it will be double that to make it work for EVERYTHING”.

An Example:

If you need to show a 3D HTML5 rendering of purses on the site with zoom, mouse-over highlights, and hotspots, do it first for a single purse in the catalog. Hardcode it to be really amazing for just that bag, and don’t even bother showing the 3D option for the other 2,000 bags on the site.

3 - Can we skip part(s) of it?

This one is kind of obvious, but it’s surprisingly easy to forget about. It can be helpful to focus on a single aspect of a feature, knowing the plan is to roll out the rest of it later. It’s always handy to think about this before spending a whole lot of time designing and building. If you can strip out the non-essential parts, you can deliver something, then enhance it. Also be sure to put in an on/off switch, so it can be deployed, but disabled if necessary.

Photo by bobbi vie, Some rights reserved

3 Selfish Features

2012-01-03T23:00:52Z

Selfish features make your staff happy and efficient, but have nothing to do with helping your audience. Remember them? The people who are going to make or break you? The people for whom your site exists in the first place?

Here’s a few features I consider “selfish”:

1 - Content Management Systems (CMS)

CMS’s are great, and critical for creating new information for your audience. Keep in mind that you could read a book and learn to write HTML, or maybe even pay the geeky kid down the street to update a bunch of static pages for you.

Don’t wait for a CMS to start your site. Put SOMETHING up while you’re rigging the internals of your authoring tool.

2 - Analytics Dashboards

Dashboards are sexy. They combine lot of impressive looking charts and figures into one place.

Sadly, dashboards are time-consuming for developers to build and test, and people rarely look at them.

Try waiting until you find yourself saying “Boy, if we only had metric X, I’ll bet we could make 15% more”, and THEN ask for the report or dashboard. Remember, time spent on reports is time NOT spent on features for your customers.

3 - Rich Text Editors

This goes along with the CMS selfish feature. People want their authoring experience to be “just like using Word”. Reality Alert: authoring HTML is not the same as authoring a term paper.

Rich text editors almost never work. They create bloated, crazy markup that messes with page styles, have unpredictable image placement and layout, and pretty much cause more trouble than they’re worth. Consider markdown or a similarly humane syntax that helps the author out, but doesn’t try to candy-coat the reality of what they’re doing.

There are many more. You get the idea.

I’m not advocating that we never build selfish features, but it’s important to recognize them for what they are: indulgences to make life easier for you, and not for your audience.

Don't Forget to Optimize

2011-11-28T04:56:10Z

“Avoid premature optimization” is a popular and effective mantra. It’s a defense against the temptation to worry about speed and performance before you even have a working feature. Sadly, this often ends up interpreted as “forget about optimization”, and that’s a big honking mistake.

Speed matters. The magic number has changed over time, but the basic rule hasn’t: the longer a page takes to load, the less likely people are to use it.

Too often programmers quote The Mantra and then neglect to ever optimize. The idea is to avoid focusing on speed too soon, but not forever.

The best way to avoid forgetting about performance is to make it a feature. When building your backlog, pop in a story that goes like this:

As a user I want the homepage to load in under two seconds so I can quickly view the upcoming concert schedule

That way, everyone understands the value of speed, and it doesn’t get sacrificed for more easily visible features.

Image by Mike L Photo’s Some rights reserved

Tool Thrash

2011-11-26T01:59:52Z

At work we’re looking for a new tool to manage workflow, tasks, and status. We haven’t been thrilled with our current system, but decided to live with it until it became to painful and/or costly to keep around.

I think living with the bad tool has been instrumental in learning what we want in a great system.

There’s always a strong temptation to discard something that pisses you off and try something new ASAP. When you do this, you learn what you hate, but very little about what you value. You might go through three or four tools before you get a handle on the core features that mean the most.

Living in pain, on the other hand, cultivates wisdom. You start learning why you can’t stand the lack of a quality workflow system, how important project setup is, and if you care about how fast it is.

With a list of grievances, there’s little room for “well, that’s just, like, your opinion, man”, and more experience-based decisions emerge naturally: “Remember how much you hate that tiny text field?”. It’s much clearer when a good choice presents itself.

Once you learn these things, you can pick your next (and hopefully last) tool. Fingers crossed.

Photo by Noel C. Hankamer ;Some rights reserved

CSS Sanity: Frameworks

2011-09-28T22:34:46Z

Ever spend more than 45 minutes trying to align three page elements in a horizontal row? Of course you have.

Like most developers, you refuse to use the table element for layout. The problem is that CSS stinks for horizontal layout. So we’re left fighting block and inline display rules, temperamental width issues, absolute vs. relative positioning, and browser quirks (wtf is the box model, anyway?).

CSS frameworks to the rescue. They let you do fairly semantic markup, have minimal sizes, are multi-browser compatible, and make it easy to align page elements.

My personal favorite it Blueprint, but there are a bunch of others.

Beware the Immovable Deadline

2011-09-27T23:32:44Z

Almost every software development deadline is movable. Even if the CEO of your Fourtune 50 company has promised via international press conference your product will ship August 1st, the deadline can move.

Of course, your CEO will scream at you and be pissed, the public might be disappointed, people may be fired, but if your company set the deadline, your company can move it.

Compare that to a deadline that is IMPOSSIBLE to move, no matter how much you or your company wants it.

If your product release is tied to a national holiday, astrological event, or similarly externally imposed temporal happening, be very careful how you build.

Be paranoid. Build, test, and deploy only the bare essentials. Start immediately. There’s always time to add on further enhancements once you have something live.

Need to build a home search site in time for a local leather festival’s parade? Start with a static HTML page that lists all the properties in alphabetical order.

Need a site that lets people track an upcoming NASA mission? Just publish a static timetable of the launch events. Build the interactive streaming video stuff once that’s up.

Having zero features at the deadline is utterly unacceptable, so get something greater than zero deployed ASAP. Remember that any number of catastrophes can happen between now and your deadline (the one you can’t miss), so get it out of the way.

This also has the nice side effect of acting as a kind of minimum viable product, and you can get early-users’ feedback to help drive the other features. It would suck to spend months building an augmented reality feature for 11/11/11 day, only to find out three people used it.

Dear Facebook, That Was Smart

2011-09-24T13:05:37Z

I’m pretty sure Facebook’s f8 conference this year was scheduled AFTER they had all their ducks in a row for the new Timeline and OpenGraph features. That’s pretty dang smart if you’re dedicated to quality products.

This year’s F8 conference wasn’t announced until about 30 days before it happened. That’s a little weird for a major tech event. Often they’re set up a year or more in advance.

I was puzzled until I started thinking about the pressure that must have been on the Facebook development teams to finish the features in time to have them ready for zillions of people to use the instant Mark finished his keynote. Then I realized what probably happened.

What makes the most sense to me is that Facebook finished Timeline and OpenGraph, and THEN scheduled f8.

Genius! No rushing at the end to cram in half-finished features. No shortening of the test cycle. It’s so much healthier to keep refining a product, and have someone watching to determine when it’s “done enough”, and THEN go scheduling announcements, rollouts, and other dramatic things.

Leftover Soap and Team Size

2011-05-10T10:30:08Z

I’ve noticed that when our family’s bar of Zest is reduced to a certain size, it becomes ineffective. There’s still soap in there, but it just doesn’t seem to produce any quality lather. I suspect the same is true of small software development teams.

A team of one or two programmers is small and nimble, but susceptible to external forces. If a team member gets sick, goes on vacation, or takes another job, your team is reduced by 50% or 100% for that time. That’s a lot. The remaining team member is almost certainly forced into some extremely inefficient task-switching, further reducing throughput.

I think it’s OK to dedicate a very small number of people to a task, as long as they’re part of a larger team with members who can help out in a pinch. Plus the team will naturally cross-train as they ask each other for help or advice.

OF COURSE! Put Your Call To Action in the Terminal Area

2011-05-06T02:56:59Z

I am by no means a user interface expert, but I like to have some clue as to what works and what doesn’t, and so I find the occasional nugget of practical design interesting.

Here’s a post that explains how your site’s call to action should go where it does the most good, in the terminal area (it’s science, yo):

A but�ton in the ter�mi�nal area is a com�pelling call to action because it’s placed at the end of the user’s view�ing pat�tern. When it’s at the end of their view�ing pat�tern, users don’t have to look around to find your call to action but�ton. Putting your call to action but�ton in any other area could get you clicks, but not as effec�tively as putting it in the ter�mi�nal area.

Why Users Click Right Call to Actions More Than Left Ones [UX Movement]

The Tourniquet Pattern Explained

2011-05-04T02:09:12Z

Today Mike Pirnat and I were discussing a particularly nasty piece of legacy code we often have to interface with. I described one technique he had used as the Tourniquet Pattern.

This Tourniquet is when you declare a section of your system to be too complex to directly work with or improve safely, and so you seal it off behind cleaner interfaces.

When You Need A Tourniquet

A favorite interview question of mine is “Do you always refactor and fix legacy code when you come across it?”. This is by no means a clear issue. A person can get lost in refactoring, turning a one-day activity into three weeks of hacking, with no guaranteed results.

Some legacy systems, though, are so arcane, so toxic, that the safest thing is to get in, make changes, and get the eff out before anyone gets hurt.

This is the kind of system that may require the Tourniquet.

When You Don’t Need A Tourniquet

Just as in real life, if you need a tourniquet, things are dire. For the sake of the larger system, you’re cutting off a section of code.

You don’t need the Tourniquet if you’re writing new modules or if you have any practical way to refactor or rebuild the problem systems. Use it sparingly, and always as part of a larger improvement plan.

An Example: Man-Purse Purchasing System

Our man-purse store has a purchasing system we inherrited from the previous owner. It’s gnarly, and was written with total disregard for human life or maintainability. It’s interface looks like this:


class MPPS():

    def __init__(self, a, x, qw="default", roching="", extra=True):
         ...

    def buy_it_now(self, itema, itemb, opt_itemc, coupon="FX"):
        if self.isnt_debugging:
            self._do_spanish_purchase()
        else:
            if self._has_blue():
              ...
        # and so on for ~ 1000 lines or so

This kind of setup makes it almost impossible to cleanly add new features, especially when that module gets to be a few hundred or thousands of lines long (please, stop sighing in disgust, you know you’ve seen something like this).

To apply a Tourniquet, we might pull out the calls we know about and make them easier to call:


class PurchaseHandler(object):

    def __init__(self, legacy_purchaser, new_purchaser):
        self.legacy_purchaser = legacy_purchaser
        self.new_purchaser = new_purchaser

    def buy_hat(hat_sku):
        """a new feature! we sell hats now

        """
        self.new_purchaser.buy(hat_sku)

    def buy_spanish_purse(purse_sku):
        """an old feature, but with a cleaner interface.

        """ 
        self.legacy_purchaser.isnt_debugging = True
        self.legacy_purchaser.buy_it_now(purse_sku)

    def buy_other(self, a, x, qw="default", roching="", extra=True):
        """ support the old gross interface until we're done porting it all

        """
        return self.legacy_purchaser.buy_it_now(a, x, qw, roching, extra)

In this case we’ve picked out a case where the new feature is added, and we leave the rest of it alone, making better interfaces where possible, or just acting like the old module everywhere else.

Over time, the newer, cleaner methods should replace the older ones. The Tourniquet has given us a place to start to gradually and safely make things better.

Hey, You’re Just Hiding BAD CODE

Life is full of hard choices. If we had unlimited time, we could bite the bullet and re-engineer systems from the ground up as they mature. Sadly, we almost never have that luxury. This pattern admits that the code is bad, but at least provides a clean cut from which to build newer and better stuff.

Two Developer Perspectives on the AWS Failure

2011-04-27T02:27:16Z

Yes, Amazon’s recent issues were a bit of a spectacle, but a couple of posts I read went beyond the typical Nelson-esque “Heaaaah Haaaa” and looked at things from the perspective of those who design and run the client systems.

Y’all Got What You Deserve

Ted Dziuba’s post indicates that you relying upon the cloud is destined to fail.

Pain is nature’s way of telling you that you have just fucked up. It’s a hint to your future self that maybe you should never do that again. Yet, you dumbasses continue to host things full-bore in Amazon.

Amazon — The Purpose of Pain [Ted Dziuba]

We’re Living Proof

Jeff Attwood illustrates Netflix’s counterexample, VERY interesting because Netflix has a program (on purpose!) that runs around destroying things to make sure it’s all fault-tolerant. Pretty gutsy…

Which, let’s face it, seems like insane advice at first glance. I’m not sure many companies even understand why this would be a good idea, much less have the guts to attempt it. Raise your hand if where you work, someone deployed a daemon or service that randomly kills servers and processes in your server farm.

Working With the Chaos Monkey [Coding Horror]

Where's The OFF Switch on This Thing?

2011-04-02T00:00:19Z

As I enter the golden years/era of my software-rigging career, I find that I REALLY value having a convenient off-switch for new features.

If you’re working in a shop of moderate to large size, chances are you can’t get code changed in the production environment in under 30 minutes and without considerable stress. This is when it pays to have a toggle switch to enable and disable your feature/site/nuclear-release-countdown.

It’s one of those things that’s easy to build but often ignored. When you have the off-switch, you take some of the stress out of production moves.

If things start going south, you just flip the switch and reassess. You don’t need to back out an entire release, or run around screaming for an hour and a half, trying to convince people that your changes need to be backed out or hacking a hasty patch.

No More Parking Lots

2011-03-21T20:12:33Z

When you have meetings, do you make a “parking lot”? A section of the whiteboard where you put unanswerable questions that arise during the meeting? Try making a to-do list instead.

The difference is subtle but important. A parking lot is a list of shoulder-shrugs. It’s codified procrastination. Parking lot items say “We don’t know but surely someone will figure this out later”. You might even write them down, but what are the odds someone will follow up?

Better to define tasks that resolve the questions.

For example, a parking lot item might read

“Do we need to support multiple languages and locales?”

This is bad because it’s not clear how this can be answered, or who’s supposed to do it.

A better to-do would be

“Ask Joel Q if we need to support multiple languages”

Maybe also stick on a post-it identifying who’s going to do it. Now you’ve got a good idea of what’s going to happen next and solve the mystery.

This applies to lots of other items, too. Ever make a list of “Areas for Improvement”? Instead nebulous problem statements like “Too many bugs”, use actionable to-do’s like “Ensure all test cases pass in the test environment before moving on to the next feature”.