“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!
“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.
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:
- Kill the speaker on the device
- Detect whether the user has been in a long-running phone conversation and kill that next
- 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…
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.
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.