Rather than a specific technology what I wanted to share this month was a simple drawing, its a drawing that many of have seen before but some how think it does not apply to us.

The first time I saw this it was a photocopied cartoon, copied many times before, but still funny, and still relevant. Today you can even build your own version of it at http://www.projectcartoon.com

 What is it about this simple cartoon that has made it so long lived? Why do we seem unable to design systems that meet the users’ needs? The answer to these questions are simple but the actions that are required to resolve them are hard.

The answer is not to focus on the problem or the problem space but to focus on what the customer really wants. What would delight the customer. In order to do this we need to think like our customer. We need to be relentless in this task.

Agile development processes help us deliver product in shorter time spans; but we need to focus on what joy each iteration will bring to the customer. We need to deliver streams of updates in the shortest possible chunks, because the only way we can find out what the customer really wants is to give them something and them to say Naah! I know I asked for something like that, but actually after seeing that I want something like this ….

As Stephen Denning would say it is all about exploring what’s involved in replacing the daily grind with discovery and surprise. It’s about becoming more productive by working smarter. It’s about generating work that involves doing things with people who share a common passion for the activity and for being excellent at it, in service of other people whose ever-increasing delight we can see and experience.

It is a million miles away from Frederick Taylor, and his 1911 classic, The Principles of Scientific Management. Where we command and control as a general on a 19^th century battlefield would do. We need to move away from rules and regulations for the purpose of those rules and regulations and towards focusing on the need of the customer. Identifying who the customer is. Getting everybody in the organisation to think in this way, and focus on delighting their customers. A delighted customer will naturally give back recognition to the teams that delivered the service or the product. That feedback makes the person who put in the effort feel valued, as they feel valued they want to do it again. It is a positive feedback loop.

An example of how it can go wrong and so easily be fixed was illustrated to me by a colleague. He had a contract with a large telecommunications provider for his mobile phone. About 1 month before his contract was up for renewal, for the first time he tethered a tablet to his mobile phone to gain access to the internet. Now bare in mind this was a one off, one month before his 2 yearly contract renewal. The telephone provider wrote to him to tell him he would be charged nominal charge of a few pounds for his activity. Whilst perfectly within their rights to do this, it does not delight the customer. The effect is exactly the opposite. To the point my colleague has changed provider to another company. A better and more progressive solution would have been to write to him, inform him of what he had done, tell him about the charge; but then waive the charge. That way he would have gone away with a warm fuzzy feeling, that they really do care, and would have renewed his contract.

Not thinking about the customer today means they will walk. They will find another purveyor of the service or product you supply, and you will go out of business, because somewhere out there someone will care.

Taking a look back to the seventies there was an institution that lead the way in innovation, they weren’t just ahead of the game they were years ahead of the game. If I show you two computers, both made in the 1970’s one looks like a machine you may use today, the other something from a 1960 scifi show.

The computer with the windowing operating system is a Xerox Parc Alto. Xerox Parc was set up, as a department Xerox, to innovate. It took some of the brightest people and produced some revolutionary products. These products were so ahead of their time they did not even look like the computers of their day.

When you look at it compared to the Altair, a computer that Bill Gates used to develop his basic language on you can see and feel the difference.

Xerox based Parc on the west cost of America intentionally to give the innovators room to think, and be radical; without the interference from the business, which was located on the east coast.

This separation produced great innovation but the separation also failed when it came to execution. In 1981 Xerox finally released a product to the world, the Xerox Star 8010. It was the first Windowed based computer to be released. At an eye watering $75,000 for two computers, a file system and a laser printer. Additional workstations were priced at $16,000.

Shortly after the Star was released, Apple released the Lisa. Steve Jobs had seen the Alto at Parc, in the late 1970’s, and formed an impression on him. The Lisa was priced at $9,995 and was the precursor to the Apple Mac.

Even in the 1980’s Xerox as a corporation it was not convinced of what they had on their hands. They did not promote the computer within the corporation, they did not put a sales initiative in place to promote the selling of the computer. If they had ramped up production they could have reduced costs. Rather than bundling laser printers they could have focused on the product, added a floppy disk for storage and sold it with a dot matrix printer, and brought down the price. This could all have been done by the Mid-70’s if Xerox had been a more dynamic company rather than a top down regimented organisation.

Obviously the company saw the need to innovate; otherwise Xerox would not have created Parc. Xerox in a way, as a corporation, were revolutionary by setting up Parc. They saw the need to innovate. They saw NASA putting a man on the moon, they new to flourish as an organisation they needed to innovate. What they failed to see is the need to execute. Innovation needs to be productised for it to see the light of day. There needs to be a dynamic way of harnessing the creativity, through trust, of those that drove that innovation, in those that best understood what they were creating to deliver the product.

In fairness to Xerox they did set up Systems Development Department (SDD) in El Segundo, to develop the Star; however this was not until 1977. After the creation of SSD they followed formal rigid methods as opposed to what we might today have expected – lean startup. Possibly more importantly, there was not enough trust.  There was not an entire horizontal that took the product from innovation through to the shop shelf. There was not the support required to market the product. For those who can remember the marketing campaigns from apple from in 1984; they showed the way to market products. Apple’s execution of Apples take on Xerox’s innovation built Apple into the corporation it is today.

To conclude, a company who innovates has the first slice of the pie, the first opportunity to capitalise on the creative. Innovation works best when the innovators are set free from the corporate shackles. The creative has to be backed up by a company that supports the innovators to turn their concepts into products and puts the infrastructure in place to market and sell the product. The production team will again work best if they are given the freedom they need. Then they can get the innovative product to market before the competition catches them up. Ultimately this will lead to the company doing what is best for the shareholders, and that is making profit.

 was looking into how to explain a large distributed system with lots of different queues, lots of dependencies, and to get a handle on it in a succinct manner. How do I model persistence of communications, how do you know what is transient, and more importantly how do I do it on a single piece of A4, so that it looks light weight and not burdensome?

Have I just asked for the world on a stick? Sure I could probably model this in UML, but I doubt it would fit on a single sheet of A4, it would not be lightweight, and the slightest change would render the diagram out of date. Furthermore, working in an agile environment, such things are often thought of a heresy. Interestingly, history tends to show that heretics are just those who are pushing the boundaries of our understanding beyond what we are comfortable with. Mordern day oganisations, like the for-said hereitics, tend to close in to quash what they are not comfortable with, so that they do not destabilise their balance of power.

Cranking my mind back through a couple of decades of development, I recalled using a methodology called MASCOT. Now I would not be surprised if you have never heard of it. It was an obscure methodology that was developed by the Ministry of Defence in the 1970’s and actually it was well ahead of its time.

If you think the Americans built the internet as a military communication tool that was a distributed method of communication, with no single point of failure, that enabled the distributed flow of information – the British created a methodology to model it.

Nowadays, the Internet is the life blood of business communication, we connect servers to other servers, we display the output on HTML5 devices or in Apps or plain desktop browsers. We have GPS signals telling us where we are, other devices tagging products using RFID or even paying with NFC, or telematics recording our behaviour. The tools we have to model all this behaviour are overwhelmingly inadequate. There is an innate level of detail, yet we need to see the flow of this data in a simplistic form. Welcome to MASCOT.

Whenever I start anything, I start from Hello World. So let’s do Hello World in MASCOT That’s great, but maybe I want my Hello World program to now be an echo server. I type in a message. transfer it to another computer and display the output.

Ok that’s great, but rather than just sending a message and instantly displaying it, what happens if the display is not online, so the messages need to be persisted?

Ok, well that was easy. But Hello World, or a simple message server, isn’t really complicated, how can this scale? MASCOT has a mechanism to hide complexities in subsystems. All you need to do is manage the connectivity between subsystems. You define what the interfaces are to those subsystems. Then you can implement those subsystems in MASCOT. This gives you an overview of the system as a whole. You can then drill down into the subsystems

What MASCOT does not do is any detailed design of the application. All it does is allow you to design the messaging between processes, but if these processes are small and self contained units, then those units would be suitable for TDD or BDD.