There is no such thing as a small change

“We want to limit the length of a review in the product to 140 characters, because we may want to use SMS at some stage. That’s a small change, right?”

Wrong.

There are no small changes when you’re committed to delivering quality software. Let’s look at the above case. A naïve programmer may well get this coded in three minutes—after all it’s just an if-statement.

A background in consulting, where you are paid for your time, teaches you to ask a few questions before proceeding with ‘small changes’. Let’s start with some easy questions.

What happens when the review is above 140 characters? Do we crop the string, or display an error message to the user? If we display an error, where does it appear? What does it say? Who is going to write the error message? How do we explain to the user why we’re limiting them to 140 characters? How will these errors look? Do we have a style defined? If not, who is designing it?

But wait, there’s more…

In the unlikely event that we have answers to hand for all of the above concerns, we’re still not finished. Just doing this server-side is a messy way to handle an error. We should do this client-side. But if we’re going to do client-side validation then I’d have a few more questions…

Who’s writing the JavaScript? Does the JavaScript display the same type of error as the server-side code? If not, what’s the new style? How does it behave without JavaScript? How do we ensure that any new update to the 140 character requirement affect both client-side and server-side validation?

We’re still not done. Look at this from a users point of view. They’re already frustrated by having to limit a review to 140 characters for a bizarre reason they won’t understand, and now we’re asking them to guess how long their message is? There must be a better way. Let’s give them a character counter. Oh, well that raises a few more questions…

Nearly there…

Who is going to write this character counter? If we’re using one we found on the net, then who wants to test it in our target browsers (i.e. not just Chrome 27 and beyond).

Also, where is the count of letters displayed on the screen? What does the count look like? Of course, the style should change as the user approaches zero characters, and should definitely look erroneous when they’ve used more than 140 characters—or should it stop accepting input at that point? If so, what happens when they paste something in? Should we let them edit it down, or alert them?

When we’ve implemented the character counter, styled all the errors, implemented the server-side validations, and checked it in all of our supported browsers then it’s just a case of writing tests for it and then deploying it. Assuming your time to production is solid, this bit will be straightforward.

All of this happily ignores the fact that users will wonder why someone wrote an eighty word review just before them and now they’re only allowed write a 140 character one. Obviously we’ll need to keep support in the loop on this, and update our documentation, API, iPhone, and Android apps. Also, what do we do with all the previous reviews? Should we crop them, or leave them as is?

Don’t get me started on how we’re gonna deal with all the funky characters that people use these days… good luck sending them in a text message. We’ll probably need to sanitize the input string of rogue characters, and this means new error messages, new server-side code… the list goes on.

Once you get through all of this you will have your feature in place, and this is just for a character count. Now try something that’s more complex than an if-statement. There are no tiny features when you’re doing things properly. This is why as a UX designer you need a good understanding of what it takes to implement a feature before you nod your head and write another bullet point.

You can’t be serious…

Yes, this was a rant. Yes, most of the above decisions can be made on the fly by experienced developers, but not all of them. Yes, you can use maxlength, but this only addresses one of the points above, and even then only in an HTML5 context.

Often what seems like a two minute job can often turn into a two hour job when the bigger picture isn’t considered. Features that seemed like ‘good value’ at a two minute estimate are rightfully out of scope at two hours.

Key point: Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.

Agreeing to features is deceptively easy. Coding them rarely is. Maintaining them can be a nightmare. When you’re striving for quality, there are no small changes.

Red means stop, green means go… snow means…?

One more example to remind you that there is no such thing as a “small” change.

LED lights are an excellent lighting solution due to their longevity and power efficiency. Replace all traffic lights with LED lights, “small” change right? Wrong.  It turns out that they may not be the best choice in all conditions. Normally, the excess heat generated by incandescent bulbs is enough to melt the snow off lights so that they remain visible even in freezing conditions. Traffic lights that employ LED lighting, while far more power efficient and reliable than older ones, aren’t able to melt the snow that accumulates.

Snow blocking traffic signals is a significant problem as it has already led to dozens of accidents and at least one fatality.

Aside

University

Universities used to be centres of learning. Now most of them are corporations with huge marketing divisions, massive administration costs, crazy slogans, a fixation with dodgy rankings, an obsession with what is often low grade and banal research and an increasing reliance on casual low-cost staff. Otherwise it’s all good!

Aside

Data Availability

Today’s businesses depend heavily on their databases. Should applications and data become unavailable, the entire business may halt. Revenue and customers may be lost and penalties may be incurred. Bad press can have a lasting effect on both customers and stock prices. Certainly, providing continuous data availability is essential for today’s businesses.

Quote

Engineering

The great liability of the engineer compared to men of other professions is that his works are out in the open where all can see them. His acts, step by step, are in hard substance. He cannot bury his mistakes in the grave like the doctors. He cannot argue them into thin air or blame the judge like the lawyers. He cannot, like the architects, cover his failures with trees and vines. He cannot, like the politicians, screen his shortcomings by blaming his opponents and hope that the people will forget. The engineer simply cannot deny that he did it. If his works do not work, he is damned. That is the phantasmagoria that haunts his nights and dogs his days. He comes from the job at the end of the day resolved to calculate it again. He wakes in the night in a cold sweat and puts something on paper that looks silly in the morning. All day he shivers at the thought of the bugs which will inevitably appear to jolt its smooth consummation.

On the other hand, unlike the doctor his is not a life among the weak. Unlike the soldier, destruction is not his purpose. Unlike the lawyer, quarrels are not his daily bread. To the engineer falls the job of clothing the bare bones of science with life, comfort, and hope. No doubt as years go by people forget which engineer did it, even if they ever knew. Or some politician puts his name on it. Or they credit it to some promoter who used other people’s money with which to finance it. But the engineer himself looks back at the unending stream of goodness which flows from his successes with satisfactions that few professions may know. And the verdict of his fellow professionals is all the accolades he wants.

-Herbert Hoover

Quote

Science

Jessica Flack: I believe that science sits at the intersection of these three things — the data, the discussions and the math. It is that triangulation — that’s what science is. And true understanding, if there is such a thing, comes only when we can do the translation between these three ways of representing the world.

Aside

Microsoft

It’s hard to believe that Microsoft is 41 years old. In that time, its had its ups (think Windows XP with around one billion sales) and its downs (think Windows ME, which lasted for less than 18 months). But one thing that’s clear is Microsoft has cleverly re-invented itself, re-booted and disrupted its own business in a massive way. Some would argue Microsoft is now “cool” again.