Developing, Code and Context for Hobbies: Brewing

[Skip this part if you just want to read the article and not why I’m writing it]

The podcast This Developer’s Life is one I’ve enjoyed for some time now.  It’s a great NPR-styled show that looks to investigate various facets of the developer’s interaction with the world.  At the end of the most recent show on Faith (which I would suggest is about courage and not faith in a historical or religious sense) Scott Hanselman mentioned that suggestions for the show were welcome.  On Twitter I suggested the topic of hobbies being impacted by the the developer’s mindset and mentioned that it really impacted my brewing and cooking.  Since Twitter is public, Barry Forrest asked me to articulate my thoughts on this – and so I shall.

[OK, Start Here!]

Software development is very much about order, understanding, and taking complex ideas and breaking them down to their simplest parts.  It’s also about being lazy where you can [See also: Perl].  So ideally you’ll take a complex idea, break it down into its component parts and then write code that executes that complex code in the least amount of lines with zero bugs.  Ideally.  Reality is that it can take a lot of code and there are usually at least a few bugs.

The thing that was so hard for me to begin wrestling with as a software developer was the complex to simple conversion process.  The breaking things down to their bare components, and then breaking those components down to their raw concepts.   This is done so that you can go from a sentence or paragraph describing a feature or idea in written language to a working piece of software that does the very thing that was described (and hopefully more).

I have written or helped write dozens of applications and thousands of features in the 15 years of my career.  All of that was practice in craftsmanship, but as I grew as a developer I noticed that it was changing me.  It was changing my thought processes so that when I looked at any of my hobbies (music, photography, cooking, and more recently brewing) they were a rich set of components that I knew as a collection of steps.  Like classes that were called in order to write a played guitar piece, a coded photograph, a compiled dish, or an abstracted ale. I’m going to simplify this article by hammering out my thoughts on brewing as I think both Barry and Rob (involved in the Twitter discussion) brew.

The following ideas below may be out of order, they may have some assumed nuances, and they might need some clarifications.  Throw me a message in the comments and I’ll do my best to fix or clarify things.

Knowing Your Problem/Goal/Recipe

Brewing beer is not just making a beverage.  You’re not just trying to make something that can be consumed.  You’re trying to craft either a clone recipe, another brewer’s recipe, or your own creation.  You may be trying to improvise to learn ingredients, or you may be trying to hone in on an ideal you’re imagining, but haven’t brewed yet.  As a software developer I aim to have a user story that clearly states the outcome I’m after.  You don’t start coding until you know your goal.

You should not start brewing until you have a recipe (which is equivalent to a user story).  It might be an experimental recipe [this is one of mine], but even still you have a goal.  Your recipe helps set constraints and it helps you begin to set expectations.

Knowing Your Tools

Visual Studio, Eclipse, or Chrome Web Inspector are examples of tools that developers may lean on to help create better code, better programs, and have a good technique for debugging or understanding existing code.  As a brewer you have a brewing setup that involves a kettle, heat and any number of other vessels for getting the sugars from barley (or other grains), hops, and water into a state that the yeast can eat.  There are different techniques to brewing, but no matter what you’re doing – you need to understand the process and the tools involved.

I spent a lot of time investigating the processes available to me as a brewer before I started brewing.  My brother – who taught me how to brew – showed me the brew in a bag, extract kit, and all-grain/sparge methods in 2 days so that I could see how simple it can be, and how complex it can be.  I began reading heavily about what control I could have with the different techniques.  How hard would it be to make mistakes and corrections with each one?  What were the expenses with the different tools?

I started with brew in a bag because the tools required were fewer, the results were more controllable than an extract kit, and I could begin learning and experimenting through experience.  It didn’t take long for me to jump to an all grain/sparge setup, but when I did that I had to re-learn the tools at my disposal.  How did the vessels retain temperature?  How easily could I transfer liquids between the kettle, cooler (mash tun), and the fermentation buckets?

If I knew the keyboard shortcuts to maximize my efficiency in various development tools, I sure as heck worked out the same sorts of efficiencies in my brewing.  What configuration of my brewing equipment gave me faster transfers, better temperature control, and maximum extraction efficiency?  I had to learn my tools.  Consistency in results built trust in my tools.  My tools produced better beers because I knew them.

Knowing Your Process

In building my recipes I take into consideration that I’m going to need to have water at various temperatures at different times.  I’m going to need various grains (or sugars), one or more ounces of hops, and yeast.  I’m going to add them at different times.  I need to know when they are to be added, mixed, resting or whatever the step is.  In programming I’ve found that doing the exact same steps in the exact same order with the exact same tools will give me the exact same results. OK, I’ll admit that isn’t always the case, but it’s within a margin of error.  Home brewing is about honing in on those same results with the same process.

Testing the Outcome of Each Step

When brewing, and in coding, tests are there to inform you as to what’s going on in your code (or your brew).  If you test for starches in the water you’ll know you don’t have the sugars you need for the wort.  If you test for pre-boil gravity you’ll know you don’t have enough (or too much, or just right) sugars in the wort.  If you test everything as you move through your brewing process you’ll be able to learn your equipment better, fix (some) mistakes, and hone in the desired outcome.

Teaching the User

Software usability matters.  It matters in APIs, it matters in user interfaces, and it matters in the steps we present users.  Users have been taught how to access and interact with software for decades now.  Beer has been more accessible for much longer, however, many beer drinkers don’t have exposure to a diversity of beers and don’t understand many of the styles.  Walking users through features of software should not be required, but documentation should exist.  Describing appearance (color, head, carbonation level), flavors (malty, hoppy, bitter), aromas (grassy, piney, fruity, carmely), and textures (mouthfeel/viscosity) can really enhance the experience of the drinker of your beer.  Talking or writing about what makes this beer special by style, history, brewing process or ingredient list gives consumers access to parts of the beer that they may not have previous exposure to.

On more than one occasion I’ve helped talk people through IPAs and they’ve developed a taste for them.  I remember not liking the first 5 or so IPAs I had until I had an O’Dell Myrcenary.  It was like switching from Windows to OS X.  It felt weird until it felt right.  I’m still learning to love lagers and Linux.

Software development taught to me think about the steps, the context, the history, the user’s needs and all (or many) of the ways a problem can be broken down and solved.  It taught me about clean code.  Brewing has become a parallel process that has steps, context, history and user needs. I’ve seen how recipes can be created with complexity and nearly identical beers produced with fewer ingredients or steps [all grain vs. extract, or adding in DME to help get your gravity higher without a bigger mash tun].

There’s a lot I’m still learning about the craft of software development, and there’s a lot I’m still learning about the craft of brewing – but they’re the same.  Next time let’s talk about barbecue!

Windows 8, Internet Explorer 10 and Web Developers

I just got done reading the specs on Internet Explorer 10’s tablet ‘features’ in Windows 8.  This new set of features is incredible on the surface, but as a developer I’m flabbergasted that Microsoft has decided to ignore the de facto standards and now has created yet another touch/tablet interaction model.  I’m not flabbergasted a company would do that, because Apple did it with the iPhone and iPad to create the de facto standard that RIM (disclosure: I work for a subsidiary of RIM) and others have followed.  What this means for developers who are trying to reach the widest possible audience is that their web applications are going to have to choose between:

  1. Lots of branches in their code to handle every possible variation of event detection
  2. Send users away
  3. Attempt to use some open source or home rolled equalization library that tries to mask the differences (this way could lie madness)
  4. Give the users a lesser experience
  5. Create multiple versions of the same thing, each with their own special ‘per device’ sauce (this way also lies madness).

Maybe there’s another option, but I just don’t get why Microsoft has done this to devs.

Today BDConf wrapped up.  It’s targeted primarily towards mobile development and I had a chance to go to their first event in Grapevine, TX in March.  One of the things that they talked about was writing for an ever changing web audience that accesses your site/web application through any number of devices.  However, this sort of added complexity from a major player in the OS department means that one of two or three things is going to happen, and one of them isn’t going to be developer buy in.  I’m convinced that Microsoft is going to have to either adopt some method for giving developers a smaller amount of effort to reach their audience on a Windows 8 tablet, or they’re going to really hurt their end user experience.

I want to create interactive, 3D-space enabled applications with rich interactions that happen to live in a browser, but Microsoft is definitely not reaching out to developers to create a “bold”* new experience in IE10.  They’re not making it easy for end users to have a great, familiar experience.  If you’re switching from an iPad 1 or 2 to a Windows 8 tablet you’re going to get fed up, and move back to the iPad.  If you were to switch from the iPad to the PlayBook you’d be comfortable.  Microsoft has created a barrier to entry, and this is not a good move.  They’re distancing themselves from developers, and they’re distancing their users from rich content.

(update:) Don’t misunderstand me to think that all of what they’ve added to IE10 is a move in the wrong direction, but it’s just not cool that they added a bunch of new HTML5 standards support, and ripped the mobile/tablet market a new hole to support.

* Microsoft employees used the term “bold” numerous times during their announcement presentations today and many people in the media and on twitter noted this.

IE7 ClearType Gripe

I fully understand why Internet Explorer 7 uses clear type. Some people’s eyes work better with ClearType. It is simply an accessibility nightmare in my humble opinion. Actually, the problem is not in the ClearType – which works better on some displays than others – but it is in the Internet Explorer ‘Advanced Options’ dialog. If you’re a glutton for punishment take a glance at it [click on the screenshot below for a larger version].

As a designer please use consistent text to give users the simplicity of vocabulary.  If all of the options use enable or disable rather than both, this will help.  Worse is the ClearType option which says, “Use…”  that’s neither enable or disable and it makes the scanning of the text even more frustrating because its even more words your brain has to parse as you scan over the text.  If you design interfaces – please consider being consistent.  I have some software I need to update to take this into account, but please – all new software should be written with greatest usability in mind, and all older software should really be updated.

The Advanced Options Tab in Internet Explorer 7

The Advanced Options Tab in Internet Explorer 7

They Got it Right: TripIt Invite

I just got an invite from TripIt.com. Well, it was through TripIt.com, from my buddy Dave. When the invitation arrived it not only had a link, but it had a username (my email address) and password already in the email. Wow. The cost to click the link and join their social network was much smaller than sites where I know I’m going to be skating around forms for half an hour to get setup *cough* hotmail *cough*.

TripIt.com got it right. Now I just have to look for opportunities to use this same style, which I find QUITE inviting.

Write It Like You Want to Experience It

I dabble in the world of philosophy at times and one of the philosophical movements that I don’t participate in, but find interesting is existentialism. Experience is all that there is doesn’t suit me, but in the world of software development experience is all that there is.

  1. Does your software do what it says it can do?
  2. Does your software do that in a way that is simple?
  3. Does your software do it in a visually attractive way?
  4. Does your software do it in a way that is memorable?

For some folks these questions aren’t critical, but they help. I personally love to use certain pieces of software because they deliver on the promised goods, they’re simple, they’re attractive and most of all I remember them when I’m talking with others about software they may want to purchase. It isn’t grassroot software advertising that makes software catch on, its software that is designed well that brings about grassroot advertising.

The Double Save

I just finished proving my residency as a Colorado state citizen for some continued education. I needed to do this so that I didn’t have to pay out-of-state tuition fees of over $1000.00. While the staff at the Community College were trying to change my status to resident they went through all sorts of heck with generic error messages that didn’t help and java dialogs asking them if they wanted to try again until either their computer crashed, their computer became outdated, or the miraculous happened and things actually saved as they were supposed to (I am not making up the number 48 when I say they had to try 48 times to get things to save).

What really concerned me though was that the staff had been trained to get things to work by saving the information twice. You see the first save worked, but the second save refreshed the information from the database. Whomever coded the sorry Java/Oracle/Pergatory application was too lazy to write the code correctly and failed to understand the need to refresh tainted data. If people use your software please don’t train them to double save. It just isn’t worth keeping your code around if you work that way.

Please, Please,Please use alternative Text in HTML Email

If you’re like me you have subscribed to various email lists or advertising newsletters from specific company. You want to know about specific airfares when they’re being offered that may allow you to travel to destination X for a low rate. You also want to know when your next credit card payment is due. You get the emails from the companies and your modern email client (mine is Thunderbird) blocks the external images because they’re sometimes used by spammers to track legit email addresses. The blocked images, if they don’t have alternative text, give you the broken image symbol in the email and the ‘buy now’ link is just a broken image and nothing indicates that you should be able to take advantage of the lower fares from within the email. In essence their whole plan to draw you in has failed miserably because they have failed to do something that is so simple that even spammers have figured it out.

Please use Alternative Text

What do the links above go to in the original email? I can’t tell. And if I was blind or visually impared and wanted a screen reader to tell me what they go to? Tough. SilverPOP, the service that sent this email out doesn’t care about its customers enough to actually put in descriptive words that would tell me what those links go to.
Now with images

Thunderbird adds a button to show the images in the email when it has blocked the images. However, it is possible that the images contain text that a screen reader will still not see. This is the kind of stuff that would be easy to do, and add value to the email for EVERY user who has images blocked, a restrictive proxy server, visual imparement and or the email composer forgot to link to an external image and the URL is broken.

Think twice and add alternative image text, it could be effecting your bottom line!

Search Engine Optimization Verses Usability

Recently a client of mine hired a search engine optimization (SEO) company to help get their site optimized for search engines. What blows me away is that sometimes practices that may help in ranking a little bit blow the crud out of usability. One recommendation the company made was to use images and have ‘alt’ attributes to help increase ranking. However, the client’s site is already heavy on the graphics and so if they add more images they will actually increase the download time so much that users will need a personal vacation to the water cooler, a trip to the bahamas or maybe could serve a life sentence in San Quentin before the thing loads up.

If you want to get good search engine ranking, do yourself a favor, hire a designer who knows symantic markup, get a nice design that folks might just link to for the appearance, and keep it clean. Write good content that the search engines will eat up, people will link to, and that informs actual readers of valuable information. None of what I’m writing here is new, revolutionary or a secret, however, SEO firms insist on magical markup and stupid hacks. Wake up folks!

I Agree!

How many times have you had to click some checkbox somewhere that confirms that you agree to the end user license agreement (EULA)? Well, Sony, in an act of sheer brilliance has done something that I hope evey single software vendor will do:
They’ve turned the ‘Next’ button into the Agree button.

Witness the screen shot of their cell phone SDK installer:
I Agree
I have reduced the size of the image but overlayed the button row for higher legibility

Can Vs. Should

Recently a support request for WordPress came up on the wp-hackers email list I subscribe to that reminded me of one of the big delimas of programming (and frankly much of life): If you can do something, should you do it? There is a big, and valuable, movement in web design called contingency design. This design approach says, “Given Murphy’s Law of things going wrong, what can we do to prevent that from happening?” In general this is a good principle. However, it is not a law. You need to find areas that are useful for your time, things that help where 90% of the people will need it. In programming misconfigured machines can cause ‘bugs’ that are really just the result of a misconfiguration. In design it is possible to spend extra hours working on things that do not help the end user because only 1 person in 10,000 will ever do what it is you’re working on and they don’t need to do it.

This is basically an issue of prioritization and evaluation of what is vital and what is extraneous. Sometimes in interface design choices are made that make the development process quick, however, the end user is not thought of. In this case usability is so bad users might not use the feature at all. In other cases users might misconfigure the software simply because the interface is poor. Make priority judgments based on:

  • Quality
  • Cost
  • Time

Note:Thanks David O’Hara for showing me this ‘triangle of evaluation’
Realize that you usually can’t have something that is of the the utmost quality in a very small amount of time, or that if you design something that takes more time to develop because of quality needs, the cost will go up.

Just because you can do something doesn’t mean you should do something.