<!-- Content Here -->

Just say no to standups

I never liked regularly scheduled standup meetings. They interrupt your flow. They are boring because most of what is said has nothing to do with you. When an interesting topic does come up, the standup quickly transforms into a meeting-meeting that holds uninterested parties hostage. Standups are lame.

The good news is that, thanks to tools like Slack and Hipchat, we don't need to suffer through standups anymore. For around a year, my development teams having used ChICO (Checkin/Checkout) rooms. I got the idea from this blog post by Zsolt Kocsmarszky. When team members check in, they report what they are working on, who they need to work with, and any blockers they foresee. When they check out, they report what they accomplished and their plans for the next day.

This approach has multiple advantages over the classic standup.

1. It does not need to be synchronous.
   People report in and read at a time that works for them. They are alerted when a new announcement is made and can check it in their next stopping point.
2. It is scannable.
   You can scan over information that is not relevant. 
3. It is self documenting.
   Nobody needs to capture minutes or take notes.
4. It works well for geographically dispersed teams.
   Nothing is worse than a "phone standup" and, when timezones are involved, there is no good time to have them.
5. It cuts across language barriers.
   This may be the biggest one for us. My team's written English skills are great but the spoken word is challenging due to accents and "buffering" (when the time it takes you to decipher a word and recall it's meaning makes you fall behind). Removing that barrier has brought my teams closer together on both personal and professional levels. 

In-Context Review: Know the Power of Your CMS

I am blogging again (sort of).  Here is a post I wrote on the Lionbridge Blog about reviewing content in your CMS. Crazy. I know. But you would be surprised how many people think you should be reviewing content outside of their CMS.

Internet Explorer Support

I tend to be more aggressive than most when it comes to ending support for outdated browsers. As I mentioned in this article about ending IE6 support 5 years ago, supporting old browsers is not worth additional cost and drag on innovation.

I am happy whenever I see a big web property end support for an old browser, but I was absolutely thrilled to see that starting on January 12th 2016, Microsoft will only support the most current version of Internet Explorer available for their supported operating systems. This means:

• IE8 and lower will be practically dead. It will only be supported on some embedded versions of Windows.
• IE9 will only be supported on Windows Vista (remember Vista?), which will lose support on April 11, 2017.
• IE10 will only be supported on older versions of Windows Server.

Even better, whenever Microsoft launches a new version of Internet Explorer, the older versions immediately lose support on mainstream desktops (and probably phones and tablets too).

Thanks Microsoft! It is a lot easier to stop supporting a browser if the software vendor behind it has also abandoned it.

Does the average user prefer multi-factor authentication to expiring passwords?

I was doing some anecdotal research about password security preferences and I was surprised to find that most of the people I talked to favored two-factor authentication (using Google Authenticator) over expiring passwords. My survey pool consisted of project managers who I think are pretty typical enterprise software users. Around half of them had not seen two-factor authentication until I showed it to them. The general attitude was that anything is better than expiring passwords — an opinion that I agree with.

Are my colleagues unusually geeky or is this a trend that other people are seeing as well? If you have experience, research, or intuition around this, I would love to hear from you. @reply me on Twitter: @sggottlieb if you have something to say.

Double International Snapshot

Last year I wrote a post about two deployment patterns to prevent source language bleed through when using a transaction proxy. If you don't want to click through on the link, source language bleed through can happen when a visitor views a page with text that has not been translated yet. Most translation proxies have an option to use machine translations for untranslated text but this is not always desirable.

In our experience, the "International Snapshot" pattern works very well as long as the customer is willing to freeze their content while the site is being translated. Without a content freeze it impossible to make the site completely translated. You never know when a content editor is going to publish a new string. It is also inefficient because the translators might need to translate text that is only on the site for a few hours. For example, a translator might be sent a task to translate a sentence with a typo that will be corrected in a matter of minutes.

But not everyone is willing to interrupt their publishing flow. Thanks to the wonderful world of content management systems, people are used to being able to publish whenever they want. To accommodate customers who have no tolerance for bleed through or content freezes, we have started to apply a new pattern that I call the "Double International Snapshot." This pattern is identical to the "International Snapshot" pattern but has an added layer of a translation instance which effectively freezes the content for the translators.

In this pattern, you have three instances of the site:

1. The Original Site that is serving your source language visitors today. This site can be updated regularly for the benefit of source language visitors.
2. A "Translation Snapshot" that is a point-in-time snapshot of the Original Site. This site provides a stable environment for new content discovery and staging translations.
3. An "International Snapshot" that is a point-in-time snapshot of the Translation Snapshot. This is the site that your target language visitors will hit through the proxy.

The translation process works like this. When you think it is time to refresh the translated sites, you refresh the Translation Snapshot. This freezes the content for the translators so that they can complete their work without new content constantly appearing. The Translation Snapshot can be finalized and go through all sorts of testing to make sure that it as perfect as it needs to be. Once you are satisfied that the Translation Snapshot is production-ready, you refresh the International Snapshot from the Translation Snapshot. Because the translations for the new content are already in the proxy, there will be no bleed-through.

The Double International Snapshot allows content editors to constantly publish new content to the source language site without compromising the stability of the translation environment. The translated sites can be fully verified for translation completeness and quality before going live. This pattern is an ideal solution for companies that don't want to risk source language bleed through but are not willing to compromise publishing freedom. But these benefits are not without cost, you do need to host three versions of your website and you need to build mechanisms for maintaining these snapshots. The Translation Snapshot site can be relatively low powered because it will get only a limited amount of traffic. If your site is simple and does not have any runtime server-side logic, both snapshots could be static HTML files hosted on Amazon S3. This can be done pretty easily with GNU wget.

The Three Worlds of a Product Manager

One of the most challenging aspects of being a product manager is that your mind needs to simultaneously exist in three worlds — three different realities: the present, the near future, and the distant future. Let's go through them one-by-one.

1. The Present
   This is the state of the product that everyone is using right now. To the product manager, however, the present feels like the past because it contains features and characteristics that he thought through long ago. The most relevant function of the present is as a tool to learn more about users and decide what the near future should look like.
2. The Near Future
   The near future feels like the present because it is the world that the product manager's mind spends most of its time in. The product manager is looking at mockups and prototypes and thinking about the sequence of when to deliver near future features. If you follow lean product development, release cycles are short and the actions are pragmatic and concrete. The picture of the near future is clear enough that it feels like present day. We do weekly releases so the near future can be real this week, the next, or the week after. If you use feature flags, the near future may be the current state for some users.
3. The Distant Future
   The distant future may not be that far away on the calendar (maybe a few months), but to the product manager, it is science fiction. The distant future never arrives; pieces of it merge into the near future but the rest keeps on being pushed off. Because knowledge and priorities are constantly changing, the product manager can't get too attached to the distant future. More than likely, the product manager is juggling multiple possible distant futures simultaneously in his head. The whole purpose of the distant future is to put the near future into a larger context and to force the product manager to extrapolate where decisions for the near future may ultimately lead.

Your product exists in a different state in each of these parallel universes and you need to know every detail about each of these states because people look to you as the expert. It is hard to keep these details from getting muddled together in your head and harder still to not confuse others as you talk about the product.

The hardest time to avoid confusion is when discussing a product road map. The best approach is to talk about the near future. Stick to three months or less with the details weighted towards the first month. With this horizon you are safe to talk about sequencing and dates but the most important topic is "why?" You are rapidly responding to an opportunity, testing a hypothesis, or incrementally building towards something bigger. The reason for an enhancement should fall into one of those three categories. Describe the distant future as a vision that influences your general direction. Don't commit to details or dates. You just need to paint a picture that shows that the next steps in the journey are worth the effort.

The other time when the three worlds confuse stakeholders is when they request a feature. Often what they ask for fits into a larger vision. For example, they might ask you to fix something that you plan to replace with a different approach. You need to adjust your perspective to their present (which feels like your past) and then take them through time to show your plans for the near future. You might also need to take them forward a few releases more to describe how you want that feature to evolve.

Navigating back and forth across the present, near future, and distant future feels a lot like time travel. It is disorienting when you context-shift into a particular time period and sometimes the past feels a little embarrassing when you come back from the future. Like a hero in a time travel movie, sometimes you need to repair the future by going back into the past. There is never a dull moment in product management. If you think things are boring and routine, you need to get your mind over to where the action is.

Drupal is to web development as Powerpoint is to design

I was recently talking with a friend about how hard it is to find a good Drupal developer. While Drupal is the second-most widely used CMS, finding developers who know how to work with it properly is really challenging. I think there are three reasons for this.

1. Drupal is so ubiquitous that most PHP developers have had at least some level of exposure to it.
2. You can get a lot done in Drupal without knowing what you are doing.
3. Most of the people hiring Drupal developers are not able to evaluate the quality of the work.

In thinking about this, an analogy came to mind:

Drupal is to web development as Powerpoint is to design.

PowerPoint is everywhere. Anyone who knows a little bit of PowerPoint, and can search the web for images, can convince himself that he is an adequate designer (or at least a good visual communicator). But the more you care about design, the more horrifying these amateur presentations are. PowerPoint itself isn't bad. If you do have good design skills, PowerPoint can be an incredibly powerful design tool. But there are more bad designers working in PowerPoint than good designers.

Similarly, Drupal has a huge library of modules that you can install and configure about as quickly as you can drop an image onto a slide. An expert Drupal developer will know what modules to use, have good judgement of when to use them, and have a solid process for testing and managing configurations. A Drupal amateur is unaware when he is creating a mess that is going to create embarrassing situations in the future.

So how do you separate the wheat from the chaff in the Drupal developer ecosystem? I tend to focus on three areas:

• The types of sites the developer worked on. Wrong answer: "I build Drupal sites all the time."
• How the developer finds modules to use. Wrong answer: "I just search for them."
• How the developer manages configurations across environments. Wrong answer: "I just click boxes."

By asking these three questions, I can usually get an idea of expertise and craft that a Drupal developer applies to his work. Happy hunting!

Rediscovering Private Chat

A few weeks ago, I moved my development team from Skype to HipChat for chat-based collaboration.  All the buzz around this new breed of collaboration services (such as HipChat, Slack, and Flowdock) was making me curious.  I had used private chat room technology like IRC and Jabber in the past with mixed results.  I also used to work for a company that made a product called MindAlign (which looks like it has been frozen in time since 2004).  In every case, these services were initially popular and then people drifted away to other tools such as AOL Instant Messenger (AIM), Yahoo! Instant Messenger (YIM), Microsoft Messenger, and Skype.  People preferred consumer chat services because you can also use them to communicate with your non-work friends. Nobody wants to run more software on their computer than they need to.

Times have changed. YIM and AIM are basically irrelevant only to be replaced by tools like Apple Messages, WhatsApp, and Viber.  But I think that there are bigger differences in play.

Smartphones have conditioned us to multiple channels

Now pretty much everyone runs at least two computers: a workstation on our desk and a personal computer in our pocket (our smartphone).  These two computers have different roles.  Your workstation is very clearly for work and your smartphone is focused on digital communications.  The smartphone has the best chat network of all (SMS because it is ubiquitous) and it is easier to use now that we have a keyboard.   The new chat services (WhatsApp, Viber, Apple Messages, Facebook Messenger) are all focused on the smartphone market.

Chat-based collaboration tools like HipChat don't have to compete with personal messaging services. It is easier for them to coexist because they live on separate devices.

Twitter and Facebook have built new habits

Integrations make chat collaboration tools more powerful

Why change?

Back to Blogger

In case you noticed something different, I moved this blog back onto the Blogger platform. Actually, Blogger is where Content Here started back in 2004 (Wow! A little over 11 years ago!). Over the intervening years, I converted the site to Wordpress and hosted it on a number of different providers. Some of the formatting shows that the posts are a little worse for wear.  And I need to do some theming work.  If you notice any other major problems, let me know.

Data ownership and control were the primary reasons for moving off of Blogger. When my website was a core part of my consulting business, $20.00 per month seemed worth it. Now that blogging is back to being a hobby and Google has a "Data Liberation Policy," Blogger makes more sense. 

Moving from WordPress to Blogger definitely feels like going against the grain but this article "How to Move Your Blog from WordPress to Blogger" gave excellent instructions plus a good explanation of why you would want to do it.

In addition to great utilities for both Blogger and Wordpress, one of the things that made migration easier was that I hosted all of my images and files on Flickr and other sites.  That means that there was less to move.

My experience so far is that Blogger seems like a less cared for part of the Google ecosystem.  It's clunky when compared to Wordpress or other web content management systems that I have used. I am sure that Google+ (and before that Google Wave) have consumed most of the attention.  I can't imagine that Google would kill blogger, but if they do, there is always Google Takeout.  

Nan, you are not a number

Here is a little programming oddity that we ran across yesterday.

onDemand has a number of downloadable Excel reports. To generate a useful Excel file, it is important to tell the Excel library what data type to make each cell. To facilitate this, we had a little utility function called is_float:

def is_float(data):

    try:
        float(data)
        return True
    except Exception:
        return False

That seemed reasonable enough and it worked fine for quite some time. But then we had this customer named Nan (thanks for the business Nan!). The problem with the name Nan is that float('Nan') doesn't return a ValueError like float('Bob'). float('Nan') successfully returns a float object with a value of 'nan.' The reason for this is that Nan, in addition to a being fairly common name (I went to school with a girl named Nan), is Python shorthand for a "Not a Number." Python's float function interpreted the input 'Nan' as an attempt to create a float object with a value of 'nan'. This caused our logic to try to tell the Excel library that 'Nan' was a number and that created an error. Incidentally, we would have had the same problem with someone named "Inf," which is Python shorthand for infinity.

In case anyone is curious, the fix for this was quite simple:

def is_float(data):

    try:
        int(float(data))
        return True
    except Exception:
        return False

The int function doesn't try to be as clever. It rejects cheeky floats like nan and inf. You learn something new every day!