Organisational Growth

Business is growing and you need more people to handle the increased demand.  You hire a new member of staff to grow an existing team to handle that increased demand, obviously you put them with that team and the team size has just increased by one.

Demand for your services continues to grow and even more people are required to handle that increased demand.  Naturally, you hire a new member of staff for the team, and a new one, and a new one.  If you keep adding them to the team then the team will just get bigger.  As the team gets bigger the number of paths of communication increase.  The team also begins to function less like the team of old, cliques form and the team's identity is fractured.

What went wrong?

There are a number of options to be considered whenever one increases the number of staff within a department - increasing the number of accountants and lawyers is two separate areas (accountants and lawyers) unless you have cross-functional teams.  So let's re-frame the situation as increasing the number of staff within a collection of related teams (each team may have a single function or be cross-functional, but if the teams have a single function then you have multiple teams with the same single function), therefore there are three options:

1. new starters are distributed across all existing teams
2. new starters join a new team only for new starters
3. new starters are allocated to one team only

Let's explore each of these options in turn.

Distributing new starters across all existing teams means that each team will face the disruption and overhead of incorporating a new member into their team and training them in the team's way of doing things.  It also means that all teams will increase in size.  If this is only a short term modest increase of only 1 or 2 people per team then it may have no adverse effect on team function.  However, if you keep hiring new staff and distributing those new starters across the existing teams then you will eventually face the situation where all of your teams have begun to reach that critical moment when they are "too" large to function as effectively as they had done previously.

Instead of distributing all new starters across all teams you can put all new starters into a team consisting only of new starters.  If the new starters team has no established staff working with it then it is on its own, forging its own way, making its own mistakes, and creating a potentially distinct identity quite separate from all the existing teams, but at least none of the existing teams are affected by having to train the new starters, at least not directly.  With some guidance from an existing member of an established team then the team of new starters will not be left completely to its own devices.

The third option was to allocate new starters to just one existing team.  New starters would be trained on the job just like if they were distributed across all the existing teams, but now only one team has the disruption of having to form, storm, and norm with the introduction of each new starter.  Eventually that team will have to split once that critical moment of being "too large" is reached, but this will only happen for one team, not every single time as would be the case in the first option where new starters are distributed across all existing teams.  Splitting the team will still have some degree of forming, storming, and norming associated with it, but that is minimised if the nucleus of the team is split, amoeba-like at the same time, where the nucleus consists of two or more established members of the original team.

Are there other options?  Possibly some mixture of the 3 options.

Which option makes the most sense?  That depends on the system to which you are going to make the changes.

Teams are not amoebas.

Visual Studio Code: it does more than you'd expect

Visual Studio Code is great, just great.

Having previously been a big user of Visual Studio I was rather dismissive of Visual Studio Code - it's just an editor for Macs, isn't it?  Anyway, since seeing it in action in the technical sessions at the Microsoft Tech Summit in Singapore I knew it was now a lot more than a simple editor and was a credible rival to Visual Studio.

So, I downloaded it, started installing it, ticked all the boxes, and set about playing with it.

Some time later I noticed that when trying to open some folders in Windows Explorer that Visual Studio Code would open.  This was odd - who on Earth would always want to open Visual Studio Code when double-clicking on a folder in Windows Explorer?

Investigating a bit further I saw that "Open with Code" was the top and default entry for the context menu for folders in Windows Explorer.  So how to disable this?

I turned to Mr Google, and after a bit of browsing I came across this:
http://thisdavej.com/right-click-on-windows-folder-and-open-with-visual-studio-code/

The article describes itself thus:

Today’s topic is aimed at Windows users who are using Visual Studio Code and want to be able to right click on a given folder and launch VS Code.  We’re going to add a right click context menu item to “Open Folder as VS Code Project” since it saves time—and it’s more fun!

However, I want the reverse.  I want to stop Visual Studio Code from always opening when I want to open a folder in Windows Explorer.

What appears to have happened was that in my eagerness to install Visual Studio Code and ticking all the boxes I'd ticked too many boxes.  Namely, I'd ticked but not properly read these options:

http://thisdavej.com/wp-content/uploads/2016/03/VSCodeInstall.png

Rather than uninstalling and re-installing Visual Studio Code I wanted something that was less time consuming.  Anyway, the solution is to remove the correct entry from the registry, namely:

HKEY_CLASSES_ROOT\Directory\shell\vscode

 With that entry gone I can now open folders in Windows Explorer as intended, and I can still select "Open with Code" from the navigation pane.  Huzzah!

Conversational UI in Singapore

Went to the inaugural meeting of Chatbots SG this evening.

As is traditional I have to say something about the catering: there was no food, only drinks, so I took my seat.  My seat had a freebie: Slack socks.  I tried them on later and fortunately they weren't slack socks.

The venue wasn't too bad, but I do find that the Block 71 area is rather earnestly hip and trendy.

Anyway, I went there to listen to what people had to say about chatbots, or conversational UIs as nobody described them.  We did learn that the group had been set up "by accident", but didn't get more detail on that story.  Anyway there were talks by people representing a number of organisations, so here goes.

Slack

OK, so we start with the sales/marketing pitch.

The premise presented for chatbots in Slack is that one does not have to build a new app or web site with forms, menus, etc, instead one can use Slack conversations (and buttons) as the UI.

What did we learn?

• walkiebot.co is great for prototyping conversations
• dashbot's chatbots analysis reported that  4/5 of chatbot users prefer textual engagement over buttons
• someone in the audience said "algo" instead of algorithm - it sounds equally as bad as people saying "geo" instead of geography
• unfortunately, we didn't manage to get any roadmap secrets

We also learnt that Slack are now introducing forms, menus, etc. to their chatbot toolbox.  Remember those?  They're the kinds of things that you get on the apps or web sites that you might otherwise build instead of using a chatbot...

osome

(I have to stop thinking of the AWESOM-O 4000 when I hear the name.)

What did we learn?

• if people want to do something quick & easy then they prefer self service
• if people want to do something complicated then they prefer a live agent

One of the audience questions touched on data privacy, which is always something that organisations handling personal data need to be aware of, particularly when it comes to the various pieces of personal data protection legislation.

Bus Uncle

Known as Singapore's favourite chatbot, I'd never heard of it before, partly because it's on Facebook.  Having seen the demonstrations of it I can understand why it's the favourite: the developers paid attention to the user experience.  Bus Uncle uses local vernacular and has a personality.

The developers had also developed a chatbot for visitors to Indonesia, which then raised the area of potential movement towards bot-to-bot conversation, or effectively referrals from one bot to another.

The Bus Uncle chap did mention that they have adverts embedded in conversations... hmmm, product placement.  They do need to make money to pay for this, but I hope it's done well.

And Finally

The pizza arrived, but I needed to go home...

"What happens to HR in an agile journey?"

I'm at another Agile Singapore meetup, this time in Titansoft's offices - ah the smell of freshly-decorated office, it's so... cephalagic.  Anyway, I'm in Titansoft's offices listening to Titansoft's HR & Operations manager talk about what happens to HR in an Agile journey and I'm taking notes with a Titansoft 3-colour pen I'd picked up at a conference a couple of years ago.  I'm not, however, wearing a Titansoft T-shirt, nor a T-shirt with Titansoft's name on there as one of the sponsors - basically, I'm not wearing a T-shirt.

This is a talk about a journey, so there are travellers on that journey who encounter obstacles and have to navigate twists and turns along the way.  Not everyone was ready for the journey, people were happy where they were, but then difficulties were found with their situation at the time, and there were voices in the distance indicating a new and different situation that might just be better.  Along the journey some people found particular paths to be hard-going, particularly when they were still carrying so much other baggage that made it harder to navigate those narrower paths.  The main path was quite wide and generally inviting, but it was mostly muddy - sticky and slippery, not the kind of ground you want when you're carrying that historical baggage.  Not everyone followed the same paths, but each group seemed to find what most suited them, or what they were most comfortable with, or rather what became their new comfortable situation.

What stuck out?

Kids today(*) want their work experience to include the following: autonomy, flexible working hours, learning opportunities and challenges, meaningful work, and frequent feedback.  I don't know why that list should be exceptional, they're all the kinds of things that I like to find in an employer, and I'm supposed to be a member of Generation X.

So much like Plato's reporting of Socrates' complaints against the youth of 2400 years ago, the comments about the kids of today would appear to be the same view of every generation.

There was one other desire that the younger workers want from their work experience: early promotion.  Though history is littered with stories of ambitious (and exceptional) young characters who found early promotion, the emphasis is on them being exceptional, which is also why there are stories about those characters in the first place.

This is something I have trouble with because it potentially sets up an unrealistic set of expectations for repeated promotions.  If so, then there are going to have to be many more rungs on the promotion ladders than there are now - you want to move up from Junior Assistant Junior Clerk to Assistant Junior Clerk and then on to Senior Assistant Junior Clerk?

Surely there was more about HR in general?

I was struck by some of the default mindsets that I'd deduced from the presentation.  (It was only an hour's presentation and I did not grill the speaker so I may be wrong in some of my assumptions.)

The focus was on the shift from performance appraisal to no performance appraisal and from fixed hours to flexible hours, which suggested to me that the default mindset of HR was very much one of command and control, that people are resources - hmm, the clue's in the term HR itself... - and not thinking of how one cultivates an environment for knowledge workers to thrive.

The HR manager was only recently introduced to Douglas McGregor's Theory X and Theory Y theories of motivation and management.  I would have expected an HR manager to be fully familiar with the various theories of motivation and management such as Maslow's Hierarchy of Needs, etc

Performance reviews were removed but the experience was that there was reduced feedback, which suggested to me that the managers were not conducting regular (and frequent) one-to-one meetings with their staff - something which I'd been taught in my first line management training course many years ago.

Flexible hours is something that I've come to expect over the years in non-customer facing roles, and that teams are well aware when one or more members are not pulling their weight.

It was also interesting that more developers were included in the recruitment process - after overcoming an HR concern that people were not qualified to conduct interviews.  (Which leaves me wondering what magical skills interviewers have or why one did not think about how people can learn how to conduct interviews.)  However, I understand that the recruitment process then reverted back to the previous framework because the developers had complained that recruitment work was getting in the way of their day-to-day development work.  My immediate reaction to that would have been to ensure that there was alignment in terms of expectations regarding the balance between the effort required for (the very important) recruitment activities and the effort for day-to-day activities.

What else?

Looking at the slide on the workforce demographics I was surprised to see that the age bands stopped at 45.  Hmmm.

What about the food?

This was an after work meetup, so how could I not have some comment on the food?  Well, there was no greasy pizza.  In fact, there was no pizza at all, but there were plenty of doughnuts.  I decided to give the doughnuts a miss.

(*) So-called Millennials, Generation Y, Generation Whine, the (latest) Me Generation, etc

Microsoft Tech Summit 2018 (Day 2)

(This post originally appeared at: https://www.linkedin.com/pulse/microsoft-tech-summit-2018-day-2-duncan-k-g-campbell/)

After day 1 of the 2018 Microsoft Tech Summit in Singapore comes, surprisingly enough, day 2.

Yesterday's Mr Jif was back, and to confuse me even more he was talking about "damons".

As irritating as it is to hear jif and damon (you can add lettooce and suchlike to the list) it was startling to find that there were so many participants at the summit who'd spoken to him for whom containers were new territory.  Indeed, from a show of hands in the venue, half of the audience had only heard of containers in the last year.

The IT press has been banging on about containers along with devops, IoT, blockchain, machine learning (whilst pretending it's AI), etc for the past few years.  Either it's just the IT press that I read, or it's just that I read the IT press and many others in the industry don't.

Choose your speaker

Next time I need to be careful about who's talks I attend.  The talks by actual engineers have demos with real content that I can appreciate.  I just need to avoid talks by "program managers" - the PowerPoint Architects of the IT presentation community.

What was out of this world?

Cosmos DB stood out.  From what the speakers described, the data model is Atom-Record-Sequence and you can access through various different models, such as MongoDB.  It has some pretty impressive performance claims, and is certainly worth further investigation.

But what about the Demo Gods?

Of course the Demo Gods struck.  There were demonstrations.  What would one expect to happen?

T-shirt?

The T-shirt rules were different this year.  Lat year you'd just to complete the evaluation form.  This year you'd to talk to one of Microsoft's on-hand experts and get a voucher that could be redeemed for a T-shirt.

I had no burning questions.

Anyway, the T-shirts I gather from conferences become instant gifts for my children.  Also, the queue for T-shirts on Day 1 was tens of yards long - I was too dumbstruck to take a photograph.

Microsoft Tech Summit 2018

(This post originally appeared at: https://www.linkedin.com/pulse/microsoft-tech-summit-2018-duncan-k-g-campbell)

Last year I attended and wrote about the 2017 Microsoft Tech Summit in Singapore and was rather disparaging in my comments with just the slightest hints of sarcasm.  How does this year's Microsoft Tech Summit at the Marina Bay Sands Convention Centre compare?

The keynote's theatrics and orchestration were, thankfully, toned down a level this year.  Yes, there was the ghastly thumping music, but the coloured spotlights were toned down and the house lights were up as we entered the auditorium.  There were still the ushers with their illuminated batons like aircraft marshallers on the airport apron directing us into the chairs that were again arranged too close together for comfort.  Fortunately it was not a full house, so I could decamp to seats further back where there was a civilised degree of space for one's comfort.

How was the keynote itself?

It wasn't actually one keynote this year but two: one for Microsoft 365 and one for Azure.  The toning down of orchestration had spread to the clothing, and the tech summit corporate presenter uniform of jacket and jeans was barely evident.  Not everything was toned down from last year, as there were still the meaningless statistics presented at the start.

Sitting through the speeches in such keynotes one does wonder how to separate "predictions" from a company's product roadmap.

We also got to hear IT directors and CIOs on the stage tell us in person that using Microsoft services such as Azure were good business decisions for them, that security and flexibility were important to them and that Microsoft's offerings provided security and flexibility, etc.  I'm glad I was there to hear these insights first-hand.

It was a bit confusing at one point when one of the speakers was talking about jifs, but I did not dwell too long on that peculiar word.  I'll try to look it up later...

Each presentation was accompanied by surtitles, but the transcriber appears to be rather slow and hard of hearing.

Do Microsoft's speakers all get the same coaching?  It's truly amazing!  Is it just USAians in their ranks?  How awesome!  Or do Microsoft only select those with a certain style for public speaking?  That would be so massive, so powerful!

There were the usual videos of people (usually young and hipsterish) working on the move or from any comfy chair in their New York converted loft offices.  What they don't show are the people checking their e-mail on the loo, writing that presentation in bed just before they turn off the light, then waking up to check the spreadsheet over breakfast - with the right device you could even continue being "productive" in the shower.

Are these the images of the bedraggled, over-worked (hence unproductive) worker, or are they just people finding the times and places to do their work because their "work" hours are full of non-productive activities and are in an non-productive environment?

I do wonder about corporate videos these days: the flashy, corporate-cliched presentation; the over-loud music to remind you that something is happening even when someone's not speaking; the lack of attention paid to the audio mixing of people's voices so that you can tell what they say and they don't sound distorted.  Who approves them?  Who approves of them?

But was there any interesting content?

OK, one can now spend less time on the style of PowerPoint slides because it can automatically give you a series of corporate professional looks.  Will that mean people putting more time into the content of their presentations rather than the style?  Time will tell.

Microsoft's purchase of LinkedIn has paid off: people's LinkedIn profiles are now linked to Microsoft 365.

The Azure Stack is pretty good - consistency across on-premises solutions and in-cloud solutions (so long as those are on Azure).

Last year I noted that there was only one Azure region in South America and none in Africa.  This year there's still only one in South America, but two are planned for South Africa.  So, I'm looking forward to more services coming out of Africa.  Though the location of the planned Australia "Central" region is geographically questionable.

How was the Tech Summit app this year?

It was a smoother experience this year, but who on Earth thought that dark blue text on a dark grey background was a good idea?

Can you spot it?

Do the name badges still reverse themselves?

Yes.

Dealing with God Objects

(This post originally appeared at: https://www.linkedin.com/pulse/dealing-god-objects-duncan-k-g-campbell/)

At some point in the life of a programmer one will work on a legacy code base with an all-powerful, all-pervasive god object.

God objects provide a superficial simplicity that is all too attractive to both the novice and the stressed programmer. Placing all one’s faith in the god object feels like the right thing - it certainly feels easy, at first. The innocent programmer begins to fashion the god object, imbuing it with knowledge that no other object dares to possess. The god object becomes the answer to the programmer's prayers:

• Where is the control logic? The god object.
• Where shall I put this new logic? The god object.
• Where shall I find the state of the system? The god object.
• Where shall I seek out the answers to my questions? The god object.

But soon enough its complexities become unfathomable.

The god object’s mysteries need to be fully understood before one can make an alteration or an addition to the functionality of their realm.

Once the god object is all powerful the novice who does not understand its mysteries risks falling victim to its wrath as calamitous consequences are unleashed. Hours, days and weeks of debugging follow the tragedy as valiant efforts are made to clear up the mess. The new novice has now learnt that only the truly enlightened dare to approach the god object.

Documentation

The mysteries of the god object are great, and those mysteries are recorded in the great documents.
The elders tell you that only through deliberate study of the documentation may you come to understand the mysteries of the god object.

From the outside the documentation may appear to be a single document, but it is actually a collection of documents from various authors.

Some documents tell the story of the god object, of how it enabled the creation of the system. Others tell of how one has interacted with the god object.

The documents were written long ago, but often after the events they described. A few dedicated individuals attempted to keep the documents up to date, revising them, but in the course of doing that they introduced inconsistencies and even some contradictory passages, leaving the documents not wholly truthful.

In the past there were many more documents, but one day the management convened a meeting of the senior programmers where they argued about which documents should be included and which excluded from the definitive set of documentation. Eventually they agreed, and non-canon documents were removed and archived.

The novice programmer may find that the documents have little bearing on the current situation one finds oneself in. They were written a long time ago and the authors of the documents are long departed. This leaves one with different interpretations of those documents; in intrepid programmer may even seek out the previous versions of the documents in order to better understand the intent of their authors.

Child God Object

A time may come to pass when a child of the god object is seen to hold similar power as the god object itself.

This may lead to some confusion. Is the child of the god object a separate god object? Are the god object and the child god object really one god object that is both separate and indivisible?
Beware of creating new god objects.

Priest Class

The need to understand the complete mysteries of the god object act as a hindrance to change. Rapid progress in the system is thwarted by the need to fully plan for and test the consequences of each change throughout the whole of the system.

Instead of communicating with the god object directly an intermediary shields one from full exposure to the mysteries. Separating the concerns of the god object from those of the new functionality, the priest class allows one to communicate through priest objects acting as intermediaries. The new isolated functionality can be unit tested with the effects of the god object mocked. The calls from the priest class to the god object can be analysed and meditated upon in isolation from the new functionality.

One comes to trust the priest class, but one is never quite sure whether it understands everything the god object does. But as the priest classes become more prevalent it is important that different priest objects serve different parishes with their own particular congregations of objects and functionality, otherwise the priest class risks becoming as mysterious and all-powerful as the god object itself.

The priest classes may start off using the same language as the new features, but as new features are added they use new languages while the priest classes continue to use their own older language.

Eventually the priest class can remove all direct interaction with the god object, and one day some Zarathustra will say that the god class is dead.

Mob Programming: not as crazy as it sounds

Thanks to Agile Singapore I saw Woody Zuill speak about mob programming yesterday.

I'd been sceptical about mob programming at first, probably because I'd only heard the term and a one-line description of it rather than hearing from the main proponent of it himself.

The "mob" is not quite the whole team, the "mob" is all the right people being in the right place, at the right time, and working on the same problem on the same computer.  As it happens, that is also what a whole team should be: all the right people.  So, you do not need extra programmers, but you do need the people who know the requirements, understand the system, know how to test it, and sufficient to program it.

What's perhaps more interesting is that mob programming just evolved naturally out of the environment that Woody had cultivated - it was the right thing that needed to be done at that time and it was the right team.

What seeds had been planted to cultivate this environment?

For a start the team was used to working together on problems.  There were weekly study sessions, weekly coding dojo practice sessions.

The team was focused on getting better by effectively using retrospectives so that they could produce better results.

The team - the team of professionals - was also trusted to be able to decide for itself how best to work on something.

Mob programming then began when the team got together to re-familiarise itself with a project and its horrible code base.  Then they just started working on it together.  Then they just carried on, working together on one problem at a time.

Like pair programming, mob programming has a driver-navigator relationship, but in mob programming there is one driver and many navigators.  The programmer as the driver in a pair (or mob) is a "smart input device".  (This is unlike my first experience of pair programming when everything wrong was done, resulting in me acting as a typist for my partner without any thinking going on in my head.)


Mob programming also makes various problems just disappear.

Communication is not a problem when you have all the right people together in the same place at the same time.  The same goes for decision making and meetings.  Thrashing is also eliminated as one problem is completed at a time.

Having the whole team with the same attitude to quality acts as a barrier to the introduction of technical debt, so too does having the whole team understanding the system and working on one problem at the same time rather than producing dissimilar solutions to similar problems.

So mob programming is not as crazy as it sounds, but for it to work you need to have cultivated the right environment, which is not a bad thing to do anyway.

Innovation for Transformation at Agile Vietnam Conference 2017

Yesterday I spoke at Agile Vietnam Conference 2017 giving an updated presentation on TRIZ.  I'd taken the feedback from my previous presentation on TRIZ at Global Scrum Gathering Singapore 2017 and produced something with a bit more focus.  Rather than spending so much time on Genrich Altshuller's story and on the 40 inventive principles I instead focused more on the various tools for inventive thinking.

The end result certainly held together better.  This time I could go into more depth with the tools for inventive thinking and start to apply them to software development scenarios rather than spending half the time introducing the background then spending the rest of the time dancing around the subject and expressing my amazement at the marvellous discoveries.

Then next step is probably to develop some workshops to apply the tools in a group setting.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/innovation-for-transformation-agile-vietnam-conference-2017 

Some other highlights from the conference:

• Guillaume Duquesnay talked about Extreme Estimation - a key take-away was to remember that people are much better at comparing things than putting a number to something, which makes relative estimation faster and more accurate (or less inaccurate)
• Silvana Wasitova talked about High Performing Teams with reference to the McCarthys' 12 Core Protocols - I'm still not sure about the Check In with a statement of one's feelings...
• Kiro Harada gave his continually evolving Kaizen talk and introduced the Manifesto for Lazy Product Development; his mention of Muri (overload), Mura (uneven) and Muda (waste) struck a chord, particularly dealing with Muri before one can then deal with Mura and then Muda.

Google Cloud Partner Summit Singapore

Attended the Google Cloud Partner Summit in Singapore today.

Not quite the usual Mr Jacket-and-Jeans affair.  Though there was still the usual mix of commercial/account speakers (boring) and technical speakers (interesting).

Spoke to Øyvind Roti and he's also of the opinion that the current advances in machine learning should not worry humanity too much because computers are still to develop any real understanding of the world.  Until such time as they do, they are still very fast, dumb calculators that can be used for very fast identification of correlations rather than understanding actual causations.  Hmm, that's almost like a cargo cult...

Beyond Brainstorming at Global Scrum Gathering Singapore 2017

Yesterday I spoke at Global Scrum Gathering Singapore 2017 giving a presentation on TRIZ.  TRIZ originated in the USSR, but it is gradually gaining worldwide exposure so it is still relatively unknown.

Brainstorming is the intellectual equivalent of grabbing whatever is to hand, throwing it at a target and seeing what hits and sticks.  Humans have evolved further than our dung-throwing simian cousins, and so too has our understanding of innovation.

Genrich Altshuller's Teoriya Resheniya Izobretatelskikh Zadach (TRIZ), or the theory of inventive problem solving, consists of a catalogue of 40 inventive principles, a matrix for resolving contradictions and numerous mental and practical tools that can be successfully employed by anyone to solve any problem innovatively.

TRIZ emerged from a systematic study of patents, other innovations and how innovative people produce innovative solutions.  Despite the inventive principles and contradictions leaning heavily towards the physical world, TRIZ is applicable to all domains including software, people and not just the invention of new physical products.

In this presentation I aimed to provide the audience with an introduction to a number of TRIZ tools that they would be able to apply immediately to any problem-solving scenario, not just when thinking of product backlog items or resolving impediments experienced by Scrum teams.\

At the end I had some positive feedback on the subject, and some suggestions for how to improve the talk for a future presentation.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/beyond-brainstorming-innovation-for-everyone-global-scrum-gathering-singapore-2017

AWS Summit Singapore 2017

Attended the AWS Summit 2017 in Singapore today.

The keynote session had more members of the Jacket-and-Jeans family (see Microsoft Tech Summit), but unlike the Microsoft Tech Summit there was no ushering.  There were some not-particularly-executive seats reserved for executives, in the centre was the stage, but no ropes around it, so it's not a boxing ring.

Of course there was the usual disco taking place as people took their seats and introductions were made.

The speakers gave some compelling stories for why to choose AWS over other providers, particularly in the areas of innovation and the rate of innovation.

The talks for the separate sessions here all a "silent disco" with the keynote hall curtained into four separate quarters, each taking a quarter of the central stage whilst the separate audiences listened to the respective speakers with the aid of the radio and uncomfortable headphones included in the goody bag.

Between the sessions there were queues for booths (to get stamps for the draw), queues for cakes, queues for drinks, and queues for lunch.

The curse of the Demo Gods struck at least once.

The machine learning demonstrations did highlighted the lack of intelligence, artificial or otherwise, in machine learning - a picture of someone's face with a shadow cast over the eyes from an overhead light looks like sunglasses to the machine learning system.  The fast, dumb calculator of a machine may have learnt a correlation, but it does not understand what sunglasses are.

Microsoft Tech Summit Keynote Notes

(This post originally appeared at: https://www.linkedin.com/pulse/microsoft-tech-summit-keynote-notes-duncan-k-g-campbell )

Today I attended the Microsoft Tech Summit held at the Marina Bay Sands Convention Centre in Singapore. The Tech Summit stands out compared to the last conference-like event I attended at Marina Bay Sands, unfortunately it does not stand out for the right reasons.

The first thing to stand out was the event’s code of conduct.  This code was displayed at the registration counter and consisted of several paragraphs of good intentions and exhortations that attendees should basically behave themselves like civilized adults.  It is disappointing both that people should be asked to behave civilly and for someone to think that people need to be asked to behave civilly.

The second thing to stand out was the keynote.

If there was ever a keynote to leave me in dread of the rest of event then this was it.  Someone had decided in their wisdom that some level of theatrics was in order:

• thumping music (I hope nobody had come to the event with a sore head)
• coloured spotlights
• ushers with illuminated batons squeezing everyone down into the front so that we might sit like packed sardines (or simply cattle class airline passengers) in the chairs that are always arranged too close together
• once we were all squeezed into our seats the announcement was made that “Our shown is about to begin”, which only caused my heart to sink further.

The “show” started with a ghastly promotional video of carefully selected representatives with their corporate messages booming out over the PA system. Once this was over Mr Jacket-and-Jeans appeared on the stage and spoke at a bearable volume to introduce things and present some meaningless statistics.

Next on the stage was was the main act, Mr Jacket-and-Jeans-2, a marketing person. For a “tech” summit the keynote was pretty low on tech. He even cited Über as an example adopter of Microsoft solutions – does one really want to be associated with Travis Kalanick’s pet and its toxic culture?

Some people with unknown roles were brought up to demonstrate various things. Fortunately amongst them was Mr Jacket-and-Jeans-3 who looked like he’d done this sort of thing before and so did something interesting, despite his talk being replete with marketing buzz-phrases he did at least work through something in front of the audience and interacted with it in an interesting way.

Was the keynote a ploy to make one think that nothing that happened afterwards could be as bad as it?  It was certainly a relief when it ended.

There was no conference booklet with the details of the sessions, so I relented and downloaded the app, resigning myself to not being able to quickly browse the programme of events nor to being able to make notes or other annotations.  Having downloaded the Tech Summit app it took me several attempts before I remembered my LinkedIn password so that I might log in.  Once successfully logged in the app appeared to be stuck on LinkedIn.  Each time I opened the Tech Summit app I was faced with my LinkedIn home page – what to do?  Like all good IT folk I closed the app and started it again.  This time the app decided that it would show the actual event app instead of my LinkedIn home page.

Whoever designed the app likes scrolling.  After spending quite some time scrolling through the programme I tapped the appropriate buttons to add my favoured sessions to my own schedule, but when viewing my own schedule I found none of my selected sessions have been added.  Still, the trusty tactic of closing the app and starting it again solved that problem, where “solve” in this case means scrolling through the list of sessions again whilst trying to remember what caught my eye then adding those that did and checking that they had appeared in my schedule.

Fortunately, the technical talks which followed were well presented by people who knew their subject and those sessions contained interesting material.

I am yet again presented with the question: why do conference name badges on lanyards always reverse themselves? Are they linked somehow to buttered toast (which always lands butter-side-down when dropped) and cats (which always land on their feet)? Would buttered toast attached to the reverse of a conference name badge on a lanyard force the name badge to face forwards? Would a slight spin be induced? Would the propensity for the buttered toast to seek one’s shirt be the stronger force?

 (It was also noteworthy that there are no Microsoft data centres in Africa and only one in South America.)