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.)

LinkedIn’s Desktop Doublespeak

(Also posted on LinkedIn: https://www.linkedin.com/pulse/linkedins-desktop-doublespeak-duncan-k-g-campbell)

I previously wrote a rather general criticism of LinkedIn’s new website design and experience, likening it to Microsoft’s Windows 8 and the attempt to unify the experience of keyboard and mouse-driven interfaces on (primarily) desktop computers with touch-driven interfaces on (primarily) mobile devices. A seamless experience is a noble goal indeed, but there are differences between mobile and desktop devices. Also, the desktop offering is a web site whilst the mobile offering is an app – though it is still possible to access the web site from a mobile device. So, why should someone using one interface be restricted by the limitations of another interface rather than playing to the advantages of each interface?

My previous article also touched on the contrast between the uncritical adulation of the new design by the professional commentariat and the dissatisfaction voiced by individual users of LinkedIn and their own experiences.

I was in two minds over whether to follow up with an article on the same subject, but LinkedIn’s press release is still at the top of their own Newsroom page, so in this article I would like to delve a little deeper into LinkedIn’s own claims and see how those match up to reality as experienced by myself and others.

LinkedIn’s own press release for the new LinkedIn desktop makes a number of claims and gives a number of hints. Let’s examine the main points in this press release in more detail.

“Streamlined navigation: […] With one simple click on the “more” icon on the navigation bar you can also launch into other experiences that matter to you, like LinkedIn Learning.”

The “more” icon was renamed to “Business”, but it now appears as “Apps” – presumably some of the 3-times-a-day updates facilitated by the new technology stack that the press release also mentions? – but are the contents really “apps”? Also, the contents include Groups which was not mentioned in the list of experiences that matter to me and other users – a hint as to what LinkedIn thinks of the Groups feature?

“Smarter messaging that helps you connect and unlock new opportunities: With our new real-time messaging interface, you can message a connection wherever you are on LinkedIn.”

That’s odd because I tried to send a message directly to a contact in response to his status update in my news feed but couldn’t. That’s hardly helpful.

“Richer Feed to keep you informed: With a combination of algorithms and human editors working together, we’ve fine tuned your Feed to surface the most relevant content from people and publishers you care most about. We’ll also be adding new ways for you to dive deep into specific topics relevant to you and follow trending stories.”

This is perhaps my greatest gripe with the new LinkedIn experience: “relevant” content.

The people and publishers I most care about are the ones in my network; can I easily see their content? No. The feed is jumbled up by someone's or something’s own idea as to what might be relevant to me. If I could sort the feed chronologically – like one used to be able to do – then I would be able to easily see the content from the people in my network. LinkedIn is not a newspaper or a magazine where I am quite happy to accept that editors have an editorial line and will decide what gets published in what order, but I also expect the order of articles in a newspaper or magazine to stay the same, except for those “most viewed/commented/shared” lists.

In order for me to be better informed I read from a variety of sources and relish serendipitous discovery of new things. Algorithms (as they are generally designed to behave at the moment) are the enemy of such breadth and variety – watch one video by a crazy conspiracy theorist on YouTube and then see your YouTube recommendations fill up with more crazy conspiracy theorists. Such recommendation lists further funnel people into intellectual silos, a practice which is the antithesis of what it means to be intellectual.

“More intuitive search: You now have one universal search box to easily find people, jobs, companies, groups and schools. You can refine your search by using filter options on the right hand side, with the ability to search posts coming soon. Also, we're investing further to better understand signals on what they searching for? Or who you are searching for so we can bring you the best results for any search query.”

The search functionality appears to be fine, but it was not a major part of my interaction with the LinkedIn website so I cannot really say whether it has improved or not.

“Greater insight into who’s viewing your content: You can now see who’s reading and engaging with the content you share, including the company, job title and location of the people who are interested in your updates.”

I used to be able to see who’d liked my comments in Groups or replied to conversations I’d replied to in Groups, but not now.

I used to be able to see who’d liked or commented on my updates before, so what’s really changed for the better?

“Better suggestions to make your profile stand out: […]”

Those better suggestions include asking me to indicate my location when my location is already part of my profile.

I could also touch on how I now see less news on a single Feed page than before, how it is harder to scroll on the Feed page because of the delayed loading of images causing it to jump, h

ow the faster site is now slower, etc. but perhaps those things will be fixed as part of the 3-times-a-day updates.

I cannot help but think that LinkedIn is now a network that no longer has the benefits of a network, is a news site that lacks the benefits of a news site, and is a forum that lacks the benefits of a forum.

Scrum: my first introduction

I was first introduced to Scrum when I saw it mentioned in some job adverts in early 2006 when I was rushing to jump ship from the stricken SS Idesta. So I undertook the usual brief look on the web, but I don’t remember being that excited – I was more concerned about blagging that we had been doing iterative and incremental delivery.

When I found my new employer and started as a Senior Developer in April 2006 I was told that we were starting using Scrum in my aviation-focussed web solutions development team.  Our implementation of Scrum consisted of:

• occasional morning meetings to say what we'd done previously and were doing today - these were help around a table in a meeting room rather than standing up in a circle.
  
  From the morning meetings we did discover that everyone working individually, but someone might know about a particular application so you would know they were there for advice.
• keeping a sprint backlog on a spreadsheet indicating how much effort was left for our tasks.
  
  There was some confusion over how to update the backlog spreadsheet, such as how to record remaining effort for a newly-discovered task that was discovered and completed on the same day - which column to should one update with remaining effort, should it be the column for  today or tomorrow?
• tasks were allocated by the Team Leader.
• having a sprint planning meeting where the proxy product owner would explain what was wanted.
• after the sprint planning meeting was over, individual developers would return to their desks to estimate the effort required to complete certain requirements.
  
  Occasionally the Team Leader would ask you to review someone else's estimates - but there was no common understanding of what work was required for development, such as testing, documentation, release preparation, etc.

This process carried on for many months, and I would occasionally deputise for the Team Leader: allocating tasks, chairing sprint planning meetings and ensuring that people estimated tasks.

I later became the Team Leader for the team and introduced some new things:

• Pre-planning meeting between myself (team lead) and product manager (as proxy product owner)
• requirements and tasks on PostIt notes stuck to a whiteboard
• list of up-coming issues on whiteboard

(Though my recollection is a little hazy around this period.)

The whole department then had a presentation from Jens Ostergaard, a Scrum Trainer.  I don't really remember much of the detail, but the key point was to pitch Scrum at various levels within the organisation in order to achieve buy-in from parties at all levels involved in the transformation.

A few weeks later the presentation on Scrum from Jens was followed up with the Scrum Master Training conducted by both Jens and Boris Gloger.  We were mostly Team Leaders, Product Managers and other managers from the various different website teams.

Before the training I had not thought a great deal about Scrum nor thought that great a deal of it.  However, the training was a revelation for me, transforming my thinking regarding Scrum and regarding it as the natural way in which software development - and other kinds of product development - should be done.  (That easy adoption would introduce challenges later on because I had not experienced the mental conversion necessary to help me convince others of the benefits of Scrum - to me it was obvious and required little further explanation.)

The hands-on training really got us all thinking and we returned with a new purpose.

Immediate transformations were:

• more whiteboards, and larger whiteboards than the previous ones
• daily morning Scrum stand-up meeting, every day
• whole team involved in estimating
• proper breakdown of requirements into tasks of no more than 1 day duration
• team-wide understanding of what tasks are required to provide a solution to a requirement
• smallest granularity started at half-day, went down to hour (and minutes) with practice
• all tasks on PostIt notes stuck on white-board
• list of support tasks written on whiteboard

The enthusiasm drove us to be more imaginative and experimented with new ideas

• pre-planning meeting including the whole team
• UAT column on the Scrum board for requirements in UAT
• Ready for Release column on the Scrum board for requirements passed UAT
• Other teams used different-coloured labels to indicate testing status

That was my first introduction to Scrum before I moved on to other organisations.  That was the start of my Scrum and Agile journey.

LinkedIn's Windows 8 Moment

(Also posted on LinkedIn: https://www.linkedin.com/pulse/linkedins-windows-8-moment-duncan-k-g-campbell)

If you’re reading this on LinkedIn’s website, then welcome to LinkedIn’s very own Windows 8.

LinkedIn’s new website is slow, it has less functionality than before and the remaining functionality is harder to use.

The LinkedIn app for mobile devices already offered me little in the way of functionality so the bulk of my interaction with LinkedIn was via the web site.  Now those two experiences are barely distinguishable, both being as equally useless as the app was before and remains so.

Why, you might ask, is my ire so raised?  Why the vitriol when praise aplenty has been heaped on the new web site design?  Why indeed.

Searching the web for comments on the new website design leaves me to wonder whether I’m living in some sort of parallel universe as there is nothing but complete praise for LinkedIn’s new look and level of functionality from the professional commentariat.  But take a look at the comments on those articles (where comments are allowed) and there is nothing but rejection of the new design – take Wired’s article for instance https://www.wired.com/2017/01/new-linkedin-looks-just-like-facebook-smart-move/.

(Shades of the media living in their echo chambers and not recognizing the forces leading to M5S, Marine Le Pen, Geert Wilders, Brexit and Trump?)

What in particular do I find so distasteful about the new website design?  What is the oh-so-precious functionality that I miss?

The greatest loss for me is the loss of chronological sorting of items in the “news” feed.  The writing for this has been on the wall for many months since the default order became LinkedIn’s own random sorting of items rather than sorting by date.  Is it so perverse of me to actually want to see things in order?  Is it so unusual for me to want to look through the updates of the people in my network in the order in which they happened?  Why would I only want to see what’s “top” based on some echo-chamber inducing ranking algorithm that changes periodically so if I browse down through that list I suddenly see items from weeks or months ago in amongst things from minutes or hours ago?

Knowing what’s “top” – however that’s determined – is occasionally of mild interest, but give people the choice!

LinkedIn claim that the loss of chronological sorting is only “temporary”, but is that “temporary” like emergency powers, or is it temporary like the dictatorship of Cincinnatus?  I have my own suspicions.

The Jobs section was already sorted according to some unknown ranking, which make it useless for anyone to discover a newly-listed job posting.

It’s slow.

No, I don’t have the figures to back up my assertion, but it is noticeably slower than with the previous design.

For my profile views I now know next to nothing.  The total number of views over the last 3 months is useless.  At least the old graph as well as being able to see one’s ranking for views within one’s network or organization was entertaining.  That even provided a little bit of gamification, but alas no more.

The website and the app are now barely distinguishable.  Yes, it’s great to be able to share code and present a familiar look between web and app versions, but the app is for use with a device that has limitations in its user interface – fingers.  A website is something that is expected to be accessible to people from someone using a screen reader to people using keyboards and mice or fingers.  On a website I expect to be able to open all links in new tabs, now some of the links are magic links that don’t work like that.  Popping up a window when hovering a cursor over a button allows one to glance at something without having to open a whole new page, but now one has to open a whole new page instead.  Did I mention that it’s also slower now?

There are many other areas with diminished levels of functionality with people complaining about the changes to searching within one’s network.  There are also too many other nit-picking details for me to bother with here.

As for features having been moved around, I’ve come to expect that.  I’ve even done it myself in products in order to group functionality in a more logical fashion.  But should Groups really be found under Business?  Seriously?

Sadly, we’re not members, for if we were then we would have a say in this “club”.  Instead we are users: users of a product that is our own data, for that is what one is in any social network even when that social network is for business and career networking and advancement rather than sharing cat videos and writing ungentlemanly abuse at strangers from behind the cloak of anonymity or pseudo anonymity.