TechDistortion

Cloning Success

A group of people (and sometimes just one person) see a problem and create something to fix it. The product or service they create is a huge success and then everyone starts to ask the obvious question: why didn’t I think of that? The same person(s) do it again and again with new and different products and people start to ask the next question: how do they keep doing that?

We humans are a strange lot. Where there is a problem we feel the need to solve it. Where there is a problem solver we feel the need to explain how they solved it. Countless cumulative years of some peoples lives are spent arguing about the how and why of successful people and successful companies. This company puts their customer first and that one doesn’t; this customer has an inverted boab-tree management structure and this one looks more like a watermelon and clearly THAT’S why they were successful. Recently I’ve read theories that Apple was successful because of one man: Steve Jobs. Steve Jobs sadly passed away recently and now some theorists state that Apple is ‘doomed’ without him, whilst others now say his company and it’s design process are the reason for their success all along. On that note, process is for nought without talented people to execute on that process.

This effect is not unique to technology and certainly not just Apple. Many years have seen many different processes evolve around successful companies and many companies have copied them with several becoming very mainstream like 6-Sigma (from Motorola in the mid-80s). Centralised vs Decentralised management; Matrix management and so on. When one company is having market success, their processes are cloned in an attempt to replicate that success. It seldom results in anything significantly positive for the cloning company and the desire to clone what they think makes that other company so successful wastes thousands and even millions of corporate dollars every year.

Trying to understand and clone success isn’t just a company level pursuit: another example is productivity “gurus” that are analysed and torn apart and then put back together as people try to understand what makes THEM successful or efficient¹. Stephen Covey and David Allen are two popular examples and whilst their techniques and suggestions benefit some people the inevitable truth however is that exactly what works for any one individual is unique to THAT individual. No one set of notebooks, software or habits can make everyone more efficient: some will benefit and some will not. Each answer is unique.

No matter if it was Steve Jobs or Apples design processes that produced the Macintosh, iPod, iPhone and iPad; no matter what system made the Sony Walkman, Discman and Stereos so sought after, no matter what made the Motorola Pagers so successful; attempting to clone their successes has not produced any subsequent successes for cloning companies around the world. And yet, they still try.

The quest for an answer, a solution, a method, a process or a reason (any reason) for others success drives many people mad. The truth is that success in any path of life can not be copied from another. Success can’t be bottled or transferred it must be created uniquely. Too many people waste their lives over-thinking the success of others when they should be thinking about their own successes. Following another companies design processes won’t automatically make your own products better. Stop trying to replicate the success of others and get on with making your own success in your own way.

Freedom From Outlook in Corporate Lockdown [Redacted]

In my quest to back away ever so gently from Microsoft’s ecosystem of office applications that run on Windows XP [redacted] freedom from Microsofts way. As a Mac user it’s hard to handle Windows at work on my “trusty” DELL Latitude god-knows-what-number with keys that fall off regularly that takes 10 minutes to boot and 3/4s of the time doesn’t wake from sleep. It’s an abomination but it’s a company provided abomination so most normal people would just use it and grumble but [redacted]. [redacted] Macbook Air [redacted] using native Mac apps [redacted].

[redacted]

Active Directory

This is a big problem. Macs support Active Directory but unfortunately you need an Administrator account in order to add your machine (Host or Virtual Machine) to the AD Domain. [redacted]

[redacted] After that everything should be straight-forward enough except for two gotchas [redacted]: Network-pooled printers and hard-drive based proxy configuration files.

In large companies it’s quite common to share a group of identical printers located throughout the building/floor with a common printer driver that is linked to your employee number. Everyone prints to the one print queue and can walk to any printer and after entering their identification they can then print it. The problem is that both systems that I’ve used are Windows only. [redacted] printing would have to happen from your Windows PC or your Virtual Machine.

In Lion Apple changed the Network preferences such that a .pac file on the hard drive could no longer be directly selected/referred to. Instead it had to be placed on a server. Since this isn’t practical for most people, the workaround is use the loopback address of your PC - http://127.0.0.1/proxy.pac and put the proxy.pac file in the /Library/Internet Plug-Ins directory (correct for v10.8.3 &v10.8.4 of Mountain Lion [redacted] but reportedly this works back as far as Lion). Mind you, that’s only an issue if you’re using Safari. Both Chrome and Firefox should work fine with a HDD file location specification for the .pac file.

Office

Microsoft Office is the predominant office software suite in the world and fortunately there is a Mac version. Despite the drawbacks with Macros, toolbars and stability [redacted] use Office for Mac 2011 which reads and writes everything [redacted]. It works for everything except Microsoft Access and Visio but if you want free office tools there’s always Libre or Open Office. Recently a Visio editor for the Mac appeared [redacted]. However in a corporate environment the office software is only one part of the problem.

Exchange

The issue is that Microsoft introduced Exchange Web Services in Exchange 2007 and Apple decided to run with that, abandoning ActiveSync from Exchange 2003 since Snow Leopard. The problem is that despite running Office 2007 or 2010 as their front-end software, many companies are still using Exchange 2003 as their email server. This renders all current OSX Applications for Calendar (formerly iCal), Address Book and Mac Mail useless as it does Outlook 2011 for Mac as it also doesn’t support ActiveSync.

[redacted] Office for Mac 2008 and specifically Entourage.  [redacted] the corporate edition [redacted] has Communicator for Mac. Being careful to install Office for Mac 2008 first, fully update it, then install Office for Mac 2011 over the top and then update it, and away we go. It would be nice to see ALL of our appointments, Family iCloud Calendars, Personal iCloud Calendar and Work Exchange Calendar in one view. In order to synchronise our Calendars on the desktop Entourage supports syncing Mac Calendar with an entry entitled “Entourage” and this gives us one place to see all of our appointments.

[redacted] Tracking down the public folders [redacted] is also important as this carries free/busy information for scheduling meetings. [redacted] It is not straight-forward and it’s very far from a one click setup. There’s no iCloud integration with Entourage and there are several Outlook features like “Propose a new meeting time” and more that aren’t supported [redacted].

Corporate IT Needs to Grow Up

I hear anecdotal evidence suggesting that corporations are increasingly allowing employees to bring their own laptops to work or to choose between a corporate supplied Mac or PC when they start at the company. This sounds great but it if that’s true it certainly hasn’t filtered down to any of the companies that I have worked for here in Australia, or worked with either for that matter. Until then geeks like me that can’t stand being told what IT equipment or software to use [redacted]. Some IT policies threaten instant dismissal and even fines for breaking the rules as ridiculous at it sounds.

The problem is that the world is moving on and people are starting to realise [redacted] that our computers are the tools of our trade and we need to be given the best tool for our job. IT departments follow policy mindlessly and accept the shortcomings of the hand they are dealt but the truth is that IT work for us - not the other way around. They need to remember who their customers really are and start being more flexible [redacted].

Contextual Hierarchies

Artificial Intelligence has fascinated me for a very long time and how it applies in the real world with current technology bears some discussion. For me the ultimate goal is to achieve fully interactive conversation with a computer: to ask it questions with a wide variety of contexts and have it respond correctly. Some may question the need for such an advanced interactive interface at all however simpler commands are steps along the same road.

The biggest barrier to interpretation of intent is understanding context. Without the technology to tap directly into the cerebral cortex the next best solution is that which people rely on day to day: context. In relationships that exist we have a historical context about the person we talk to: what they like and don’t like such that we are guided in how to respond. For computers to achieve similar results they must have the first level of contextual knowledge: about the person they are talking to. For this they must have absolute knowledge of who they are interacting with. To do this we consider that in the case of a computer or smartphone, just because a person typed in the right password (if there was one at all) it doesn’t mean that they are the same as the person who is logged in as the current registered user on the system. (To say nothing about systems with generic logins) For the purposes of this discussion, assume this problem has been resolved and we definitively know the identity of the user.

I see an individuals context in multiple layers. Clearly the first is the facts about them: What they look like, who their friends or family are, what sports they follow and so on. For a computer to understand the context of a sports question it goes beyond simply understanding what was said. On that note, technology has progressed significantly however converting spoken words into written text is still not 100% accurate. Again for the purposes of this discussion, assume this has been resolved and all that is spoken is understood correctly by the computer.

Computer: “What’s your favourite sport?” Human: “Cricket.”

At this point the computer can add this information to a ‘personal context database’ and can derive their current location based on geolocation (again assuming this is possible) and can then respond as another knowledgeable human might by saying, “The Poms are giving the Aussies a hiding in the Ashes test aren’t they?” To assemble this response it requires knowledge that:

• I am in Australia (location),
• I like cricket (Personal),
• I am Australian myself (Personal),
• There is a cricket match being played or has just been played involving Australia (Current Events with interpretation of the value of the scores made by each side),
• Australian cricket fans refer to the Australian team as the ‘Aussies’ and the English team as the ‘Poms’ (Subject specific public knowledge).

The local computer can only locally store information about the person and can use location to reduce the seek time for current events and subject specific information such as that from Wikipedia or similar online resource which would require a low-latency internet connection (the faster the better).

The layers in the contextual hierarchy in order to strike up a casual conversation about sport with a computer are: Personal, Subject Specific and Current Events. Each database must be cross-referenced against location and must be kept current at all times to be truly useful. Current Events will change constantly whereas Subject Specific matter will change much less quickly. The problem with publicly collected data is that ‘facts’ vary from country to country and based on the person(s) inputting them in the first place. The simplest example is a pie. If you’re in Australia a Pie usually means a hot Meat Pie, whereas in certain parts of the US it means a Pizza, but other parts of America means a cold Pie that usually doesn’t contain meat. Hence facts need to be duplicated in many cases to account for regional differences and can not simply be ’learned’ by an automated system.

The point of this is that there is no easy answer. It’s not just how much data you hold it’s about how well it’s organised. Google Now and Siri are Google and Apples attempts to bring AI to the mainstream with each system giving mixed results. There is no doubt in my mind that for basic tasks like setting a timer they work fine as context is extremely limited and curation isn’t necessary, but for anything approaching conversational contextual understanding, we are a very, very long way off.

Not All Design Churn Is Bad

It is generally accepted in design that design churn is the enemy. For those unfamiliar with the term, unlike design iteration whereby a common set of requirements is agreed upon and during development new ideas are added and redesign occurs to improve the end result, churn is normally driven by an external influence which is usually requirements changes. Sometimes this is referred to as scope creep, however churn needn’t be about additional new features that are ’nice to haves’ but can be simply about what the design team originally missed or neglected as requirements.

The ways to avoid churn and creep are also generally accepted and perhaps obvious: The lead designer responsible for developing the requirements specification has a great deal of experience in the area the product is developed in and key knowledgable stakeholders from all affected end-users are involved in the development of the requirements. Once the requirements are set many lead designers are loathed to change them to keep their churn in check and reduce any potential scope creep. Unfortunately this rigid approach ignores the fact that not all design churn is bad.

In addition to the initial requirements definition phase, in Engineering there are special detailed design reviews referred to as HAZOPs that are intended to flush out the finer details of what happens to a design if/when specific things go wrong. They are intended to be thorough and run by an independent third party and can take days to perform for even a simple system. This represents a significant investment in peoples time and hence the projects money and once designs pass through a HAZOP they are often felt to be ‘set in stone’. If significant design changes are required post-HAZOP then technically the HAZOP needs to be revisited (not redone from scratch as is often touted by nervous design leads) which becomes a strong obstacle to change.

The problem with the reactionary approaches to requirements change, especially post-HAZOP, is that they ignore the very real possibility that the requirements gap is real and will cause operational or safety issues for the end user(s) upon completion. There is an implicit assumption made every time someone responds with “A HAZOP was performed” or “We had end user input” that those persons involved at those times were A) knowledgeable on all aspects of the subject and B) infallible. We are all human and we all know that people make mistakes including lapses in concentration and judgement, but the odds of obtaining the best requirements input early on is most highly influenced by the persons involved.

There are two stages to consider. During the initial requirements specifications stage, teams are often quite small consisting of a bare minimum of design staff and those staff are predominantly senior staff that, whilst they may have some field/end use experience in the past, sit in management positions and have done for some time. In my experience this assertion is not too much of a stretch as I’ve observed this to be the case in at least half of projects I’ve been involved with in my career. Remembering that age does not equal wisdom or quality and that what actually matters is recent, relevant experience then this effect should be a cause for concern.

The second stage is the detailed design review stage which in engineering usually includes a HAZOP or similar detailed design workshop/study activity. The length of these reviews is often seen as a reason to keep the numbers down - too many people means too many opinions which makes the reviews even longer. Often there are strict requirements to have only 1 representative from each stakeholder group present and those that are sent can sometimes be chosen because the more experienced designers are just too busy with other deliverables and can’t dedicate a solid week to a HAZOP review. The way in which HAZOPs are run also plays a big part with holes in requirements that are found often thrown out the window on the pretext that the current design is being HAZOPed, not what the design could or should be. Such ‘off-topic’ input is supposed to be recorded and resolved outside the HAZOP however if this leads to a design change then the requirement to re-HAZOP the resulting changes is cited as being an expensive and unnecessary exercise and those comments end up ignored.

The customer MOSTLY gets what they want

The end user or customer that is paying for the design to be done for them should be the highest authority on design requirements. There does need to be some restriction on scope creep once the initial requirements are set but the wrong way to handle it is to uncategorically say, “Requirements are set, can’t be changed now,” or “It’s too late, it’s been HAZOPed.” Both statements are ridiculous and ignore the very real possibility that omissions and mistakes were made earlier on and that ultimately the end user will suffer from a difficult to use or under-performing product.

The right thing to do is to assess the true cost of the potential design change. Be honest with how much time a HAZOP revisit would really take (if applicable) and be thorough with the number of design documents and deliverables that would require modification. Once this figure is known a rational debate can take place that factors in schedule as well as the risk to the end user(s) of NOT implementing the changes. Far too often in my industry the design team shuts out the end user from design requirements changes and forces them to spend additional money themselves further down the road (after the project is ‘finished’) to correct the mistakes they found during the project. This ends up costing the customer more money in the end and will hurt future business between the designers and the customer in question.

Everyone should care about customer satisfaction and yet the transitory nature of employment in the engineering space (about 18 months per position) leads to a culture of apathy and rigidity where customer satisfaction is seldom a big factor. Continuity in projects matters and being honest with your customer about the cost of change will help you to both succeed. Shutting down design requirements changes without thought or consideration leads to bitterness, frustration and is ultimately is bad for business.