Content Filter Wish List

As we kick off 2017, rather than making a New Year’s Resolution focused on my own improvement, I’m here to spell out my hopes for someone else: my favorite social media frenemy, LinkedIn.

Clearly, the good folks at LinkedIn have ignored my previous suggested remedies for getting back on track, and continue to morph into “FaceBiz.”  If Facebook can tailor its “news” feed to the biases of its users, perhaps LinkedIn can help me tailor my feed to only those things that give me actual business value.

Therefore, LinkedIn, please consider my fantasy list of content filters below, and give me the option to block:

  • Any graphic illustrating the differences between a “boss” and a “leader” (am I the only one who reads those and thinks, “being the boss sounds awesome?”)
  • Any photos of a well-equipped cubicle awaiting the new employee
  • Any photos of training class attendees sitting attentively in a training room
  • Any photos of trade show attendees having discussions at a trade show booth
  • Any photos of business professionals sitting in airplane seats en route to a training class or trade show
  • Any picture of an inspirational message written on a whiteboard, easel pad or tablet
  • Any request to “like” the notice of a dying child, an aging vet, a deceased spouse, or any other deeply personal tragedy to which the word “like” should not apply and that could not possibly benefit from a random list of gullible mouse-clickers.

Perhaps, if I had these options, I would be motivated to grow my network, rather than pare it down, as I am actively doing now.

As a software developer, I know that the logic to implement the above filters is quite difficult.  Therefore, I will propose a very easy alternative.  LinkedIn offers several choices to react to content, including “like”and “share.”

  • Like:  Tell the author that you appreciated the content
  • Share:  Tell your business network that this is content worthy of consideration.

However, my feed shows both types of activity from my network – I see all of your “likes” and your “shares” equally in my content stream.

I will henceforth reduce my wish list down to one request:

  • Only show me what my network “shares” and not everything they “like”

I will gladly take it from there, using the “Unsubscribe” option on anyone in my network who actually “shares” how many pens their new intern is getting.

My Phone Doesn’t Need a Haircut

“I just need a haircut,” I said to the lady.  “Sure, what’s your phone number?” she replied, fingers ready at her keyboard.  “I’m not in your system, I just need a…”  She interrupted.  “Ok, just tell me your e-mail address and I’ll get you in here and then you’ll show up on the waiting list.”

“I don’t want to give you my e-mail address.  I just want a haircut.”

She looked stunned, and a little hurt.   “We don’t give it out to anyone.  We just need you in the system.”

“I don’t want to give you my e-mail address.  Can’t I just come in here and get a haircut?  I’m going to pay cash.”

Even more stunned.  “If we don’t have you in our system, how do you get your hair cut?

Now it was my turn to be stunned.  “With a scissors?”

Lately, it seems that every retail chain, franchise barber shop, gas station or fast food joint now gives me a chance to be part of their own program.  Sure, there are some benefits to be had, but are we really at the point where program membership is expected for everyday purchases?

These “loyalty” programs are theoretically an exchange of value: I give them access to my personal data for demographic data and future targeted marketing, and they provide me some value in terms of discounts, early access to specials, or some enhanced level of service.

In the case of the haircut, the “enhanced service” consists of keeping track of which clipper to use and whatever other notes are relevant.  So, maybe it saves me 10 seconds of conversation (provided I want the same thing every time), while I’m already a captive audience.  As my industrial engineering friends would say, it’s all internal motion.

Typically, during the ensuing 20 minutes of haircut captivity, the associate will continue to sell me on the benefits of the program.  I will explain, in my best “grumpy old man” tone, that I’m just tired of being in everyone’s system.  The news reports data breaches every week, and IT policies are only as durable as CIO job tenure.  That’s usually enough to make them drop the subject.

Yesterday I stood in a long line of holiday shoppers, only to have the sales associate start my own checkout process with an attempt to find my loyalty number.  With a growing line behind me, he automatically  proceeded to the “new member sign-up” process on his screen.  I had to tell him twice that I didn’t want to sign up.  By that time, I was a grumpy old man.

This is another case of technology improvements making us worse as people.  Even as these programs enhance their customer engagement experience for those who opt-in,  they are not valuable in the eyes of all customers.  Associates  should still expect (and respect) customers who prefer anonymity.

In other words, retail associates: don’t be offended if I don’t want to give you my contact information to buy a pack of gum.  I’m just not ready for that kind of commitment.  It’s not you, it’s me.  I’m sure there is a whole generation of Millennials that will be just perfect for you!

Story Points: It’s the Thought that Counts

“Do you have an estimate on how long writing the new software will take?”

To the questioner, it’s a completely reasonable question.  New software is required and many other decisions hinge on the timeline and cost.

For the software developer, however, it’s often the equivalent of asking, “when will the world end and how?”  We’re sure there is a way to figure that out, but it’s going to take time and effort to dig into the problem before giving an answer.

This then, starts the invariable cycle of frustration.  “Well, when will you know how long it will take?”  “You’re now asking me to estimate a duration for the estimation of a duration?”

In trying to measure the unknown, the software industry has embraced various approaches over the years, including Lines of Code (LoC) throughput rates, Function Point Analysis (FPA), and the Story Points estimation of the Agile world.

Any method that is based on resulting quantities of code artifacts, in my view, is inherently flawed.  We as developers do not strive to solve problems with the most lines of code, nor the most complex algorithms.  Our best work results in the fewest lines of code.

That’s one of the reasons I really like the story points concept.  Story points are not required to be a specific measure of anything concrete.  They reflect how the development team understands the problem to be solved, relative to previous problems solved.

Many developers struggle with this as they first encounter Agile.  “But what ARE they?  Hours?  Days?  Functions?  WHAT?”  It’s very hard to embrace a measurement system of something intangible.

As I’ve struggled myself to explain answer this question, one line of thinking came in handy:  What is the real output of software development?

It’s not the “lines of code,” for reasons I noted above.

It’s not measurable in “programs,” “screens,” “reports” or “object classes” or anything else whose boundaries and quantity are completely arbitrary, based on the individual developers involved (and may not reflect good decisions).

What we sell, in this business, is “thought.”  Code is simply the final delivery vehicle.  It’s the effort to break down the complexity of a problem, a challenge, a requirement, and use the tools available to craft a solution.

We might solve the actual problem while using a whiteboard, or scribbling on a bar napkin, or writing a document, or prototyping, or feeding the ducks.  The point is that the,actual keying in of code, compiling, building, etc., is only part of what we do.  When we focus our estimating on those activities, of course it’s going to be incomplete.  The actual valuable work is what goes on between our ears in getting to that point.

Story points allow for that.  Story points allow us to quantify, by relative comparison, the time it takes to solve similar problems.  Not just “write code,” but “solve problems.”  Problem solving is thought.  We can’t predict the exact amount of thought it will take to think through a problem.  The best we can do is draw a comparison to similar exercises in the past, which is where velocity comes in to play.

Understandably, this will be a hard perspective to embrace, for both developers and their customers.  Our stakeholders, in particular, may reject this explanation as a stall tactic, or a deflection.

Here is one possible path to get them on board.  Get a book of mixed puzzles.  It might contain Sudoku, crosswords, logic puzzles, story problems, etc.  Now ask each stakeholder to estimate how long it would take to complete all the puzzles in the book.

Some might outright reject the request.  Some might boldly offer a ballpark estimate, already planning a game of “schedule chicken” should they be held to their word.  Some might request more time to analyze the book.  How many Sudokus?  How many pattern matching?  How many that I’ve never seen before?  Some may venture to assign ranges to each type of puzzle, based on their own personal experiences.

Most will concede that, even if past timing data was available for each puzzle type, there will still be variability and unpredictable errors, snags and retries.  Almost no one would think that, since every Soduku requires 81 digits filled in, an estimate can be based on some per-digit number times 81.

Of course, this doesn’t satisfy those stakeholders who must commit to rigid limits of time and money.  It does, however, provide a mechanism to illustrate the variability inherent in software development, and make a compelling case against selling to-be developed software at fixed bid budget and delivery dates.

Fixing LinkedIn

In 2003, a social media platform named LinkedIn emerged to meet the needs of business professionals.  Rolodexes were quickly becoming extinct.  An increasingly mobile workforce, combined with a quickly globalizing economy, made even electronic contact lists difficult to maintain.  Enter LinkedIn, your permanently current, business rolodex.  You and your contacts are free to move about the industry, and thanks to LinkedIn, you never lose touch.

Besides the obvious benefits of personal contact storage, users benefitted from secondary networking.  “Who do I know at …” or “Who can introduce me to …” are some common examples.  The recruiting community justifiably came to see it is the Garden of Eden (sans forbidden fruit). Of course, as a subset of the self-organizing glob that is the internet, LinkedIn Groups emerged, further slicing the network by industry, skills and geography.  At the time of writing, over 2 million such groups exist!

As the community grew to it’s current 300 Million+ members, something completely unsurprising happened:  it lost its original focus and intent.   Corporate accounts took to the practice of posting daily PR, encouraging (sometimes compelling) their own employees to “like” every PR blast and job posting.  Worse, the “Facebook” behavior settled in, with individuals and sneaky advertisers posting math problems, motivational posters, and other appeals for “likes” (contacts) that quickly propagate throughout the network.  Of the latter category, some are simply despicable.  Never will I believe that the only wish of a dying child is to collect a million “likes” on a business networking platform.

Frankly, the amount of usable or even interesting content has diminished greatly.

So, solve THIS if you are a genius: how do we get back from the abyss to make this platform relevant and valuable again?

My answer: self- and community-enforced organization.  If users are required to categorize their posts, and the community-at-large can keep them honest about it, then the UI can be tailored around that organization.

Step 1: Self-categorize When I’m posting, I know 100% of the time whether I am posting:

  • Corporate PR (with or without personal embellishment)
  • A job opening
  • Distraction content (the cat-hanging-from-the-tree poster)
  • Actual original content, like this blog

Therefore, as a content provider, I am in the best position to categorize my contributions.  I should be required to enter a category before my posts are accepted.  Ditto for LinkedIn itself – the content it generates (updates on job changes, work anniversaries, etc.) is all intentional and can be categorized just as easily.

Step 2: Community enforcement Mis-categorizations will happen, either by honest mistake or deliberate attempt to bleed out of a category.  So be it – the community can detect it right away, and will happily flag such mistakes.  Repeat offenders can be denied access, just to make it stick.

Look at Wikipedia – there are enough people willing to give their own time to police the submissions.  As a result, the factually inaccurate content very quickly turns into grammatically correct factually inaccurate content!

Step 3: Leave the stream Am I the only one who finds content streams to be the least intuitive development in the evolution of computing?  The concept of a content stream is this:  we have gathered all of the known information in the world, and here it is in chronological order.  It’s like asking a grade-schooler what happened in school today, and in the ensuing reply, the double-knot in Jimmy’s shoe lace is relayed on equal par with the principal’s nervous breakdown.

Humans, by nature, categorize.  It’s why we have good things like the candy section in the grocery store and bad things like racists.

The UI should give me an option to view by category.  Let me choose when I want to look at career changes / milestones and when I want to go look at corporate shills.  Let me choose to never see someone’s stupid math problem challenges.  Don’t show me in 10 different notices that 10 people “liked” or shared the same link.  Organize for me!  This is a business platform!  Time is money!  (I’m imagining wearing a monocle and smoking a big cigar as I type that.)

Now, I realize that what I’m requesting is a major overhaul of content and its relation to consumers, as well as user experience.  But hey, don’t be discouraged!  To quote this cat I just saw on a tree limb, Hang in there, baby!

Impersonal Devices

Do people get so suckered by the moniker “personal device” that they believe playing videos, music or games with the volume up, in small public places, is somehow not audible to those around them?

Airplanes, waiting rooms, and basically any other public space where annoyances already abound are now also subject to the child, or worse, adult, who has yet to grasp the dynamics of sound waves and nearby ears.  Hey look, that Candy isn’t going to Crush itself, but I know for a fact that the volume setting is optional.

Really, these folks are today’s version of those folks from yesteryear:


The personal device space has advanced so far in such a short period of time, cramming more and more functionality, speed and sophistication into smaller and smaller devices.  But what is hasn’t done is crammed more and more courtesy into the same old people.

I’d like the makers of personal devices to turn their innovation towards something of significant societal value: making their owners better participants in society.  While we are still probably years away from building a reliable “scowl detection” algorithm in every device, at least we could all be equipped with a universal kill switch that mutes the speaker volume on every device around us.  Détente would take it from there.

Phase II would advance the tech to detecting the sound of heartbeats in close proximity.  If those heartbeats start to all rise at once, it would, in order:

  1. Kill the speaker on the device
  2. Detect whether the user has been in a long-running phone conversation and kill that next
  3. Realize there’s something even worse happening and call 9-1-1.  It could put them on speaker.

Sure, users might bemoan the loss of their inalienable Right to Annoy, but the gains in the Right to Not Have Your Device Thrown into the River would likely make them soon forget.

And yes, this applies to YOU, lady who chose the closest bench in the whole empty park to sit and listen to your Calypso music…

Pair Programming? Sure. Pair Shoveling? Not so much…

I’ve been reading about Agile methodologies and the SCRUM approach to software development recently, as I prepare to institutionalize the practice throughout my organization.

One of the methods highly espoused by some Agile aficionados is “pair programming.”  In this method, two developers literally share a single computer and take turns on the keyboard. The “observing” developer provides immediate feedback to the typist should anything appear fuzzy in the logic being written, while also considering the bigger picture solution.  After 30 minutes or so, the roles switch, and the keyboard gets handed over.

In theory, some amount of logical errors (bugs) are avoided when the program survives the scrutiny of two independent minds.  Pairs may be changed around regularly to avoid developers getting into a groove and thus losing the “independent minds” benefit.

Some developers bristle at the notion of letting another developer into their brain space so intimately, while others have tried it and swear by it.  Some of the studies indicate a slow-down in initial coding but a significant enough reduction in bugs and other long-term maintenance / rework to more than justify the change.

Personally, my jury is out on the whole concept until I get more experience with it – actually see it in my own teams and hear from my developers.  It seems like a good mechanism for continuous sanity checks, but I know there are minds that like to solve problems in private before sharing ideas with others.

However, I did see something recently that requires no more data, no more empirical studies, for me to know it’s a bad idea: Pair Shoveling.

I had the good fortune of spending the holiday break with my family on a sunny beach in the tropics.  Every couple of days, the resort would comb the beach for the mounds of seaweed that the constant, pounding waves deliver, non-stop, to the shore.  The team consisted of a tractor with driver, and two men tasked with digging a pit.  The tractor combed the debris and continually dumped the contents into the pit.  The shovel-wielding job consisted of digging out a larger and larger hole in which to bury the debris – staying ahead of the tractor’s endless onslaught.

The men shoveling really did not work well as a team, and in fact their productivity was half of what it should be.  This is because, perhaps in a failed attempt to be Agile, they were sharing a single shovel.  One man shoveled while the other watched for 20 minutes, then they switched.  All the while, the tractor kept on delivering more and more debris to be buried.  Repeatedly, the shoveling team would realize that the pit must be expanded, which meant displacing again the sand piled up around the current borders of the pit.

I won’t pretend to understand the economics, politics or logistics that led to this job sharing arrangement, and mean no disrespect to the two men trying to do honest work with inadequate equipment.  My comparison to pair programming is, of course, tongue-in-cheek.  However, watching the spectacle with a SCRUM text in hand, I couldn’t help but reflect on the unorthodox approaches we try in pursuit of excellence in the software industry.  The shoveling team I observed were not helping each other dig a sufficient pit, they were merely relieving each other.  They didn’t stave off rework, as the pit had to be expanded at least five times while I watched.  They were not improving methods or finding more innovative ways to shovel.  They were just taking turns shoveling.

I’ve read that pair programming really has little benefit on repetitive, already “solved” development activities that require little innovation and limited diligence.  Shoveling.  The best benefits are realized when charting new courses, solving new problems, etc., when the first thought of a single developer is unlikely to be the best answer.

We can safely use a mix of pair programming and singles in many projects.  Not every project is 100% ground-breaking such that some of the routine work can be done solo, probably by newer team members coming up to speed.

We can also raise the awareness within the team that when you find yourself “pair shoveling,” partnering on something that is not benefitting from collaboration, it’s time to make a change:

  • Break up the pair, and power through the work individually,
  • Move on to a different challenge, if the shoveling deadlines can still be met (that tractor never stops!),
  • Turn some of the problem-solving energy to automating the mundane coding itself – if it’s not challenging, it should be ready to automate.

I don’t know if “Pair Shoveling” will make it into the Agile lexicon, but for me, it will serve as a reminder to use the correct tool (and correct number of tools), for the job at hand.

The Path of Least Resistance

I recently overheard a conversation between several senior employees of a firm that, apparently, had experienced rapid growth.

Like many such firms, the senior folks were bemoaning the loss of the “old days” when employees just “did the right thing.” In this idyllic past, employees did the right thing because it was the right thing, and not the easy thing. Today, they cried, the easy way wins out, even when it’s not for the company good.

This got me thinking. The first thought was, have I always been an eavesdropper? The second was, should I admit it in my blog? I guess you know the answer to the second question by now.

I’ve been in the small company mode. Success depends on adrenaline and heroics. Altruism is easy when everyone knows each other. The “good old days” end when the growth necessitates the first real batch of “strangers” into the mix.

After that, reality settles in. Shared values and passion can no longer be taken for granted, and you have to assume that macroscopic laws take over.

Most notably, the work will begin to follow the path of least resistance. This is the “easy way” these seasoned fellows were bemoaning. Certainly, individual employees will always step up to stressful situations, and carry the day. Passionate endeavors will spur innovation and growth. But over time, the dominant trend for “how the work gets done” will be the path of least resistance.

In my view, it is the job of management to make sure the path of least resistance is also the right path – the path we want to take. To try and re-build a startup-culture or get our employees on an endless cycle of adrenaline is folly. The only sure way to get things done right is to make sure that the barriers to that approach are eliminated and the desired way, the “right way,” is also the easiest way. Otherwise, we are battling a force of nature that hasn’t lost yet.