When I Say No, I Feel Silly

| Comments

The main point of making software is to produce things people want, right? But sometimes saying “no” is important.

I’ve noticed a trend when trolling Atlassian’s bug/feature tracker. There are features requests in there that some users (paying customers!) have been demanding for several years. My favorite example is a feature request to allow admins to disable comments on Confluence wiki posts. The response from the Atlassian employee is fairly sublime, and worthy of reproducing in its entirety:

After much discussion we’ve concluded we won’t be implementing this feature request. Our goal is to continue to simplify the product, by focusing on building for the majority of our customers. Whilst the ability to disable comments on a specific page or blog is a completely valid feature request, we believe it just crosses the line in terms of adding an extra level of complexity to the product and is a use case that isn’t catering for the majority of our customers.

This is a very diplomatic way of saying “Yes, that is a good idea, but no, we won’t build it”. Think about the focus it takes to say this. Some customers will consider this a “must have”, and so Atlassian is almost certainly leaving money on the table. But in the long-term, they’re not adding complexity they don’t want to support. Plus, they may not want to even have clients who can’t live without this feature, thus avoiding the need to fire them.

I have a favorite kind of chart. I’m positive it has a name among statistics people, but I call it the “Show me a line comparing yesterday to today” chart. I first spotted it on Facebook’s platform status page. Along with other system notes, this page shows two charts of statistics comparing the past six hours of today to the same window of time from yesterday.


A Non-Expert Can Spot Changes and Problems

I love this flavor of chart because it’s easy for non-experts to spot when something is up. You don’t really need to know what the lines are measuring to see that “things changed right THERE”. Almost anyone can help monitor your system, and you’ve lowered the barrier for participation. People won’t be discouraged from helping because they aren’t experts.

People are lazy. When given a table of statistics and numbers every day, they eventually stop paying attention. It takes effort to interpret those, and if they rarely change, it’s even harder to keep doing it.

You can put a today vs. yesterday chart up on a screen where everyone can see it and count on at least a few people to glance at it daily, and maybe even raise the alarm if something strange appears.


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 fairly close attention to how code is depicted in films and TV shows.

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’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:

  1. Renewed Motivation - being surrounded by nerds facing similar problems is always good for morale. You are not alone.
  2. 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.
  3. Networking - You’ll meet people. Good people. These are folks that you’ll tweet, email, and Link-in. This is a good thing.
  4. 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.


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

| Comments

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

| Comments


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 Attribution Some rights reserved