Delight is the Success Criteria for Application Code



The Strategic Brief:

The hardest decision in coding applications is to admit your users are NOT delighted – and that you have to rebuild. It takes discipline to move application development from functional to delightful. It can only happen when there is clearly understanding by coders of the purpose of the code. Connecting coders to customers is hard work. It takes deeper effort from product managers and marketing teams, though the payoff is worth it.



Public speaking is supposed to be one of the most stressful events in life. Luckily, I am pretty comfortable in front of audiences. As a musician in bands, I was lucky enough to perform before thousands. It was ok because I was part of a band. My inner critic could interpret success or failure as being caused by other members of the band! 😉 (It was the bassist’s fault, or the singer never won the audience). Then a friend asked me to read my poetry in a public forum before an audience of about 30 people. Yikes! The poetry was my own words and thoughts, performed by me. Solo. Whether the audience applauded or threw vegetables, it was solely down to me. They were judging me personally. Yikes!!

One of the things I love about code is that code does not judge. Code either compiles or fails. It runs or it does not. Code does not care what clothes I have on. There is no human value judgement involved with coding. Except that is not true.

Code has no value or quality on its own.

Until code has a user, it is the bad poetry that never leaves your high school diary. Using code makes it real – the user gives code purpose. The value judgement in code is what it does for a user. Airbnb makes finding a bed in a foreign town easier. The binary nature of code function is decided by whether a user can find a bed or not. The quality of code is found in the experience of the user.

Compare coding an application to making a movie. Director Jon Favreau describes the movie editing process. “The first [compilation of the film from the editor] you view is terrible! Each edit makes the film less terrible. Then somewhere in the process it starts to be good … and maybe even great.” Like a movie, the application code begins as terrible. Edits make it less terrible, and eventually the code runs. It is functional. HERE IS WHERE FAILURE HIDES. If you get to running, functional code and think the job is done. Well, sorry, you failed. The movie director is not even done once they get to a good edit. Movie directors then perform test screenings to see how audiences react. Based on audience reactions, reshoots are performed, final edits are made and then the film is complete. Running code gets you to the first alpha test. Here you should be both looking for user response, as well as bugs.

Sometimes delight is baked in. You were lucky enough to identify the delightful aspect for your customer during a sprint or early mockup phase. Sometimes delight is serendipity, in the coding process you find something beautiful to reveal to customers. Sometimes you get to functional and delight is still not there. The hardest choice to make is to admit your users are NOT delighted – and that you got it wrong – and you have to rebuild (or reshoot in movie terms). If coders cannot be users of the code themselves, you must connect them to customers, not just product managers. Code must be seen in use to understand delight in its’ use.

Applications have one distinct difference to movies. Movies get one distribution, or maybe an additional director’s cut. Applications get multiple versions. On the plus side, this allows you to address challenges over time. However, be careful this does not turn into the dependency on the adage of ‘we will delight them in the next release’.

EDIT: Reader’s asked what happened with the poetry reading? The audience applauded, but I realized I was better with processors than poetry. 😉

Is DevOps Enough in a SaaS World?

 

Strategic Brief:

The devops approach was meant to give us agile development AND more manageable applications – reducing cost of operations and making apps more reliable. Being close to ops helps, but it is not the full story. It works well for individual applications, but can miss the complex interactions between applications, and between applications and the users or consumers who operate them. The Sprint approach that grew up within Google is good as a starting point, but a more continuous relationship needs to grow out of it.

 

 

When I was a system programmer, I worked on a project setting up a HL7 (1) communication network for a group of hospitals. In early configurations, different applications processed HL7 transactions at different rates, so you needed a queuing mechanism to allow backlogs to be solved without losing data. So far, so good. Except, each laboratory application and queuing application was developed separately and often came from different vendors. Even within the same application, each component might have its own commands to collect information on transactions. Developers gave no thought to the operational need for measuring and managing the overall queues once in production. (Developers over here, operations over there).

This hot mess went live.

The phone calls began. Hospitals complaining about laboratory results not getting back to the wards in time. It turned out that some format errors caused transactions to get stuck in the queues (the application code definitely under-delivered in dealing with variances in field content). Operations needed a way to see what was going on between the applications.

An in-house developer created a complex PERL script triggered the various commands, cleaned up the results, and reported on the queues. The first attempt revealed all the details of the queues. Yippee, development solved the problem.

DevOps will only solve part of the problem.

Now operations had ALL the details, but without any meaningful way to interpret and act on it. Operations did not know what to identify as an impending problem. How long a delay was acceptable in a hospital? (Developers over here, operations over there, customers further out.)

Finally, the developers met with some nurses (customers!) to understand the ‘time’ requirement. The goal was that a transaction from labs to bedside should always be faster than the time for a human (generally a nurse) to physically run there.

A rewrite of a script highlighted queues approaching thresholds. Now meaningful thresholds could be set and recommended actions be added in. The stuck transactions were flagged for development to sort out. If queues got too long, the relevant hospital could be informed to switch over to manual delivery of results to wards. The angry phone calls stopped.

  1. A little background. HL7 is a standard for transfer of clinical information between various healthcare applications.

The ‘I’ in CIO is for Information



The Strategic Brief:

For the last sixty years, the title for the person in charge of IT should really have been the Chief Digitization Officer rather than Chief Information Officer (CIO). Today’s technology enables the CIO to focus on information as well as technology. As CIO, you must own the connection of your customers to your business – the customer experience (CX). Personalizing this experience will require collecting more information about your customers. There are multiple information collection approaches, and you must select those that will give you sufficient details, and more importantly match the type of relationship desired with your customers.



For decades, the purpose of information technology was to capture and store information about the business. The 1957 Hepburn/Tracy classic “Desk Set” tells the story of “two extremely strong personalities clashing over the digitization of a TV network’s research department.” (1) In the film, the news research department was humans, books, papers and all of that knowledge was being digitized. Digitizing existing information was all the rage.

google-ngram-frequency-of-cio-1920-2000

Chief Information Officers (CIO) have existed since World War II, yet for the first seventy years it may have been more accurate to call them Chief Digitization Officers. They were responsible for taking processes and information from analog to digital. Now, with mobile applications and the internet of things (IoT), the job is changing enough that they are finally earning the ‘I’ in the title.

For decades, CIO’s spent most of their time on acquiring real estate to house computers; operating the computers, networks and storage; developing or buying needed software; connecting devices to the centralized systems; and managing the people needed to make all this happen. IT was really digitizing existing processes – instead of bank tellers handwriting deposits in giant tomes with manually totaled results, they entered the deposit into a computer. Companies did not learn that much more about their customers, they were merely digitizing existing information. In simple terms, that early CIO focused on the ‘technology’ part of information technology, not on the information part.

Leap forward sixty years to 2016’s omnipresent mobile applications and accompanying personalization. IT now moves well beyond the role of digitizing processes into owning the connection of the business to the customer. The new CIO will now own the frontline customer experience (CX). Customer experience personalization is a crucial survival tenet for 2016.

In addition to all the technical responsibilities above, the CIO must now focus on the ‘information’ part of IT. To support customer experience, and in particular personalization, a business must collect and understand significantly more information about the customer. A critical component of customer trust will be clearly explaining why you are collecting and using the information and how you are protecting the customer during and after collection. (This is so important, it will get a separate article with deeper analysis soon).

With each generation in society, the relationship between a customer and a business becomes more digital than IRL (2). Take the example of enterprise software vendors in a sales cycle for a new technology. Previously, the vendor team would visit the client and explain the new technology to initiate the sales process. Today enterprise IT staff use the internet and social networks to discover and research new technologies. Once the technology is identified, the IT team seek out the vendors offering the needed features. Most of the sales cycle is done before a salesperson even enters the conversation. Technology supporting self service is only the first step in IT involvement in the customer experience.

The takeaway is that while existing information must still be aggregated and connected, significantly more new information must also be attained to support improving the customer experience. This is now a key requirement for the business relationship with customers, and must be handled with finesse. Base how you will collate information on the nature of the relationship you want with your customers. We can transform our relationships with our customers by making the technology part of IT take a step back and focusing on the information part. The CIO is finally earning the ‘information’ part of their title.

  1. For fun, compare how computers are portrayed in that film versus the ‘Mr Robot’ TV series. For more fun, compare Hepburn’s job to Google.
  2. In Real Life