<!-- Content Here -->

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!

Priorities

Prioritizing is hard when other people's requests fight for your attention. It is stressful. You feel attacked; and when you constantly shift your priorities in response to whoever cries the loudest, you get nothing done and you feel defeated. As hard as it is to prioritize your own time, prioritizing what to improve in a product is even harder. The decisions you make on a product have such a large impact. Living under this stress of competing priorities is the life of a product manager. Here are some tricks that I learned.

1. Create and publish a model for prioritization.
   My prioritization framework looks like this. Being transparent about how you prioritize serves three functions: it sets expectations; it encourages stakeholders to express their requests in terms that you can easily evaluate; and it forces you to adhere to your own rules.

2. Don't elevate the priority of one request. Push everything else down.
   It is easy to fall into a cycle of urgency inflation where each request tries to one-up the others in priority. Hysteria builds and you go into reaction mode as you try to keep up. When I feel like this, I try to visualize calmly but firmly pushing other requests down. You only have so much capacity. The highest priority thing should be whatever you are working on right now. It can't get any higher than that. Everything else will have to wait. It feels empowering to actively push requests down to make room for the one request that cannot be deferred. The alternative is passively accepting every request's own self stated importance. That feels horrible.

3. Group niggling little things into a single item.
   One risk of prioritization is that some of the little things never get done. Individually, these details never get to the top of the stack. But in aggregate, they do matter. User experience is all about the details — sanding down the snags that get in the way of delight. To solve this, I like to group some of these requests together to give them a fighting chance against some of the larger initiatives.

4. Strive for continuous improvement rather than immediate perfection.
   Your application is not perfect today and, no matter what you do, it will not be perfect next month. Rather that succumbing to the pressure of immediate perfection, focus on continuous improvement. One of my favorite articles about product management is "Make it Suck Less." While this sounds like an overly humble goal, software would be a whole lot better if every application was managed on this principle. Besides, if you achieved perfection, your job as a product manager would be over.

5. Take a moment to celebrate your achievements.
   After you launch a new feature, resist the temptation to immediately jump to the next thing. Get closure by reflecting on what you accomplished. This will help in two ways: it will get you off the treadmill for a moment to enjoy your success; and it will allow you to evaluate what efforts have yielded the greatest impact so that you can be even more effective with your prioritization. Personally, I find the best time for this reflection is when reviewing release notes before publication and when preparing for a team retrospective.

These practices work for me in product managing my own time. Hopefully you will find them useful too.

Too Dry Anti-Pattern

I do a lot of code reviews. On average, I probably spend an hour a day looking at diffs. I find this an efficient use of time because I frequently spot bugs that wouldn't be revealed by regular testing. I can also prevent implementations that will create obstacles as we progress through the road map.

One of the anti-patterns that I have started to notice is what I call the "Too DRY Anti-Pattern." For the uninitiated, DRY stands for "Don't Repeat Yourself". It is a primary tenet in one of my favorite books: The Pragmatic Programmer: From Journeyman to Master

. Keeping your code DRY means using methods and functions rather than copying and pasting code and not storing the same information in multiple places. I have written about DRY in terms of content management in this blog before.

The Too DRY anti-pattern starts with the good intention of keeping the code DRY. The developer creates a function or method to avoid having the same code exist in lots of places. However, over time the developer starts to use that function in places that do not quite fit. The function gets more parameters and has increasingly complex internal logic to control its behavior in different cases. Too DRY functions are easy to spot. They have lots of intricate if-then logic that try to address a wide diversity of usage.

A counter-weight to the Too DRY anti-pattern is the Unix philosophy of doing "one thing and doing it well." When you run into a Too DRY function, use the Unix "one thing" philosophy to break it down. Perhaps create smaller functions that do specific elements of the larger Too Dry function and then have different functions that use those building blocks in different ways. Also, repeating code isn't always a bad thing if the code is small and performs a discrete function. For example, if you have some code that creates an object and sets its properties, it is OK to have similar instances of this logic if the properties need to be set to different values.

Like all things, best practices need to be applied thoughtfully rather than as rigid rules. So keep your code DRY, but not at the expense of simplicity.

On Building an API

A few months ago we announced the availability of the Lionbridge onDemand Public API. While there are many translation APIs in the marketplace, I think that ours is the most comprehensive. Most translation APIs offer one level of translation quality (for example, machine translation or crowd translation or professional translation). The onDemand API allows you to select a translation type that meets your needs. This means that you can integrate with one API and give your customers lots of options. We also support many different content types. For example, we can translate videos as well as basic documents. Lastly, we offer different payment options. The end customer can pay themselves or the money can flow through our integration partner. I think these differentiators are responsible for the rapid adoption we are seeing. We already have around ten third party integrations in production or nearing completion.

Personally, this has been a huge learning experience. While I have used many APIs and even helped developed a couple, this is the first time that I designed one from a blank page. The sheer number of approaches, options, and details that you face is enormous. And although the biases formed from personal experience are important, what really matters is the developer audience — not just in the decisions you make but also how you support them.

I hate the term best practice but here are some of the things we got right. I must admit that we didn't always land on all of these practices the first time but when we adopted them, we definitely saw results.

• Learn from others. When first designing the API, I drew inspiration from other APIs that I liked to use. I also found great information from George Reese's The REST API Design Handbook.
  
• Get feedback. When first designing the API, I had the benefit of knowing who the first customers would be. I wrote the initial specification in a Google Doc and invited feedback. The first partners caught some important omissions and had some great ideas too. I also had different developers review the specification before development started.
  
• Be pragmatic about change. An API is a contract. It shouldn't change. However, in the early going there were a few cases where it made sense to change the specification. This was inconvenient and awkward for developers who are starting their integrations. However, it was much less painful than making changes later when the install base is bigger and changes would break working systems. Managing these changes requires a lot of humility (admitting you are not perfect) and effort to rebuild trust. Once the lead integration partner was getting close to being feature complete, however, we did lock down the version of the API and saved our changes for subsequent versions. Since the initial launch of the API to our beta partners, we have launched another version and are now working on a third. We handle versioning with an HTTP header so it is easy for a client application to update the version to get access to the new feature.
  
• Hire your first client. While any early beta customer will need to accept some level of instability, you don't want to risk a partnership with your earliest growing pains. For this reason, we hired a contract PHP programmer to develop and test code samples for working with the API. This external developer had no more access than a true partner developer would have. The experiences of this developer gave tremendous insight. It exposed ambiguity in the documentation where the API implementer interpreted different meaning than an external reader. It revealed cases where the test passed but externally developed code didn't work.
  
• Give client developers a plan of action. Like with most API's the hardest part of working with the onDemand API is authentication. For this reason, we recommend a development sequence that starts with the easiest API: List Services. We also wrote up a quick tutorial with a code sample to help. For our beta developers, we created a project plan template that developers could follow. It contained tasks for integrating with the various features and rough time estimates. I was surprised to learn how much the developers liked this. Personally, I hate being given a project plan that I had no input over.
  
• Provide fanatical support. Even though I love software development, I am the first to admit it can be frustrating. It is easy for developers to get bogged down and stuck. The smoothest implementations we have had were when the dev team actively engaged the client developers. I admit that sometimes I felt like my time was being stretched too thin. But when you think about it, how can you get more leverage than helping a partner use your service and bring you business? I also enjoyed working with external developers. First of all, they are savvier than regular business users so you can rule out silly things like being disconnected from the Internet. Second, it was fun to troubleshoot with them as they sent requests and we inspected what onDemand received. Pinpointing errors can save a client developer a lot of time. This work had the side benefit of improving our error handling to provide more informative responses.
  
• Treat your development sandbox like production. This should sound obvious but a lot of services that I have integrated with have very unstable developer sandboxes. They are not always available and they have issues that you don't see in production. There is nothing more frustrating than trying to fix your code and realizing that the problem is in an external system you are integrating with. For this reason, we manage the sandbox as a production environment. It gets the same monitoring as a production environment and we release new code to sandbox after it has been in production for a couple of days.
  
• Test like you mean it. Software is incredibly picky about the slightest detail so API testing needs to be extremely thorough. You can't just verify that you are getting data back. The data you get back needs to be precisely like what is in the documentation. For this reason we do what I call double-blind testing. The development team writes tests that run whenever new code is merged into the integration branch. An external QA team writes and runs tests based on the documentation whenever we have a release candidate. The hope is that having two independent approaches will everything. When it doesn't, we have a major debrief.

If you do it right, an API can revolutionize your business by opening channels that extend your reach. But getting it right requires commitment and attention to detail. If you underperform in any aspect (design, implementation, or support) your program is doomed. You won't always get everything right but if you maintain your focus and address your failures, you can get things back on track.

Is Wordpress the Microsoft Windows of Web Content Management?

We run our corporate marketing sites on Wordpress. It's not the perfect web content management system for us but, as long as we keep things simple, it does the job reasonably well. When we want to do something that Wordpress doesn't comfortably handle, we tend to use an alternative platform such as Marketo, UnBounce, or develop static web pages.

Wordpress is great, but one thing to consider when using it is that you make yourself a target to all sorts of hacker attacks. When planning server capacity, we need to accept that a lot of our traffic comes from bots trying to hack into WP Admin. There are three things about Wordpress that contribute to this.

1. Wordpress is by far the most commonly used web content management system. According to BuiltWith, 47.90% of CMS powered websites run on WordPress. The second most commonly used CMS is Drupal with 13.10%. Now I know that those statistics are not perfect but it is clear that Wordpress is head and shoulders above the competition when it comes to CMS adoption.

2. Wordpress is incredibly easy to identify. If you look at the source of any Wordpress generated page, Wordpress's signature is impossible to miss. Moreover, Wordpress makes it really hard to hide these tells even if you wanted to.

3. Wordpress is the "go-to" platform for people who know nothing about web development or security. While there are plenty of savvy WordPress developers out there, the majority of WordPress sites were built by people with no clue about security and operated by companies with limited technical know-how. Many of these sites were insecure from day one and only got worse as patching and other maintenance practices were neglected.

Put these three facts together and it is obvious why WordPress is the most attractive platform for hackers and botnets to attack. If you are a malicious hacker and want to get the most out of your efforts, you go after the biggest and most vulnerable target. And in that way, WordPress is a lot like Windows. Windows is everywhere because it is the go-to OS for people who just want a computer at a reasonable price. If you walk into a BestBuy/Staples/Costco to buy a computer, you will walk out with a Windows PC unless you have something else in mind. The majority of these computer shoppers know very little about managing their computers. These users will not keep their software up to date and will accept any dialog. Most of us have spent countless holiday hours removing adware, browser bars, and viruses from these computers.

Just to be clear: Wordpress and Windows are not inherently insecure. With conscientious maintenance, both of these platforms can be as safe to use as the alternatives. It as a sign of success for both Windows and Wordpress that they have earned the distinction of being prime targets for hackers. It is also a great opportunity for external software companies to market services to secure these platforms. The Windows security software market is already large and mature. The number of Wordpress security options is growing fast.

So my advice to everyone is to keep on using Wordpress if it meets your requirements. But accept that your site will be a target for hackers and plan for security. Work with Wordpress specialists (not designers who happen to know a little about Wordpress theming). Follow all the advice in the "Hardening Wordpress" page. Look into 3rd party services that help protect your site. Be safe

Radio Silence

You might have noticed that I haven't been posting here much over the last year. More likely, you haven't noticed at all. Blogs are often like that. They come and go depending on the whims of the blogger.

The reason for my silence is that my focus has shifted from pure content management to lean product development, web application development, and cloud-base architecture. At Lionbridge, I have been helping to build a business called Lionbridge onDemand. It has been a little over a year since our first sale and I am in a constant state of amazement about how things are growing. Like most of my projects, we followed a lean product development model of launching a minimum viable product and continually improving it to support the needs of our growing customer base. In this case, we started with a tiny website to translate videos. Since then we have grown to the point where:

• We now have a wide array of services that support nearly 40 different content types. We even have services that do not involve translation at all such as proof reading and CRM data cleanup.

• There are enterprise sites for many name-brand clients. It turns out that large organizations are full of individuals who prefer a simple consumer style eCommerce experience. With onDemand Enterprise, we can quickly create a custom site for a corporate account. These enterprise sites have the same simple "consumer" feel but they also have the ability to offer custom services and can tap into corporate payment channels.

• We have a Public API with a developer program. We started with an API for eCommerce systems to translate product catalogs; but then we grew into a full featured translation API that can handle our full complement of content types. While there are other translation APIs out there, ours is unique because it exposes different translation services ranging from pure machine translation to professional translation by subject matter specialists.

• We are now a global team working around the clock to deliver projects with industry leading quality. We have operations specialists in North America, Europe, and Asia. Managing a service like this requires a special mix of problem solving skills. This is content management at a level of complexity that I have not seen before. The process requires the constant attention of highly skilled and conscientious individuals.

The last point is my favorite. I am currently en route from Warsaw, Poland where I have spent the last five weeks working with the operations core team. It was an incredible experience to meet the people that I had only known through email and conference calls. From the start, I was impressed by their dedication and can do spirit. Now they feel like family.

So, back to this blog. What has made Content Here a worthy endeavor so far was that it provided a useful place for me to explore observations and concepts that I encountered as a content management professional. If I learned something, I would flesh out my knowledge by writing it here. If I did a decent job of explaining something to someone, I would reproduce that explanation here. If that was all blogging did for me, it would have been enough. But blogging provided so many more benefits. In particular, it was a way to connect with other people. I made many business connections and friendships with this blog.

I am hoping that I can continue experiencing these benefits by shifting the focus of this blog to be more aligned with my day to day work. It won't be a total departure from my older posts. My involvement in web development and open source software has stayed the same. But I will probably write a lot less about content management software, product selection, taxonomy, workflow, and other pure content management concepts. To be honest, I feel like there is not much more for me to write on those topics. There will be more posts about my experiences from growing a web business. Topics will include things like working with distributed teams, lean product development, customer support, web application development, and web operations.

Hopefully, along the way, I will meet new people who are struggling with these same topics. The web is a pretty big place so I think that chances are good.

Internet Explorer, you did it again

I learned something new about IE9 today. Apparently, when visiting a site in the same domain as the computer, IE9 defaults to compatibility (quirks) mode. I am guessing that this is Microsoft trying to accommodate crappy intranet sites (cough cough SHAREPOINT cough cough).

So, if your site depends on standards mode, you might find that it looks fine in the real world but not in the office. I work remotely and this has burned me twice. Both times my launch celebration was cut short by complaints from colleagues in the office who saw broken pages.

Now I know.... And you do too.

Hat tip to Marjoe Bacus for letting me know about this "feature".

Evolutionary Software Development: A Model for Maintaining Web Sites and Applications

Since I got into software development back in 1995, I have been exposed to many different software development methodologies. I started out with a highly structured waterfall model (which is hard to avoid with fixed bid projects). Whenever possible, I have advocated agile approaches and I have been on teams that have practiced agile methods like Scrum with varying degrees of fidelity. Overall, I love the values of agile but the agile methodologies that I know of don't quite feel right for the kind of work I do now.

These days my job focuses on managing several different web sites and applications. Officially, you could say that these applications are in "maintenance mode" but the truth is that they were always in maintenance mode. All of these applications have been built on the philosophy of a minimum viable product. That is, we developed a minimal solution to test a) that the problem actually exists and b) that our idea is an effective way of solving it. The initial solutions were just complete enough to answer these questions and create a foundation for an evolutionary process towards continuous improvement. Everything since has been "maintenance."

The agile development methodologies that I know of don't quite fit because they all seem to focus on a notion of defining a 2-3 week "release" or "sprint" and putting the entire team onto cadence that begins with planning and ends with some kind of review. But my teams do not work that way. We release one feature at a time. We don't wait for some large milestone to push new code into production. In fact, we push a new feature as soon as it is ready. We see an un-published feature as a huge liability. Worse than simply not being able to get the benefit of the feature or see how the audience responds to it, unpublished code is a risk. When code sits in an unpublished state it needs to be maintained like working code. Otherwise, when you deploy it, you are likely to break other things. Also, large deployments are riskier than small deployments and make problems harder to diagnose.

We try to define features to be small as possible. Some features are "below the waterline." That is, they are not visible to the end user and are only deployed to support another feature in the future. A very common example of this pattern is that we usually do our database work up front. For example, if we need to build a new page design, we will start by deploying the new fields that the design requires. Then our content team can add the data. Later, once the data is in place, we can deploy our page templates and other application logic that relies on the new data. We also commonly deploy infrastructure upgrades ahead of the features that they support. We also try phasing in features with an initial simplistic implementation to test out the concept and then a series of enhancements to reach the full potential.

When you are maintaining a live application, the line between a bug and enhancement is blurred and the same team should responsible for both. Anyone on the team needs to be able to pull herself away from the feature she is working on to fix an urgent issue. This is another reason why keeping things small is very important. It is also why it is so important to have a very clearly defined prioritization protocol. Ours is:

1. Site down

2. Feature broken with no work around

3. Feature broken with work around

4. Revenue opportunity

5. Customer Usability

6. Operations Usability

7. Brand consistency

The product manager is in charge of setting the priorities and assigning high priority issues that need to get taken care of ASAP.

The lines between coding, content, infrastructure, and support are also blurred. Sometimes an issue is noticed and the cause is not immediately apparent. For example, let's say a customer cannot download a file. It could be that the file was not added in the first place. The code to retrieve the file could be broken. The server could be out of space and the file could not be saved. It could be a usability issue and the customer was clicking on the wrong link. Triaging and coordinating this work is critical needs to be core to the methodology.

Refactoring is another big part of the methodology. You often run into situations where a feature gets a lot of traction but not in the way that you expected. You might need to change how it was built to allow it to evolve in the right direction. You will also need to refactor your successful experiments to support active use. The concept of a "user story" (common in agile methodologies) does not lend itself well to code refactoring.

As you can see, traditional agile methodologies do not accommodate the day to day activities required to maintain and extend an actively used web application. This is because they are designed at their core to support software development projects where the team has the luxury of ignoring the operational aspects of running the application as a service. But that luxury comes at a price: alienation from critical feedback by actual consumers of the application. In agile, a "customer" role filters and simplifies end user needs and tastes. This customer makes a lot of guesses about what the end customers want. The guesses tend to be big and there is no process for correcting the wrong ones. The agile approaches that I know of seem better for building packaged software or for integration companies that are brought in to build something and leave. These are cases where you cannot or don't want to be told that you need improve something right after you thought you built it to specification.

Here is a very real world example to illustrate that point. We use LivePerson to chat with customers who are on our sites. Sometimes there are cases when a customer gets stuck because he does not notice or cannot understand an error message — such as one telling him that he needs to enter something into a certain field. If it is common enough, we will use that feedback to design, implement, and deploy a fix that makes the validation message more visible and understandable. Fixing this issue could be hugely important to conversions. But think about how this problem might be solved in Scrum. A "user story" would be added to the backlog. At some point, this story makes it into the next sprint. It needs to wait for the rest of the sprint to finish before it is deployed. If you do two-week sprints, that could be up to a four-week turn around. You might say that you would handle this in a maintenance track that runs in parallel to your real development. But I would counter that tweaks like this are where applications succeed and fail and should be the focus of (not the exception to) your process. In fact, I think you should think of everything as a tweak.

Despite the fact that lots of organizations are maintaining sophisticated web applications and want to experiment with new features as fast as possible, I have found little writing on formal methodologies to support this. The best writing comes from the DevOps community but they don't directly often address the actual software development as much as I would hope. I like Eric Ries's chapter on continuous deployment in Web Operations: Keeping the Data On Time

. Speaking of Eric Ries, lean startup literature is also a very good resource. But this community emphasizes customer development and doesn't explore the architecture/implementation side as much as I would like.

What really inspired me to write this post was this relatively obscure research paper called "An Online Evolutionary Approach to Developing Internet Services." This fit the bill when I was looking for a term to describe how we work. The word "evolution" is perfect. It captures the idea that development is a series of small modifications that respond to stresses and opportunities. Each modification is tested in the real world. The ineffective ones die off. The good ones are the foundation for future progress. It is true natural selection. We just try to be a little less random than biological evolution.

I would love to hear your feedback on this. I go back and forth between thinking that we are outliers for working in this way to thinking that this process is so universal that nobody thinks about it. I also think there is a lot to discuss with regards to testing, communicating changes to users, and localizing the solution.