Saturday, 29 July 2017

5 Things Writers Need From Developers

Developers don't like writing documentation in the same way that cats don't like having a bath. There might be the odd breed of cat that likes a bath, just like there is the odd developer who likes writing documentation, but generally cats and developers are quite predictable when it comes to baths and documentation.

But people like being able to get necessary-but-onerous jobs done with the minimum of effort, time and thought, and developers are no different.  So here is a list of 5 things writers want from developers. 


Don't provide a steam of consciousness brain dump about the work item you're documenting.  List things in some kind of order.


Can't remember why you added a radio button to the UI?  Don't make up an answer.  When you're not sure, tell us you're not sure.  If you know the name of someone who might know, give us that name.  We'll do some legwork for you.  But don't ever make stuff up.  


Not just about when you get the docs to us, but when you write them.  Yeah, the next piece of work you've been looking forward to is much more interesting that documentation, but tough luck.  Your memory is fallible and you will forget details of the work you've done.  So either document as you go, or at least document before you move on to the next piece of work.  It will save you and the writer a lot of pain later on as they have to spend time interrogating you and your terrible memory.


Also known as 5WH: What, When, Who, Where, Why and How.  WHAT was done, WHEN was it done, WHO did it, WHERE was it done, WHY was it done, HOW was it done.  If you take nothing else away from here, remember 5WH.  


Provide the same information every time in the same place.  Create a template.  Ask the writer to create a template for you.  Get every developer to use the same template and save it in the same place - a new Confluence page in the Release space for every work item, in the comments of the JIRA item, in a dedicated Slack channel for that release, in a README for every GitHub pull request, wherever works for the team.  Then do the same thing every time.

Some notes on the above:

  • There are pieces of information that it's just common sense to include, like the names of people who worked on something and the numbers of linked work items.  Forgetting to include these makes you look anything from unprofessional to incompetent.
  • There are pieces of information that the non-writer may not think need to be included.  Ask the writer if they want that information included.  This is one of the ways a template really helps.
  • Writers hate it when their work can be called into question, especially if it's because a developer has fed them some made-up information.  Reputation is important to writers, so don't make them look bad at their job. (This is a pretty good rule of thumb for all interactions in your life.)
  • Being part of the "too cool for school" culture that mocks people, especially developers, who write documentation is boring, unprofessional and frankly pathetic.  It's part of the "bro culture" that everyone hates (apart from bros, obviously).  It should be embarrassing to you if you get your kicks from ripping on other professionals in your office.  Stop it.  If you're reading this then hopefully you're not that kind of developer.  Spread the professionalism around your office as required.
  • Developers who write good docs are normally the better developers in the office.  Writing good documentation requires you to be able to step into someone else's shoes, as does writing good software.  The most respected (and best paid) developers I've worked with over my career have significantly overlapped with the developers who write good documentation. 
  • When all's said and done, developers need to communicate what they've done, whether they want to or not.  Learn how, become a better developer, become a better professional.


Sunday, 19 March 2017

The Craftsmen and the Chart-Makers

We don't make anything any more.

That lament has followed us through the years as a ghost floats above his killer, never seen with the fullness of the eye but always hovering as a mocking, aggressive reminder of what we've done to ourselves.  We've killed our ability to make things, outsourced it to the non-Western world in return for self-righteousness about the lack of pollutants in our post-industrial lands, while we wring our hands about the plight of the people in those barren places where the machinery has cooled and seized.  Statues of steel and rust in yellow, grey and brown, abandoned as a warning to our children, mnemonics to those of use who saw them in their prime, moving, growling, far too large to ever be killed, or so we thought. 

And who is to blame, cry all? 

The politicians! The corporations! The environmentalists! The unions! The liberals! The elites! 

Each one says, "But, 'tis not us! We only wanted a clean, technologically-advanced land, where people are educated, work is skilled and life is good! Why do you blame us for the best of our intentions?"

And the politicians blame the unions, the corporations blame the environmentalists, the environmentalists blame the market, the unions blame the liberals, the liberals blame the elites, and the elites melt into the ghost that haunts our waking and takes what's best from our sleep.

But many have never seen a post-industrial land, let alone an industrial one.  Their concern for what we make is limited to discussions about tax, custom tariffs, import and export ratios, figures upon figures arranged in industry-approved charts of all kinds, a blanding of the sweat, effort, sacrifices and pain of the makers into black digits in a white cell.  Not for them a life steeped in the stink of manual labour, the ache of muscles from a 12-hour shift, the primal satisfaction of using the power of your body to provide for your family.  These are things that belong to a different age, an age of flat caps worn without irony, holidays to the seaside, outside toilets, knowing your neighbours your whole life, living, dying, generations of people, within the same county border, the same town, the same village, the same factory or mine or mill, the same house. 

A German and his English colleague once talked with horror of man becoming a mere appendage of the machines, workers being no longer the means of production but lowly attendants on those mechanical monsters that have taken over the effort, the sweat, the pride of making things.  A portent of what is to come?  The chart-makers delight in this thought, this hope, for all they see is minimum costs and maximum production, a line on a graph that moves smoothly and predictably in their favour in a mathematically optimal way.  The messy meat variables are being replaced with pristine metal constants.  Is this not utopia?  Is a land built on the cool predictability of the voiceless machines not better than one uncertainly sustained by the chaos and noise of a directionless mass of writhing limbs?  So much chaos.  So much noise.  So much complexity, too much complexity, a rabble of variables that moves the chart further and further away from a prediction and closer and closer to being no more certain than a prophecy.  This is not what the charts should show.

The chart-makers say: These lives are an anachronism!  We don't need them.  We need the figures to balance in our favour, and if they balance in our favour then the anachronisms will have work to do somewhere else.  And eventually the figures always balance in our favour.  Eventually, but always.

All hail the chart-makers, for they shall inherit the earth! 

We don't make anything any more.

But we do.

The chart-makers just can't see it.


When steam relegated the horse to a luxury, the wailing sounded a keen note.  Blacksmiths, tanners, farriers, your services are no longer needed! You shall drive trains, mend engines, cast metal, all to feed the new metal equines!  Things will be more efficient, quicker, more productive.  We can do the work of 10 men with 1 man!  Those who tallied ledgers laughed excitedly at all the black ink they would need for their account books; surely red ink would be the preserve only of those unfortunate enough to find themselves on the wrong side of this revolution?  But red ink continued to be produced, and the crafts that had been practised for a thousand years were slowly forgotten.

Then, a century hence, the wailing begun again.  Steam?  A historical irrelevance! Internal combustion and electricity are far more reliable, efficient and predictable. No more water towers to fill and maintain at every station, no more coal stokers, no more steam engineers!  And these crafts also fell into abeyance, replaced with electricians and mechanics who each did the work of 10 men.  And still the red ink was needed by those who tallied ledgers, their initial excitement gradually worn away as their predecessors' had been, a sour cloud of unfulfilled expectations emanating from accounting rooms everywhere as those messy, unpredictable variables stubbornly refused to yield to the new technological constants that were supposed to do away with the chaos of manned labour.

After another 70 years or so, enough time had passed for those doomed to repeat history to believe that their time had come.  Computerisation meant that the electricians and mechanics, with their specialised training, knowledge of arcane physics and militant unionism, were no longer needed.  The mechanical was becoming the digital.  Slowly, gradually, inexorably, the levers of day-to-day power were moving further away from men whose hands were covered in dirt to men whose hands had never known such indignity.  The blacksmith had become the metal worker, who had become the mechanic, who was becoming the engineer, and soon he would become the developer.  The revolutions were coming ever quicker; even the accountants has started to work more with charts than ledgers, and it was only a matter of time.  The digital revolution was here and the remnants of the old revolutions needed to be purged to make way.  The mine, the mill, the factory, these were legacies from a past time that had no place in the new order.  Again the keening wail, frustrated and helpless in the face of relentless progress, again the inevitable loss of the skills and the communities that formed around them. And as before 1 man did the work of 10 men, and those who were becoming chart-makers thought nothing of this except as it affected the colour of the font in their new digital ledgers.

Now, we stand as our predecessors did 30, 100, 200 years ago, a decade or more after the last revolution and staring the chart-makers squarely in the eye.  We are caught frozen in a moment of calm before we tip one way or another as the momentum of the world shifts to compensate for the weight of the now obsolete craftsmen that have been pushed to the side.

But in their absence a new breed of craftsman has arisen.  The architect, the graphic designer, the UX specialist, the technical writer - these are the modern stone mason, printer, fresco painter, scribe. Plant maintenance is now IT Operations, the mechanic is the developer.  Where once we made horseshoes, now we build containers, where before we listened to our machine to find their problem, now we step through their innards and debug them.  Just as in preceding revolutions, the change has opened as much opportunity for us messy variables as it has closed previous avenues.

Of course the chart-makers would claim this was their certainty all along.  Opportunity for all!  But this time the opportunities can be grasped by people using the very tools that have pushed their existing skills to the side and that's not the doing of those who would measure progress using graphs.  For graphs measure things, but that measurement has meaning only to those who find it meaningful.  To those who measure things not by lines or trends or bars, but integrity, dignity and human relationships, the chart-makers' obsession with these numbers is a measure only of the distance between them and the craftsmen.

The chart-makers glide through white corridors, cradling the magic screens that give them purpose and value, to glass-walled sanctums of design and certainty.  Outside these numerical monasteries the craftsmen toil, designing, sweating, thinking, building, drinking, testing, checking, laughing, smelling, living, messy variables that defy the digital constants to produce the magic that runs the screens.  The craftsmen know that the numbers are malleable, because the craftsmen make the magic that shows the numbers. 

Everything the chart-makers do is allowed only by the craftsmen.  Every trend-line, pie chart, scatter graph, presentation, calculation, prediction and report, everything they drive, everything they wear, everything they use, their entire world is predicated on the craftsmen, because the craftsmen are everywhere and their magic has seeped into every item, object, tool, process, and system. 

We don't make anything any more. We make everything.

But the divide between craftsmen and chart-makers is wide, too wide for either side's truth to bridge. 

So the chart-makers continue, bathing in the sterility of their quiet, calm, rational numbers.   And when the next revolution comes and the digital craftsmen feel the impotent rage of obsolescence, the chart-makers will point proudly to their charts and proclaim "We were right!".  The brave new world will once again forget the skills of the craftsmen from this age but the trend-lines will keep going up.

The charts don't lie.  They never lie, not to the chart-makers.

What's the Biggest Challenge You Face with SharePoint?

I recently had a conversation with someone that went something like this:

Him: "So what do you do then?"

Me: "I'm a Knowledge Management Consultant.  I'm currently helping a client implement SharePoint."

Him: "Oh, that's interesting.  We've just started using SharePoint and we're struggling with getting the right branding and styling on our publishing site.  Any tips you can give me on working with their CSS?"

Me: "Not really, I tend to work on the content management and collaboration parts, rather than the publishing side of it. But the Microsoft help material is very good and I can point you...."

Him [interrupting]: "What do you mean, you don't do publishing sites? I thought you said you were a consultant?"

Me: "I am, but SharePoint is..."

Him: "So you don't know what you're talking about then?"

The conversation went downhill from there, as my interlocutor almost, but not quite, accused me of lying about what I did and got increasingly irate and frustrated. In the end we parted company with him still muttering and me shaking my head ruefully.

Now you might instinctively think bad thoughts about my ill-tempered friend, but that would be a knee-jerk reaction.  He was clearly struggling with a complicated and powerful piece of software, and meeting someone who might be able to bring some light to the shadows must have gotten his hopes up, hopes which I promptly dashed.  It's only natural that he was frustrated, even if he didn't necessarily express that in the most constructive way.  What's more instructive about this encounter is that it represented a microcosm of the way an entire enterprise often feels about implementing SharePoint.

If you've encountered SharePoint before then the likelihood is that your experience hasn't been overwhelmingly good.  I've met more far more people with negative things to say about SharePoint than I have people with positive things.  It's like the England football team - depressing, confusing, poorly performing, promising lots and delivering little.  But like the England football team, SharePoint's individual components are good, yet the sum seems to be less than the whole of its parts.  To continue this analogy one stage further, the management just doesn't seem able to turn a collection of good things into a better coherent whole.

The question is: Why not?

Let's start an answer to that with the obvious point that SharePoint is large and complicated.  If you have SharePoint then you're going have Microsoft Office, which increases both the size and the complexity by a significant factor.  Office itself can be pretty difficult to get to grips with as a whole, when you've got both client and online versions, as well as lots of tools that weren't in the traditional Office package of a few years ago, like Sway, Planner and Video.  Then there's OneDrive, which is actually just a personal SharePoint site with a front-end, and Power Apps, Flow and Delve.  The sheer number of these apps is dizzying, and they all work together if you want them to, and each one is a whole book and training session on their own just to get comfortable with the basics.  Even programs as venerable and well-know as Word, PowerPoint, Excel and Outlook have lots of functionality that most users never know about or haven't got to grips with.  Then you add a powerful electronic document and records management system like SharePoint on top of all that and dear Lord, where on Earth do you even begin?

This alone is enough to put a lot of people off, and not just users.  Designing, implementing, training and supporting that kind of enterprise-level suite of applications, with its mind-boggling array of options, parameters and functionality, is not a job for the faint-hearted or workshy.  For users it can be even more daunting because they're not supposed to be the experts and usually have very little time to dedicate to learning these tools.

The biggest part of this problem is that often the people deciding to use SharePoint underestimate the investment of time and resources needed to design, implement and support it, and they seriously underestimate the investment of time and resources needed to train users. Many a C-level decision-maker has seen a demonstration, or worked in another company with a successful SharePoint implementation, or seen that it's a highly-recommended tool by a relevant professional body.  These are all valid reasons (although not sufficient on their own) for choosing SharePoint, but they're not valid reasons for thinking that SharePoint is easy, simple or quick to implement and maintain.  If you've seen SharePoint working well then you can't even begin to imagine how much work has gone into making that happen.

It's worth saying as well that when users struggle with SharePoint it's not always because it hasn't been implemented well.  SharePoint is so large that you can't even hire a consultant direct from Microsoft that knows all of it to a significant degree.  It's also not the most intuitive experience, which makes learning it harder.  Training users is always easier when an application has obvious signposts and markers for the users, because once they've got a rough idea of how things work they can generally find their way around and work out how to do things using these signposts and markers.  But there are plenty of areas in SharePoint where these signposts and markers are missing, often because a certain feature or parameter is "owned" by one application within SharePoint/O365, so you can only get to it from that application.  This means a lot more rote learning is required to know how to do things.  On an application as large and complicated as SharePoint this means that the learning curve is high, which acts as a significant barrier to adoption across a business. 

When you take these problems together - the size, the complexity, the difficulty learning it - it becomes easier to understand why my frustrated friend felt like he was banging his head against a brick wall.  He's most likely up against a deadline, he's faced with a suite of applications that is so large it's very difficult to know where to start, and when he does start the amount of learning to be done must feel insurmountable.

All of which leads to the reason that many companies struggle to have a successful implementation of SharePoint: It's not a one-off implementation, it's an ongoing process of training, learning and incremental advances for the entire life of the application.  

Every user needs to be trained, and not just with a 60 minute introductory session.  Every new starter has to be trained.  Existing staff have to have access to refresher training.  Training material needs to be updated as new functionality is released.  Content and working practises have to be analysed so they can be successfully migrated.  Deletion, retention and preservation policies must be decided and implemented from the very start.  Metadata must be applied to migrated content and added to all new content.  Workflows must be designed, created and added.  Security must be applied.  And throughout all this you have to deal with the change management aspects by engaging the users, communicating the plans and timelines, quelling fears, and listening to concerns.  If you can do all this, and still meet your success criteria then you'll have a successful implementation.

SharePoint is not an application, it's a long-term commitment of people and time.

(Note: A cardinal rule on this blog is that I never discuss current or previous clients.  Nothing from this post should be inferred about any company I've worked for; as always this is a general discussion about issues that we find in our industry.)