10 Sep 2019
One of my favorite times of year is October. There are almost too many reasons to count (my birthday, my twin brother’s birthday, autumn, black heritage month, and on). Hacktoberfest is without a doubt an annual highlight for me. To make it successful year-to-year, I’ve had to adapt.
At this point in my career, coding at work means picking up a neglected project, where I know I can take my time on it without falling behind, or without stepping on the toes of a team. Hacktoberfesting is also a great way to stay technically current and capable. It’s also a place where I can see what folks are dreaming up, what problems they are confronting, and where there are gaps. It’s nice to feel like one can lend a hand to keep them going. And seeing a pull request get merged? The giddiness never goes away for me.
It’s become more popular every year, which is great for the community, but I must make adjustments on my end. As a person that can only dedicate certain segments of time, I’ve found myself jostled out of issue fixes by multiple folks who have more time available. I’ve seen PRs die due to infighting by maintainers. I’ve also seen development environments disappear (e.g., deciding to remove docker support in the middle of October). As such, I’m writing this post because I think there are some worthwhile tips to make hacktoberfest a good ride. Here are several things you can do to make it smoother.
1. If you want to learn: make it at most 45% new.
I like to make it a learning experience while I’m at it. It’s a great opportunity to pick up something new. The problem is, if it’s completely foreign, it’s going to be hours of research and ramp-up in order to make a pull request effective. But, coming in and saying “don’t try anything new” is the kind of advice I would ignore. Once, I worked on a scala project as a way of getting familiar with the language. I picked a critical math library, and I dove deep, and it felt good. I found the commit that broke builds for them, and although I studied linear algebra in college, it proved to be too time-consuming to unwind the actual issue. Translating concepts that I long-ago grasped into a language that I was still learning, in tests that were not well documented…. Ultimately I never got my t-shirt that year, even though I’d made tremendous progress.
So, I like to make it at most 45% new. Perhaps the language is familiar, perhaps the library is somewhat familiar, but maybe you’re learning a new thing as part of it. It could be a new CI system, it could be a new kind of webservice, similar but different to ones you’ve worked in before. It could be a new language, but one a repo that is fairly uncomplicated. You’ll come out of it a bit more knowledgeable, but you’ll also be able to make an impact.
2. Don’t get a repo that’s too conflicted.
Some of the repos I really like working on are very popular, well-adopted, and well-supported. You’ve got the classic hits: your requests, your activerecord, your moment. Those foundational repos that folks know about in rando developer conversations. A couple years ago, I put in a pull request to a foundational framework. There had been a ticket sitting there for two hacktobers, and the ticket itself was written very prescriptively (removing a security hole in images on the default 404 page). The solution wasn’t even in a new programming language; it was in an HTML template. So I went boldly forth and put in a pull request that matched the request. It felt like an incremental step forward. Then I watched the pull request fall into a debate amongst core contributors. Sometimes, incremental improvements are not wanted on mature repos. Instead the incremental work exposes much deeper issues, and that’s what ends up being debated and sinking any progress. (I see this kind of pattern everywhere; not just open source repos.) Sometimes these repos likewise have enough cooks in the kitchen that viable pull requests are sidelined by internal debate. Don’t get me wrong, I could have done better, too. Even when submitting it, I was thinking, “this is what they wanted, so…”
Some repos are well-maintained and have mechanisms in place where foundational questions can be answered (or better, they are already answered in a CONTRIBUTING doc.) But for some repos there are hidden requirements or preferences at play, and pull requests can get sidelined. Even if a repo is popular, I avoid it unless I’m deeply familiar with it anyway. Fact is, the simple issues get addressed as a matter of normal development.
If for some reason the popular repo is running squeaky-clean and there’s little to no friction getting a pull request merged, I’d still be racing against other contributors who have more time on their hands. I’ve seen several efforts left permanently on a branch on my machine because someone came in and banged it out in a full day, when I was doing it on the side.
Overall I avoid the popular or mature repos (for Hacktoberfest) for those reasons.
3. Don’t get a repo that’s too immature, either.
Another side to this equation is a repo that is so new or under-supportd that the hacktoberfest issues are super fundamental. For example, “add CI/CD” or “do performance tests”. These are foundational things that the maintainers perhaps value, but not quite enough to invest in themselves. As far as pull requests go, they can sometimes be very chunky. Adding CI/CD for example, requires admin access if you’re serious about getting it on the source repo. It is possible to set it up on a fork of course, but the act of getting it merged is much larger and requires coordination or even requesting a deeper level of access on this repo. My main concern with this approach is, again, if you want the minimum number of pull requests to qualify for your t-shirt, you’re signing up for potentially a ton of effort for that one pull request.
4. Choose nice maintainers
When I am close to choosing a repo or issue to work on, I like to look at past pull requests or open issues. Sometimes the maintainers are unhelpful or even jerks, particularly to people that are new to the repo. (Sometimes these are new programmers, and sometimes they are experienced programmers that just don’t know the expectations of the maintainers.) Ideally, I will see a maintainer giving feedback to a pull request or issue. Are they respectful, no matter the contributor? Do they repeat themselves without getting irked? If there is code feedback, is it positive (even if it’s direct)? There is an opposite problem as well: someone that notices you are comfortable fixing up things, and piles on requirements after you have a PR.
If you’re thinking, “maintaining a repo is hard,” I agree with you. I was the maintainer of a high-traffic Jenkins plugin a few years ago, and indeed I would see questions or pull requests that covered the entire range: sometimes a person saw an exception and didn’t read it, but posted it and asked about it (oftentimes unrelated to the plugin), and there were also questions going into implementation details that I’d inherited where I didn’t have a great answer, or even time to dig into how those decisions had been made. Maintaining an open source repo is hard, but if you truly value open source contributions, you need to value open source contributors and avoid the 7 deadly sins.
5. Make sure it’s easy to test
Some repos ask for rigorous tests with a local test environment. That doesn’t bother me at all. But if the repo is going to take hours of set up, then I may never get far enough to contribute. If there are unit tests already, simple setup for local development, or other easy levers to pull for validation, then I’m in for a good time. I personally feel strongly about verifying my changes, so I like to look at what that process is going to be like, from beginning to end.
5+ If you worry about agreements, make sure you agree with them first
I’ve also been caught up with the legal agreements associated to contributing. One repo had a legal agreement associated with it. This is common and honestly it’s usually a good sign of a well-run repo. However, in this particular case, the fine print was a bit harrowing for me. It included giving up rights to things I didn’t even write for this particular repo, even things I’d written previously! I probably could’ve signed that agreement and nothing happened, but tbh I’d be losing a bit of sleep over it. If you’re the kind of person that worries about these things, take a look at that early.
Ultimately there is a sweet spot for repos where you can fly in and make a meaningful contribution. This is the Goldilocks Continuum.
The Goldilocks Continuum
For someone with time constraints, the ideal target has repos and issues that don’t get much traffic, but still get something. That means I’ll be able to work on a nice, chewy issue for several days when I have free slots, but I’ll have a good likelihood of feedback or even a merge without another hacktoberfester swooping in and knocking it out in a day. Alternatively, I need issues that are super easy and can get done in one sitting. So the Goldilocks Continuum for me looks something like this:
- Repos that gets hits, but not too many hits
- Maintainers that care about contributors
- Subject matter that is a little new to me, but not completely foreign
- Minimal set up, but not completely naked of development practices
- Issues that will take up the right amount of time
Good luck this October
It’s a great time to contribute back to the community that has likely driven success for you, your learning, your company, and on. If you feel good about contributing open source software, then take some time in October, contribute, and get a free shirt. Everybody wins.
27 Feb 2019
The popular phrase “Death by 1,000 Paper Cuts” usually refers to a problem that kills a company, team, or product because there are too many little problems adding up. Today, I reflect on the opposite problem: too many nice things. Let’s call it Death by 1,000 Paper Napkins.
It’s a Malthusian nightmare of features or functionality. The app, the users, or the products die because their space is so crowded, they cannot nourish themselves.
In my experience, I’ve seen this occur in a few different ways:
- Noise
- Feature bloat
- Complexity
Noise
The classic example of noise is too many pop-ups. Most of what we see today are the different ways a website can claim to help you. There are interruptions to introduce you to chatbots, there are help pointers and there are intro modals. In isolation, each of those can be useful and helpful, but adding them all together turns into a wall of noise. The website becomes unusable. From the perspective of accessibility, it truly can become unusable, if keyboard interaction does not allow a user to close a modal, toast, etc. This might sound like an exaggeration, but I’ve seen it without even trying. Noise like this rarely starts as a sudden blast of sound; it slowly rises from a murmur, and this is where there is risk.
This kind of problem plagued websites and applications in the late 1990s and inspired a host of desktop applications and browser plugins that still exist today. If we are too abusive of toast notifications and the like, we will see a similar cottage industry arise. In the near-term, you might simply be driving users away from your application to a quiet competitor.
Bloat
Another form of noise comes from a good thing: capabilities. We get many capabilities with minimal effort if we pull in 3rd-party applications to do the work for us. It’s a completely sensible development or business decision: buy vs build. Without a holistic view however, it adds up. I previously worked for a company that used a total of four different analytics tools to gather user information. Those tools were used by different departments, but it resulted in heavy pages for end-users. Even when reducing sync transactions the overall transaction load on browsers was heavy, and the page weight itself was heavy, too. Many analytics tools do not want you to cache their tooling either, which means end users are carrying that weight around as they navigate.
Another manifestation of this overload is in product features. When user experience drifts from simple to complex, it does not happen suddenly with one feature. Rather, it slowly adds up over time. UX thinkers among us have attempted to make this measurable (interesting posts here or here ), with things like surveys, number of clicks needed to accomplish tasks, and other metrics. Having many features isn’t necessarily a problem on its own, but if user experience is not a highly held value across teams, you may have a dedicated cadre of power users and little else.
Complexity
In the ebb & flow timeline of frameworks across the industry, some become more powerful and more complex, leaving openings for “new, simple <insert framework type here>”. You not only see this on products and websites; you see this on frameworks. It is not always a problem, but it can add up to one.
A great example of this is in the configuration settings. This could be for a user, an application, or a framework. How many configuration points do you have for running your application? How about your users? How far back does backwards-compatibility go? When using all of the default settings, how easy is it to spin up your product? These are applicable questions when thinking about configuration sprawl. The larger the sprawl, the more expensive changes become due to testing, risk, and so on. Of course, sometimes sprawl is ok. The more widgets you have to adjust, the more powerful the system becomes. It’s the unfettered expansion that can result in suffocation.
Complexity and sprawl is another important area to measure; and it’s not a matter of counting configuration duckets. Indeed, complexity can be measured when thinking about things like cyclomatic compexity. But value – particularly for configuration items or backwards compatibility – can be approximated when measuring usage. When building an application that is installed onsite, for example, this is often a step that is overlooked and costly down the line. If there is some level of phoning home or other (safe, reasonable) approaches to providing telemetry on how your product or framework is used, then it can become much easier to accurately foretell which napkins are disposable.
1,000 Paper Napkins
Similar to 1,000 paper cuts, death by 1,000 paper napkins can only be avoided by keeping that count under 1,000. It’s a healthy dose of discipline along with prioritization and, potentially, drawing some lines you refuse to cross.
25 Nov 2018
Users are smart people, and they all operate in a place where they don’t need to use their smarts to navigate a website. They are focused on a task and don’t even think about the way they do it causing a catastrophic event. When discussing user-experience, I’ve been in scenarios where I’ve heard folks say “a user can figure it out”, but that’s the sound of an echo-chamber.
I’m describing some examples here, each one leading to the user’s untimely demise.
John Denver
Many folks know that John Denver died in a plane crash where he was alone, but most don’t realize it was because of bad user experience design.
I’ll do my best to summarize for you the NTSB findings and excellent, well-sourced wikipedia section.
Denver’s father was a colonel in the US Air Force, and as a result, Denver had grown up around airplanes, eventually flying them, and he understood both the dangers and the possibilities. By the time he hopped into the cockpit on October 12, 1997, he’d logged over 2700 hours of flying in many types of aircraft.1
Denver in front of his aircraft.2
As I’ve learned, it’s not uncommon for airplanes to have multiple fuel tanks, and a pilot may need to switch the tank s/he’s using mid-flight. This is generally a straightforward maneuver. Perhaps for obvious reasons, one does not want to operate for very long without access to fuel. The plane he was flying had been built out of a kit, which is a practice that still occurs to this day. Denver did not build it himself; someone else did, but switching the tanks had been explained to Denver before he began flying. (In fact, this was his second flight in the aircraft, but the first where switching tanks became a necessity.) When he took off from the airport he had plenty of fuel, but it was clear he’d need to switch tanks during the flight.
To switch tanks in this plane, Denver had to reach over his shoulder and toggle the tanks behind him. He was given a vice to help him reach the fuel tank controls, which is pretty similar to tying wooden blocks to someone’s shoes so they can drive. He also was given a mirror he could use to look behind him. I’m not kidding about this. He had to reach over his shoulder with one hand gripping long pliers, and use a mirror with the other hand, all while keeping the plane flying. If something seemed wrong or he needed a closer look, he’d have to twist his body and look over his shoulder. A very instinctual way to do this was to swivel the body and push up with his foot. In this manner, one could end up pushing on the banking pedal and take a sharp turn to the right.
Based on 4 observers that saw the crash, the plane took a sharp bank to the right before going down. When the plane was recovered, it was found that the fuel adjustment was halfway done.
It was not only tricky to understand how to do it, but it was difficult for a user to execute. The user actually was doing the best he could under the circumstances, but ended up falling into a lethal usability trap.
Monostable shifter
The Monostable shifter was the reason for a recall in over 1.1 million Fiat Chrysler vehicles in 2016, and could be the cause of multiple deaths.
There was minimal user feedback, including letting someone know that they had successfully put a vehicle into the park position. As noted at the time by David Tracy at Jalopnik, “The mushroom-shaped unit does not slide up and down entirely the way a traditional automatic shifter does, but rather can be moved back or forward while changing gears, after which it then returns to center.” Tracy quotes the National Highway Traffic Safety Administration:
…operation of the Monostable shifter is not intuitive and provides poor tactile and visual feedback to the driver, increasing the potential for unintended gear selection.
In other words, it was hard to tell whether someone had put the car into park or not. In fact, according to Tracy, the difference between reverse and park was incredibly subtle. If a user made a mistake and opened the door without the car in park, there was no feedback to let the driver know the car wasn’t parked.
Anton Yelchin was famously killedAnton Yelchin when his Jeep Cherokee pinned him against a wall in his driveway, and many pundits believe it is because of the confusing gear shifter. By the time that had happened, there had been over 250 crashes, and nearly 70 injuries reported due to this shifter. 4
Some fixes of this issue included warning bells or even automatically parking the car when the door opened. Either way, the drivers were used to operating one way, and this particular vehicle had a different way of doing the same thing. This is a classic UX anti-pattern: a rote task that users must unlearn.
Linkstorm on healthcare usability
Sadly, there are too many examples of usability issues in health care to really pick from. I can’t decide if marking patients with an X for where they need a transplant is a usability problem or a usability enhancement. But here is a series of links.
I could keep going, but it’s turning into LMGTFY which reflects poorly on both you and me.
Bad UX hurts, friends
Consumers and users are smart, it’s true. But we do them a disservice by assuming that they will put all their wattage on solving problems that they expect to be simple.
1: Much of this section on John Denver is taken from a well-written description on Wikipedia.
2: Photo is copyright 2018 from fototime; however, attribution beyond that is unclear. See comments here.
3: monostable shifter photo
4: “FCA bedeviled again by shifters”
07 Aug 2018
I believe complete strangers have more power over us than we realize. My wife is a teacher, and years later I still get irritated thinking about what an anonymous user said in an online newspaper commentary about teachers. Strangers can also sum up others in a frank and direct way. They have less time than an elevator pitch, and they react to a situation, even if it’s as simple as seeing your face for only a few seconds.
Granted, there is a fair amount of noise: misinformation, neuroticism, and misplaced cruelty that come from strangers. Every once in a while though, we hear nuggets of usefulness. This post is an attempt to honor the good advice I’ve received from people that are not my friends. Some of them used to be friends, some of them were acquaintances, and some of them were complete strangers.
Pablo, 1992, “When someone leans in like this, they might stab you”
Fortunately or unfortunately, I’m not very well educated in gang warfare, but I’ve lived and gone to school in places where gangs have an influence over the culture, down to how you walk. I learned to walk with my head down, hoodie up, keeping as much to myself as possible, without any sort of challenge towards others walking along the street.
Pablo was a guy at my school whose brother was in a gang, but was trying to keep him out of it. Pablo and I had gym and history together, and once after school he came close to me and put a hand on my shoulder. He said, “if someone puts his hand on you like this like he’s leaning in for a hug? He might be about to stab you, like this.” And out of nowhere, came his opposite hand, right into my stomach.
Good advice. It’s like the next layer of “keep friends close and enemies closer.” Sometimes your enemies are trying to keep you close. More than once I’ve found myself in a hostile work environment when someone is suddenly being a pal, letting bygones be bygones, only to realize a knife was coming my way. So I generally get extra paranoid when a poisonous or hostile person is unexpectedly buddy-buddy. Thanks, Pablo.
Al, 1998, “You can’t just say something’s ‘awesome’”
I read The Stranger during Spring Break one year, while we were driving deeper into Texas to visit my sister. I had heard about it of course, and had always meant to read it. So, I soaked up that one and followed it up with Paulo Coehlo’s The Alchemist. I read both books on the drive, and I thought they were each awesome. When I got back to school, I was in another car with a friend and a sort-of friend, Al. He was a smart man and one of those where, upon graduation, you’re convinced he’s still going to do something academic. He was also an English major, and when I pointed out how I thought The Stranger was awesome, there was an uncomfortable beat. Then he gave me this advice. His point was that I sounded ignorant. That stung but he was giving me a valuable perspective. In some circles, critical analysis is the secret handshake, and bland text is a liability.
Now, I’m still going to call things awesome, because I like to enjoy awesomeness. However, the lesson I learned from this advice is twofold: (1) know your audience, and (2) some people criticize things to sound smart. I’m not kidding on that last one. There are some circumstances in which folks need to constantly establish their authority. In those situations, naked enthusiasm is a sign of weakness. (I think that’s a terrible truth.) Largely I try to avoid getting mired in places thick with this, but that doesn’t mean it’s truly avoidable. So, it’s good to adjust as needed.
Ex-girlfriend, 1999, on running.
After seeing me out for a run, I got some advice from a woman I was dating. She’d been taking a triathlon class, and she pointed out how much vertical energy I was spending, rather than using that energy to propel myself forward. I needed to lower my shoulders and lean into the run more. In essence, I was doing more jumping than running.
I think this advice has farther implications than running technique, though. More than once I’ve found myself looking at or even taking opportunities that were somewhat pointless exercises: expending energy without actually propelling my skills or my professional life forward. For example, I spent about 4 months on an analytics project at a former company, and I had spent most of my time either acquiring permission to systems, or waiting for someone else that had permissions to develop on those systems with me. Somewhere between 60 and 80% of that time was spent hitting this wall and trying to find alternative approaches to avoid the wall. I had enough blockages and impediments that it dawned on me: I was spending important career cycles for something that ultimately I was not receiving support to do. I decided to write up my architecture plans and put them on the backlog. I called out that the team I was helping should pursue it since it had to do with guaranteeing data integrity, and then I moved onto another project. I hated to declare something incomplete, but I was getting feedback and questions about what value I was adding in general, so it was clear things were heading in the wrong direction professionally. Closing up work on that project was a great move on my part. I shifted to things where I could get home at night feeling I’d accomplished something, and soon, my coworkers and superiors noticed, too. Had I spent more energy jumping up and down, I’d have found myself in a rut.
Ramón, 1993, “Your breath smells, dude”
Yeah, that one was embarrassing and hurtful. Somehow we were both leaning close towards a candy machine as we were feeding it coins. But you know what, I took his advice and went nuts buying tictacs. Now I like to have a constant supply of gum and Altoids. Nobody likes bad breath, pal, so do something about it.
Various forums and product reviews, 2005-present
This is the noisiest of the noisy. There are trolls, there are bots, and there are jerks. We could have a separate blog/post on how to weed out noise properly, but I’m leaving that out of scope for this entry. I’ve read countless forums and product reviews, weeded out the noise, and made some decent decisions before treating my lawn, fixing something in the car, or even buying a product. Praise to the heartless strangers that just spew what they know, even if it’s layered in hatred!
CPR Training, late 90s, “Don’t worry if you hear something breaking because on the first couple of pumps you’re breaking up cartilage.”
This is old-fashioned attention to detail. Both as a student and as a sometime teacher or mentor, I’ve found that details can completely derail someone. Even though it’s verbose, I like to give as much detail as possible. There’s a nuance to it, of course, in that I don’t just jump into detail. I try to prepare a person beforehand, and tell them: I’m giving you a brain dump and you can throw away whatever you don’t need. This is because I will not be there when that odd situation comes up, and those details can put a hard stop on important things, like pumping lifeblood. When I was working with an overnight, offshore team in a previous job, we got back to the office one morning to discover that they had encountered an error, and then sat at their desks for 8 hours because they didn’t know what to do. That was a waste of everyone’s time and money. So, in this case, we were sure to give them not only guidelines, but specific instructions, too. When odd things came up, they knew how to pivot and keep moving.
Jaime, 2006, “It’s an adjustment”
Honestly I still consider Jaime a friend, but we’ve only had one indepth conversation in the last 10 years or so, and perhaps that means I can list him here. We worked together during the time my wife and I became parents. As a soon-to-be father, I would hear two extremes: (1) “your life is ovah!” and (2) “your life will forever change for the better”. I’d been spending time in the mornings writing, essentially pursuing a dream, and the mentality from either version 1 or 2 was telling me that the time for dreaming was ending. Jaime though, nodded and thought for a second before he said, “it’s an adjustment.” He was the only person that did not paint fatherhood in some sort of extreme. (This includes the literature. Deciding to pick up a crying baby was either the only thing you should do, or the absolute last thing you should do, depending on which book you were reading.) The mentality that Jaime injected into that situation was critical, and it was through that mentality that my wife and I made life changes without completely gutting the lives we’d already built. Instead of leaving the house early to go write, we instead experimented with writing at home early in the morning, or on the weekends, until we moved and I began writing on the train ride in. But I did not abandon the writing (at least, not for several years, and not due to having children).
Casting a major life change as an adjustment brought stability to the overall vision without completely upsetting it.
A Slovenian in a hostel, 1998, “You should go to the hospital.”
While traveling, I slipped down the side of an outcropping and jammed my leg, twisting it in a crevice. I walked on it for 3 days thinking maybe it was just a sprain? I mean, even if it couldn’t bear weight and was badly swollen, it wasn’t that bad, was it? (Indeed, I had a hairline fracture.) Fact is, sometimes a person just needs to hear a concrete next step, rather than an assessment. If he had said, “your leg is broken,” then I would’ve waved it off since he wasn’t a doctor. Ignoring, too, how the bruising was strangely spreading to my toes. But instead he gave me a step to take. This still felt like a big deal, but it was easier to walk to a nearby hospital than to speculate what the next 8 weeks would look like. This made it feel small enough where it was worth the effort.
We don’t treat broken legs in software (well, at least not the software I help develop); however, we do solve large-sized problems. The best way to procrastinate is to look at how great the effort size is, or how fundamentally different life would be afterwards. But getting there is usually incremental. Breaking the work down into concrete steps – where you can see improvement without actually committing to steps beyond that one – is a great way to get something moving. And it’s true: you could take that first step and then realize more time won’t be worth it, in which case, you’re relieved.
Guy that gave me a ride, 2000, “Sorry. I’m usually not racist.”
This isn’t advice, but it is a statement that’s hard to erase. For about two weeks, this guy gave me a ride to work from Southie. He was a nice enough guy (I mean, he offered to give me a ride every day while his wife was out of town), but he had just said a racist slur I’d never heard before. We were on the highway and a car had dangerously swerved into and out of a non-existent exit (maybe it used to be a bus stop?). The guy had to slam the brakes and, although he didn’t raise his voice, he let fly a few slurs, shaking his head. I am not repeating what he said because that would just give it more power than it deserves.
First I had to absorb what the slurs meant. There are several racist comments that are powered by stereotypes, and sometimes I just don’t know all the stereotypes. But second, I was surprised. Massachusetts, home to the Massachusetts 57th infantry, surely was bereft of racism, right? (Indeed, I clearly needed to be taught a lesson in this area.) The third part of it, which is dead-clown-funny, is that some folks think that racism is temporal. He taught me a lesson: people are bigoted even if they don’t think they are. After my experiences growing up, after traveling to Northern Ireland in the ’90s and seeing The Troubles, I’m convinced that just about everyone has prejudice. What’s important is having the humility to recognize it’s always lurking. That humility allows folks to keep it in check, at the least, and perhaps change some part of their world views.
Unsolicited advice
I’ve heard plenty of bad advice, too, and over time hopefully I’ll get better at figuring out the signal-to-noise ratio. I’ve also heard plenty of hurt, ranging from how I look, to my race, to my belief system, to what people think is my background. I’d like to say I can easily discount it and ignore it as crazy/wrong/misdirected, but occasionally there is value if I take a few minutes to evaluate what I’m hearing.
11 Jul 2018
The class I took in college on Transition Economies was one of my favorites. My professor was a brilliant man with a soporific voice, and I’d scan the room to see heads nodding off, but I found it fascinating. At the turn of the 21st century, “transition economy” generally referred to countries that were adjusting to post-communist life. In those sectors of Europe, things as fundamental as buying a carton of milk or even how to do your job were significantly changing. Entire countries were altering how they did commerce. It was the whole system, too, all the way from how to pay people based on their job or skills, up to creating industries that had previously been government-controlled or simply did not exist. It wasn’t only changing a system, it was shifting a culture, too.
This kind of thing happens in organizations, too. When thinking about adopting a large change such as adopting Agile for an organization, I think of it from the perspective of organizational behavior. There were two extreme ends of the spectrum to making the transition: do it gradually, or do a shock treatment. (Pardon the out of date term; I’m pulling from my out of date textbook.) Each approach came with pros and cons of course, but this is how I look at making changes within Engineering, such as adopting Agile Scrum or SOC2 processes. An organization needs to decide where they land on the spectrum.
1. Gradual Shift
At its most extreme, a gradual shift would be unnoticeable to the folks doing the work. The system would evolve over time to follow certain practices, with workflow changes of minute differences until one day everyone looks around and realizes that they are already executing the Scrum, SOC2, or simply, the New Way and need to announce it. Of course, that’s extreme! In reality, an organization may decide the New Way is what they want, and make small changes over time, marching towards that goal.
On one hand, this approach is not very disruptive, kind of like sculpting with a chisel or even a toothpick. The personnel will basically get ample time to adjust to changes and arguably this means they are invested naturally with minimal distraction. The same went for a post-communist economy: slowly auction off government assets, slowly loosen regulations on the areas the government controlled, and the economy makes adjustments, ranging from building a certain amount of widgets, to learning new skills. In the reality of our engineering organizations though, detractors that have never bought into the New Way could bring a persistent sag to morale. In her book, The Change Monster, Jeanie Daniel Duck points out how critical it is to get proper buy-in, and to handle detractors aggressively.
When looking at a gradual model for a company, buy-in will be much deeper in the organization’s roots, and the system could easily feed itself into improvements over time. However, getting this wrong can result in problems that are just as deeply rooted, so the gradual approach needs full attention for the whole ride.
The most obvious cost to this approach is the amount of time it will take to complete. That’s a central point in the decisionmaking that an organization will have to weigh. If an organization has time (or decides to take the time), it could be the right fit, giving the culture time to shift with minimal impact on the short-term. Arguably, the longer something takes to implement, the more sustained the impact will be.
2. Shock Treatment
This is the other extreme: yesterday you are not an Agile Scrum or SOC2 or New Way shop, today you are. Essentially the approach is: swift and resounding. The benefit of this approach is its unequivocal nature: the org is adopting the New Way without a doubt. It goes into effect on such&such a date. Like a big bang software release, this approach will only be successful with proper preparation. Detractors will be more obvious as well, making it clear where there is disagreement so it can be managed. With a shock approach, arguably management attention can have a shorter lifespan on this issue than in a gradual approach. (Arguably. The caveat is that there still would need to be enforcement after adoption.)
In a study of this approach in transition economies, it was found that wages were sticky once they were set. In a similar way, if tweaks need to be made after adopting the change, it will be harder to put them in place and harder to be successful at it. This is partly because there’s limited feedback and fewer change agents in place, and having that kind of organizational dialogue can be stifled. This can result in confusion and inconsistent adoption of any changes.
Ok, So Which One?
Using transition economies as a reference point is helpful for me when weighing the options and coming up with an action plan for an organization. I’ve experienced each of these approaches both as a leader in organizations, and as an employee. The important variable for me has more to do with the appetite for change among the employees. Working in engineering, you see a broad spectrum of folks that are open to change and innovation, and others that fight against it. I’ve seen behaviors along these lines up and down the development chain, whether it is writing unit tests, building a different feature, or adopting a new deployment model. So indeed for me, the soil I’m working with has a lot to do with my own strategy. In general, I side more with the gradual approach; however, I’ve implemented shock changes that have been effective as well.