DaedTech

Stories about Software

May
8

By

The Larger Significance of the Royal TDD Rumble

Category: The Life of a Programmer | 15 Comments

Let’s Get Ready to Rumble

Tomorrow (this) morning at 11 AM Eastern time, the world is going to tune in on Pay Per View to the greatest rumble this side of the Thrilla in Manilla that pitted Muhummed Ali against Joe Frazier. Nearly 40 years after the original, the 2014 incarnation will pit the creator of Ruby on Rails against the creator of Extreme Programming and the TDD approach as well as an internationally acclaimed author and speaker in and about the field of software engineering. The venue will be google hangouts. Get your tickets before the internet sells out.

The reason for the brouhaha? A post entitled, “TDD is dead. Long live testing.” From there, a long series of subsequent posts, debates, arguments, etc ensued across the development world. So, after a couple of weeks of this, the battle was set between the TDD antagonist and a couple of proponents. Or something like this. (Might be that this isn’t a death match, since Martin Fowler explained, “We hope to be witty and entertaining, but we are more interested in exploring these topics in a way that expands our understanding of each others’ ideas,” but what’s the fun in that?)

Boxers

Of late and I guess in general, I’ve written a lot of posts about unit testing, automated verification and test driven development, so suffice it to say that I’m a fan of this practice. So, one might think that I’d watch this hangout rooting for Fowler and Beck to win, the way I root for the Chicago Bears on fall Sundays. But to be honest, it doesn’t really bother me that someone, even a well-respected and widely known industry figure, doesn’t do things the way I do them. I don’t need or even want everyone to agree with me if for no other reason than this state of affairs would present me with new ideas to consider. If DHH doesn’t find TDD to be beneficial, I’m sort of curious as to why, and I might disagree, but it’s no skin off my nose.

Might Doesn’t Make Right

The tone of this post started off breezy and satirical, but I’d like to get a little more serious because I think there’s a lot of effort, money and happiness at stake. There are two competing attitudes at play in the hubbub surrounding this conversation and pretty much any tendency toward disagreement: “my way worked for me” and “my way is the right way.” I try hard — so very hard — to be someone who says or means the first thing. It is my sincere hope that this attitude permeates any blog posts I make, content I publish, and talks that I give — that they all have an implied “this is based on my experience, YMMV.” I might not always succeed, but that’s my goal. I take this with me at work as well; even with people that report to me when I’m reviewing code I don’t tell them what to do, but instead offer what I would do in their situations. I think this is critical with knowledge workers. It becomes a matter of persuading rather than forcing, which, in turn, becomes a matter of needing to earn respect rather than “might makes right.”

The reason, I think, that the Expert Beginner series resonated with so many people is because the Expert Beginner is “might makes right” incarnate, and it’s something that has invariably squashed your motivation and made you hate your life at some point during your career. Expert Beginners say “my way is the right way” and even “my way is the only way.” This is a characteristic of micromanagement and lack of vision that reduces knowledge workers to brainless cogs, and therein lies the effort, money, and happiness to which I referred.

I’ve left projects or even jobs to avoid “might makes right” Expert Beginnerism, and no doubt so have you. This is lost opportunity and value. Poof. Gone. 2 weeks notice, “knowledge transfer,” on-boarding, and starting all over. Running in place for organizations and projects.

Now, all Expert Beginners tend to think, “my way is the right way,” but not all people who think this way are Expert Beginners. In fact, some are legitimate experts whose way probably is a great way, and maybe even “the right way.” It’s human nature, I believe, to think this way. People form opinions and they want others to agree with those opinions. If we decide that a gluten free diet is really the way toward better health, not only do we expect others to be interested in our newfound wisdom and to agree with it, but we’re even offended when people don’t. I’ve been bored to tears watching this phenomenon take place over and over again in my Facebook feed.

As humans, we seem naturally to want our advice to be heeded, our opinions validated and our approaches mimicked. In my travels, I started doing TDD, and I found that it helped me tremendously and made me more productive — so much so that I post about it, create courses on it, and teach it to developers on my teams. So, if someone comments on a post about it saying, “that’s just a bunch of hippie crap,” my natural inclination is to be offended and to feel combative in response (and indeed, phrased that way, confrontation would appear to be the goal of such a comment, no doubt coming from someone who felt that my posts were an affront to the approaches he’d found to be helpful).

But I try to fight this as much as I can, and listen more to other people and see if I can understand why they do what they do. The irony is, this approach, counter to human nature, is actually in my best interests. I learn far more by listening to what others do than evangelizing for what I do. It’s hard to go this route, but likely beneficial.

Now, I’m not attempting a relativistic argument here to say that if someone’s experience is that they’ve “enjoyed success” by shipping non-compiling code that’s just as valid as someone who delivers reliable software. It’s not that everything is just a matter of feelings and opinions. Approaches and outcomes can and should be empirically measured and validated so that objective, collective progress can be made. Approach X may indeed by better than approach Y, measured by some metric, but those in camp X should be persuading and demonstrating, rather than shouting and flaming.

I doubt the software industry is unique, but it’s the one with which I’m familiar. And it’s frankly exhausting at times to see how much time people spend getting worked up and defensive because someone doesn’t share their love of some framework, approach, or technology. It becomes heated; it becomes personal. You’re an unprofessional hack because you use programming language X. You’re a sellout because you buy tools from company Y. My goodness people, settle down. Honest debates and exchanges accomplish a lot more for everyone. The esteemed gentlemen having the hangout tomorrow to discuss the merits of TDD seem to be favoring the “cooler heads” approach and it’d be nice for everyone to follow suit.

I think test driven development is the best approach to writing software to which I’ve been exposed (of course, or else I wouldn’t do it). I think that if you have an open mind and are willing to try it, I can persuade you that this is the case. But maybe I can’t. And maybe, there’s some as-yet undiscovered approach that someone will show me and I’ll be sold on that instead. Whatever the case may be, I’d like to see these types of exchanges favor attempts at persuasion as opposed to shouting, heated personal exchanges, or, worst of all, “might makes right” types of fiats. And, I think at the end of the day, we all need to come to grips with the knowledge that not everyone out there is going to share our opinions on the best way to accomplish a task. And hey, if your way is really better, it sure looks like you have a competitive advantage now, doesn’t it?

Apr
6

By

I Give Up: Extroverted Barbarians at the Gates

Category: The Life of a Programmer Tags: | 16 Comments

Someone sent me a link to the video shown after this paragraph the other day, and I watched it. I then tweeted the link and sent it to a few of my coworkers because I figured it would make people laugh. It’s really funny, so give it a watch. But weirdly, I didn’t laugh. I watched it over and over again, mesmerized. I recognize that it’s funny and I find it funny, but I didn’t laugh.

https://www.youtube.com/watch?v=BKorP55Aqvg

This video is really a work of genius because it captures some incredible subtleties. There are two common archetypes captured nicely here in the form of the protagonist’s supposed allies: his boss and the project manager. I’ll give them names in their own sections below, along with the client characters. And then there are conversational tactics that bear mentioning.

This all revolves around a protagonist with whom any introverted person can identify. There’s nothing to indicate, per se, whether he’s introverted or extroverted, but the precision, the mannerisms, the posture — all of these scream “programmer” (or at least “engineer”) and so goes the association with introversion. The protagonist is the sole bulwark of sanity against a flood of idiocy, misunderstanding and general incompetence. You probably relate to him, having attended a meeting where all of the gathered C-levels and analysts thought you were being an obstructionist malingerer because you wouldn’t install Angry Birds on the meeting room’s television.

So who are the players?

Chamberlain

In a way, I liken the smarmy project manager, Walter, to former British prime minister, Neville Chamberlain, most remembered for his foreign policy of appeasement leading up to World War II in which he sought to dampen the aggression coming from the Axis powers by essentially “befriending” them. In this particular video, Chamberlain, the project manager, is presumably along to bridge the gap between the non-subject-matter-expert customers and the total-subject-matter-expert protagonist (and whose expertise makes the video eponymous). That’s not really why he’s there (though he doesn’t realize this), and I’ll get into that later as I’m describing tactics.

Chamberlain perceives that his best interests are served by simply agreeing to whatever is happening on the other side of the aisle, improvident though this may be. On some level, he’s probably aware that this strategy is stupid, but, hey, that’s a problem for later. He thinks his boss will skewer him if they don’t get the contract, so the fact that it’s going to be hard or impossible to deliver (what Expert is trying to tell him) just means he’ll later throw someone (i.e., Expert) under the bus.

Dilettante

The “design specialist,” Justine, is a mildly interesting character. She generally looks at Expert with some degree of respect and looks slightly uncomfortable when the rest of the characters make fun of Expert. At one point, to Expert’s delight, she even understands his point, and she visits him after the meeting out of genuine interest in the project and what is probably a “one pro to another” kind of overture. She’s the only character in the room that sees any value in Expert, and she probably recognizes that his subject matter knowledge exceeds hers and has value. If it were just her and Expert, she would probably listen attentively. I call her Dilettante because she seems to be the type of person you encounter with a bit of knowledge in a variety of fields and a genuine interest in improving.

Buffoon

The client’s boss is a classic MacLeod Clueless, and a simple idiot that isn’t very interesting. She’s the classic archetype of an over-promoted middle manager whose value is clearly wrapped up in company tenure. She spouts nonsensical jargon, torpedoes her firm’s own interests throughout the meeting, and serves up her position and her firm’s money for easy pickings by any MacLeod sociopath that happens along. She’s demanding something that she doesn’t understand in a way that makes no sense, and she’s willing to pay any huckster that comes along and sells her the magic beans she’s seeking.

Buffoon

Sociopath

Big Boss Man, to whom Chamberlain reports, is a classic MacLeod Sociopath. He likely has a fairly good handle on the situation and is of the opinion that the clients are idiots, but he has an intuitive understanding of the politics of the situation. Expert is flummoxed by the stupidity of the client proposal, and Chamberlain is simpering in an effort to show his boss his value as a diplomat, believing that the customer is always right and believing that Sociopath also believes that. Sociopath doesn’t. He knows the clients are idiots, and that Chamberlain is also kind of an idiot (for evidence of this, look at his expression at 6:14 where he clearly thinks the discussion of cats and birds as lines is dumb and simply ignores the client).

This doesn’t result in him rushing into defend Expert, however. That’s counter to his best interests, which I’ll address as a tactic, but he also finds Expert somewhat distasteful. Sociopath has navigated his way ably to money and power and a position atop the corporate hierarchy, but it is probably a slight annoyance to him that he may not be the smartest guy in the room. He knows that in Expert’s area of expertise, he’s nowhere near Expert, and while that’s fine, his inability to compare their relative intellectual worth across subject areas is a source of irritation.

Tactical Gamesmanship

So, the ostensible point of this meeting and no doubt many in which you’ve sat is to define the parameters for a project and then successfully launch that project. But, if you were to read the subconscious goals of the players, they would go something like this:

  • Chamberlain: I want to get the client to sign off no matter what, and I want Sociopath to think it was my heroics that made this happen.
  • Buffoon: I want to order people around and show off.
  • Sociopath: I want this to be over quickly so I don’t have to listen to Buffoon and Chamberlain.
  • Dilettante: I want to learn on the job without it being apparent that I’m doing so.
  • Expert: I want to define parameters for this project and successfully launch it.

Sociopath knows that getting Buffoon to agree to the project is a veritable certainty going into the meeting, and he knows that Chamberlain’s presence is valuable, but not for the reasons that Chamberlain thinks. Chamberlain thinks he’s there because he’s a “straight shooter/smooth talker” that “speaks Expert” but Sociopath just wants him there because he understands how to butter Buffoon’s bread — by causing Buffoon to think she’s won an exchange and humbled an Expert. He’s there because Sociopath knows he’ll team up with Buffoon to laugh at Expert. Dilettante is just window dressing.

So what are the tactics by which this happens? What makes this so cathartic for engineers and programmers to watch? Well, there are a number of things occurring here.

Seizing on the only part of an explanation you understand

There’s nothing to level the playing field quite like ignoring most of what someone talking to you says and seizing on some minor point. This has two advantageous for purveyors of rhetorical fallacy. First and foremost, it lets you pivot the discussion in a way that you find favorable, but secondly, it implies that your opponent has babbled on and on and over-complicated the matter (ala Reagan countering Carter — folksy and relatable countering egg-head). Near the beginning, Expert gives a detailed explanation, avoiding saying that it would be impossible to draw red line with green ink by talking about color blindness. It’s a long-winded, but technically accurate way of saying “that’s pretty much impossible,” and all Buffoon takes away from it is “so, in principle this is possible.”

Talking down to the expert because you don’t understand

When Expert asks Buffoon to clarify what she’s talking about with “transparent ink,” she patronizingly says she thought that he’d know what “transparent” means and that he’d better know what “red” means if he’s an Expert. A little later, she doesn’t understand what perpendicular means and when Expert accidentally exposes that, she blames him for not understanding her nonsense. It’s a relatively standard approach to strike first in blaming the other for a miscommunication between two parties, but it’s especially vitriolic in a case where the party in the driver’s seat is covering inadequacy.

Begging the question (and perverting the role of experts)

I’ve encountered this myself, in my travels, and it’s certainly on display here. People assume (from ignorance) that a certain outcome is possible/feasible, and then seek out an expert to make it happen. When the expert explains that they’re misguided or trying to do something ill-advised or impossible, they adopt the stance, “I thought you were an expert, and you’re telling me you can’t do this?” Chamberlain does this throughout the clip.

Dunning Kruger

This mostly comes from Sociopath and somewhat for show, but this is the tendency of those unskilled in a subject to assume that the subject is pretty simple and to generally devalue the knowledge of experts in that field. As more knowledge is acquired, so is respect for experts and humility. Sociopath dresses Expert down, particularly at the point where he says, “look, we’re not asking you to draw 20 lines — just 7.” Buffoon also does this once when she draws a triangle as an example of three perpendicular lines (“move — let me do it!”) Being the only Expert here and thoroughly outgunned and unaware of the real agenda, Expert is absolutely buried in an amplified echo chamber of Dunning Kruger.

Expert Introverts

These players and these tactics are painfully relatable. People in our line of work look at this ruefully and laugh because someone finally gets it and understands how silly the players seem to them. But introversion, lack of interest in office politics, and professional integrity are what hamstring us in such situations. I mean think of it this way — you cringe because you’re right there along with Expert, wanting these idiots to understand that red pens don’t draw green lines. You want to speak rationally to them and use analogies, diagrams and metaphors to make them see your point.

What you don’t do is turn the Dunning Kruger around on them and start telling them that they’re really going to need pure red lines if they want to maximize their verticals and strategize their synergies. You don’t tell them that kitten lines were so 2011. You don’t interrupt Chamberlain when he says “any fool can criticize” to say that you’re okay with the clients’ criticism and how he dare he call them fools. You don’t ask Chamberlain, if his title is “project manager,” why can’t he “manage” to define a clear spec.

You don’t do any of these things. Neither do I. Neither did Expert. Instead, we all do what he did in the end, which is to say, “sure, whatever buddy, I give up.” Extroverts extemporize and thrive in situations like this fueled with BS and beyond their control (though, Sociopath, who is controlling it, may be an introvert). We find ourselves at a loss for words, and utterly demoralized. Our credentials, our competence, and the validity of our very profession called into question, we bleakly resign ourselves to the madness and go home for a beer. We do that for a while, at least, and then, eventually, we Quit with a capital Q.

Perhaps that’s why I didn’t find myself laughing while watching this. Poor Anderson, the Expert, isn’t having an experience that he’ll submit to the Daily WTF and move on — he’s figuring out that his professional life is miserable. And the reason it’s miserable is because he’s realizing that expertise, ideas and results aren’t really the backbone of good business; in the land of the extroverts, egos and social capital are king.

Mar
27

By

The Craftsmen Have it Right: Defining Software Quackery

Category: The Life of a Programmer | 11 Comments

I’ve fallen a bit behind on listening to some of my go-to programming podcasts of late (I will explain why shortly), but some of my friends were talking at dinner last week about a recent episode of .NET Rocks, featuring Alan Stevens. It presented the question, “Are you a craftsman?” and adopted a contrarian, or self-described “Devil’s Advocate” take on the movement. As far as episodes of that podcast go, this one was sort of guaranteed to be a lightning rod and the volume of comments seemed to bear that out, with Bob Martin himself weighing in on the subject.

I listened to this episode a week ago or so, and I’m not staring at the transcript, but here are some of the points I remember Alan making:

  • The craftsmanship movement in some places has turned into a monoculture — a way for the in-crowd to congratulate itself for getting it.
  • The wholesale comparison to guild culture and artisans is generally pretentious.
  • The movement should be inclusive and about building people up, rather than disparaging people.
  • There are lots of people out there not doing the “craftsmanship stuff” and still shipping working code, so who are we to judge?
  • Comparing software development to high-end, artistic craftsmanship, such as that of 30K guitars, devalues the latter**

(**I’ll just mention briefly that I consider this point to be absurd since this is shifting the goalposts completely from the “craft guild” comparison upon which the name is based — medieval craft guilds were responsible for making walls, shoes, and candles — not guitars for billionaire rock stars)

The comments for this episode contain a fair amount of disappointment and outright anger, but neither of those things was what I felt while listening, personally. Stevens is fairly engaging, and he had a number of pithy quotes from industry titans and authors at his disposal, citing, if memory serves, “The Pragmatic Programmer” and “The Mythical Man Month” as well as being fairly facile with the “Software Craftsmanship Manifesto.” This is clearly a well-read and knowledgeable industry professional as well as a practiced speaker, and he said a lot of things that I found reasonable, taken individually. But I couldn’t shake a vague sense of the surreal, like the dream sequences in the movie in Inception where Dali-like non-physics lurks at the periphery of your vision. It all seemed to make sense at first blush, but it was all wrong somehow.

I figured it out, and I’ll address that with a series of vignette sections here and hopefully tie them together somewhere this side of intolerable rambling.

On Quackery

One of the reasons I’ve been a bit negligent on my developer podcast listening is that I’ve become absolutely mesmerized by a podcast called “Quack Cast“, in which an infectious diseases doctor addresses alternative medicines. This man is ruthlessly empirical and relentlessly rational and even though the subject matter has virutally no overlap with anything I do, I find it fascinating. He provides ongoing rebuttal to all sorts of news about and advocacy for what he calls “SCAM” (supplements, complements, & alternative medicine), hoping to shine a light on how magic-based many of these approaches are.

Now, it isn’t my aim here to get into some kind of quasi-political fracas about whether prayer helps with surgery or whether aromatherapy cures cancer or whatever — if you have your beliefs, be welcome to them. But I will briefly describe one thing that’s so absolutely bat%&$# nuts that I don’t think it’s controversial for me to call it that: homeopathy. Now, if you’re like I was before hearing the podcast and then doing my own research, you probably don’t know exactly what homeopathy is. You probably think that it’s “home remedies” or “holistic treatment” or something else vague. It’s not. It’s much, much more ridiculous. It’s about 150 stops further down the crazy-train, firmly in the city of Quacksville.

You can read more here, but it’s a ‘theory’ of illness and cure that originated prior to the discovery of germs and the development of germ theory. Since that time, it has persisted largely and remarkably unchanged. The basic axioms are that “like cures like” and “the more you dilute something, the stronger it becomes.” So, for example, if you’re an end-stage alcoholic suffering from cirrhosis of the liver, the best medicine is tequila, but only if you cut it with water so many times that there’s no tequila left in your tequila. So, two wrongs (and one utter violation of the laws of physics as we know them) make not a right, but a nothing (i.e. giving water to someone with cirrhosis). And the fact that homeopathy is predicated upon diluting any actual effects out of existence is probably the reason it’s persisted while other historical, magical nonsense like alchemy, bloodletting, lobotomies, and exorcisms have gone extinct — homeopathy is relatively harmless because it’s all placebo, all the time (unless a practitioner makes a mistake and creates a nostrum that actually has some effect, which would be a problem). At the time this was proposed, it was as reasonable as any other contemporary approach to medicine, but in this day and age, it’s utter quackery.

Let’s come back to this later.

I’m OK, You’re OK

In software development, we start out as babes in the woods with an “I’m not OK, you’re OK” mentality. Everyone else knows what they’re doing and we’re lost. This is not healthy — we should be nurtured and not judged until we feel that we’re OK. Likewise, what separates good mentors from Expert Beginners is the adoption of an “I’m OK, you’re OK” attitude versus an “I’m OK, you’re not OK.” The latter is also not good. I write code and I’m OK. You write code and you’re OK. Maybe you’re more experienced than me, or maybe I’m more experienced than you. Either way, that’s OK. I’m OK and you’re OK.

At the end of the day, we’re all writing code that works, or at least trying to. And that’s OK. It’s OK if it doesn’t always work. We’re all trying. Maybe I test my code before checking it in. I’m OK. Maybe I at least compile it. And that’s OK. Maybe you don’t. And that’s OK. You’re OK. I’m OK and you’re OK. As long as we’re all trying, or, if not always trying, at least showing up, we’re all OK. There’s no sense casting aspersions or being critical.

This is the mature, healthy way to regard one another in the industry. Isn’t it? As long as we show up to work for the most part and sometimes write stuff that does stuff, who is anyone to judge? We’re all OK, and that’s OK.

Can Anyone Recommend an Apothecary?

If I’ve learned anything from reading all of the Game of Thrones books, it’s that the Middle Ages were awesome. Dragons and Whitewalkers and all that stuff. But what gets less play in those history textbooks is the rise of the merchant class during that time period. This is due in large part to the emergence of merchant and craft guilds. Craft guilds, specifically, were a fascinating and novel construct that greased the skids for the increased specialization of labor that would later explode in the Industrial Revolution (I think that happens in book 6 of Game of Thrones, but we’ll see when it comes out).

Craft guilds became professional homes for artisans of the time: stonemasons, cobblers, candle makers, bakers, and apothecaries — who knows, perhaps even homeopaths, though they would probably have been drawn and quartered for their suggested treatment of social diseases. The guilds had an arrangement with the towns in which they were situated. The only people in town that could practice the craft were guild members. In exchange, a basic level of quality was guaranteed. You could think of this as a largely benevolent cartel, though I kind of prefer to think of it as a labor union, but with more dragons.

Members of the guild entered as apprentices, where they learned at the feet of masters (and their family generally paid for this education). After completing a long apprenticeship, the aspiring guild member was allowed to practice the craft, for a wage as a journeyman, working with (for) other masters to ensure that knowledge cross-pollination occurred. With enough savings and proof of his “mastery” (which I think may be the origin of the word “masterpiece”) the journeyman could become a master and open his open business. The guild policed its own ranks for minimum quality, forcing its members to redo, pro bono, anything that they produced not up to snuff. The guild also acted as a unit against anyone selling knock-offs out of a trench-coat on the street corner. (The DVD makers’ guild was known in particular for this.) The self-policing guild offered a minimum standard for quality to the townsfolk and, in return, it was the only gig in town.

In practice, this meant a stamping out of impostors, charlatans, cheaters, and cranks. It meant that standards existed and that the general populace could depend, to some degree, on a predictable exchange of value. It also meant that there were accepted tools of the trade, processes and hoops through which to jump, internal political games to be played, and a decent amount of monoculture. And, it probably meant that the world progressed at the pace set by high achievers, if not geniuses. After all, the market economy had not yet been invented to reward wunderkinds, the outsized influencers, the lucky, and the radical innovators. Improvement happened, to be sure, but it happened at a pace approved by a council of masters that were ultimately men and men with egos.

So, this is probably the perfect metaphor for software development. Right? It seems like it’d be good to strive for a minimum level of quality — a set of standards, if you will. It seems like it’d be good if there was some kind of accreditation process, perhaps more accurate than a CS degree and less myopic than a certification, to demonstrate that someone was competent at software development. It seems like it’d be good for aspiring/new software developers to have a lot of one-on-one learning time with experienced developers that were really good at what they were doing. It seems like it’d be good for those initiates then to travel around some, broadening their experience and spreading their ideas. But, wait a second… we live in a very non-insular world, work in a global market economy, and, libertarians that we are, we’d sooner die than unionize. And writing software isn’t “craftsmanship,” the way that making candles, pies or shoes is.

Crap! We were doing so well there for a while, and there’s nothing more irritating than having to throw out your babies every time they dirty up their bath water. This seems to happen with all of my metaphors if I dissect them enough.

Software Quackery

Like medicine, artisanship, and even later 20th century pop psychology, software development has sort of lurched and hiccuped along in its (relatively short) history. Things that were widely done in the past have fallen out of favor. And, while a lot of our industry practices tend to be somewhat cyclical (preference for thin versus thick clients, for instance) some ideas do stick around. We make progress. We can stand, to some degree, on the shoulders of those who came before us and say that code at the GOTO level of abstraction does not scale and that shortening feedback loops and catching mistakes early are examples of preferable practices to their alternatives. We learn from our mistakes as individuals and as a collective. The bar inches higher. Or sometimes it stays stubbornly stagnant for a while and then makes a jump, the way that the field of medicine did with practices like hand-washing prior to surgery (except for homoepathic surgery to remove gangrenous limbs, in which case hand-washing is a strict no-no).

Movements emerge in fields, and they don’t emerge in a vacuum. They emerge in contrast to a prevailing trend or following a new, avant-garde idea. They are born out of words like “never again” as veterans of some practice look over the scars it has inflicted upon them. They become zeitgeists of the period before later being described as historic, or perhaps even quaint. In our field, I can think of some obvious examples. The Agile Manifesto and its subsequent movement springs to mind. As do the Software Craftsmanship, well, manifesto, and movement. Those are biggies, but there are plenty of others (everything on the desktop, no, wait, let’s move it to the browser, no, wait, let’s put it on people’s phones!)

So wherefore art thou, Software Craftsmanship? Well, I might suggest that Software Craftsmanship movement exists not in a vacuum and not to make those participating feel good about themselves after endless conferences, talks, and meetups filled with navel gazing. It’s not about condescension or creating “one true way.” It’s not about claiming that software is some kind of rarefied art form, nor is it about aesthetics or the “perfect code.” It’s not about saying that there’s one true MV* pattern to rule them all or that your unit tests need exactly one assert statement. Rather, at its core, I believe Software Craftsmanship is a simple refusal to tolerate Software Quackery any longer.

Once upon a time, back when PHP was new, we, as an industry, edited code on production servers, just as the founder of homeopathy thought that eating bark would cure malaria back in 18th century. However, a lot of time, study, experimentation and experience later, we came to the conclusion, as an industry, that hand editing code in production is a bad idea, just as medical science later came to understand why malaria occurred and how to prevent it. So now, it’s not pretentious nor is it beyond the pale for us, as an industry, to look upon software consultants editing code in production as quacks, anymore than it is to look upon medical practitioners handing out bark-water cocktails to treat malaria as quacks. We’re OK but you’re not OK if you’re doing that, and it’s OK for us to point out that you’re not OK.

It’s tempting to adopt a live and let live mentality and to be contrarian and say, “hey, we’re all trying to fight the disease, amirite, so let’s not be high and mighty,” but the fact of the matter is that treating malaria with bark and water is grossly negligent in this day and age, and it’s quackery of the highest order. So the Software Craftsmanship movement takes a page from the craft guilds of yore, and says, “you know, we should establish some minimum collective standards of competence, have some notion of internal quality policing, encourage aspiring members to learn at the hands of proven veterans, and develop the ability to say, ‘I’m sorry, but that’s just not good enough anymore.'” Yes, fine, if you ride the metaphor hard enough, it breaks down, but that’s really not the point. The point is that the movement is attempting to raise the bar from a world of barbaric medicine via unguents, spells, dances, and hitting people with rocks, to a world of medicine via the scientific method.

Back to the Podcast

As I mentioned earlier, I felt neither angry nor disappointed listening to Alan Stevens. I liked the conversation and at least parts of what he said. I picked up a few interesting quotes from authors and thinkers that I hadn’t hear previously, and his tone was relatively humble and disarmingly self-deprecating. And there was certainly a kind of populist, “don’t look down on the dark matter developers” vibe. So what was responsible for my surreal feeling? What was ‘wrong’ that I figured out? I could sum it up in a simple phrase, when it hit me: it felt like Stevens was pandering to what he thought was a low-brow audience.

What I mean is, here was a man, clearly knowledgeable about the industry, armed with impressive quotes and enough cachet to be asked to appear on .NET rocks, telling the listening population a very odd thing. Sure, he has a highfalutin Harvard doctorate like all those other doctors, but unlike them, he’s here to tell you that you don’t need any kind of fancy degree or medicine or machine to treat your own “carcinoma” or, as real people say, butt cancer — all you need is your own know-how, some kleenex, and a bucket of water. Or, in software terms, it’s okay if you ship crap, so long as you have a good attitude. I mean, we can’t all be expected to do a good job, can we? He even came out and said (paraprhased, though I remember the message very clearly) something along the lines of “sometimes mediocrity is good.” So, forget all of these fancy best practices and be proud of yourself if that 80,000 line classic ASP file you hand-edit in production manages not to kill anyone.

The underlying message of the show wasn’t any substantive indictment of the Software Craftsmanship movement, but an endorsement of Software Quackery. I mean, sure, there are good practices and bad practices, but let’s not get all high and mighty just because some doctors don’t wash their hands before operating on you — I mean, you’d rather have all of the colors of the competence rainbow than some surgeon hand-washing monoculture, right? The reference to Dreyfus really brought it full-weird-circle for me, though, because championing Software Quackery is generally the province of Expert Beginners — not Experts. So, I’m sorry, but I just don’t buy it. We can and should have some kind of minimum standard that isn’t a goody bag for just showing up. Please, join me in a polite refusal to tolerate Software Quackery — it just doesn’t cut it anymore.

Mar
21

By

Meetings and Introverts: Strangers in Strange Lands

Category: The Life of a Programmer Tags: | 8 Comments

I’ll admit as I type the first sentence of this post that I don’t know whether this will conclude a two-part “mini-series” or whether I’ll feel compelled to write further posts. But I wanted to write the follow up that I hinted at to the post I wrote about introversion for programmers (well, specifically me). Tl;dr refresher of that post is that social situations are exhausting for me because of their inherent unpredictability as compared to something like the feedback loop of a program that I’m writing (or even the easily curated, asynchronous interaction of a social media vehicle like Twitter). The subjects I left for this post were “Erik as a problem solver and pattern matcher,” consensus meetings, and two exceptional social situations that I don’t find tiring. The challenge will be spinning these things into a coherent narrative, but I’ll take a crack at it.

Whenever I look in my Outlook calendar and see something like “Meeting to Discuss Issue Escalation Strategy,” I am struck with a surprisingly profound feeling that life is filled with senseless waste, the way one might look in dismay at his sunglasses floating down a river he accidentally dropped them into. I see an hour or two of my life drifting away with no immediately obvious reclamation strategy. My hypothesis is that this is the sort of standard introvert take on what I’ll call “consensus meetings” rather than what many programmers seem to think of as a programmer take on them. As Paul Graham points out in one of my all time favorite posts, “when you’re operating on [a programmer’s] schedule, meetings are a disaster.” But I’m not really a maker these days anymore; for the time being, I’m a manager. And I still find these meetings to be a disaster.

Extroverts draw energy from social situations and become invigorated, while introverts spend energy and become exhausted. And, when I’m talking about social situations, I mean drinks and bowling with a group of friends. Introverts like me enjoy these nights but find them tiring. Now, apply this same sort of thinking to adversarial situations that are veritable clinics in bike-shedding. A bunch of introverts and extroverts gather together and set about deciding what the organizational flow chart of issue escalation should look like. Should it start at Tier 1 support and be escalated to the manager of that group, then over to internal operations and on up to Bill in DevOps? Or should it go through Susan in Accounting because she used to work in DevOps and and really has her finger on the pulse? Maybe we do that for 2 months and then go to Bill because that’s not really sustainable in the long term, but it’s good for now. And, we should probably have everyone send out a quick email any time it affects the Initrode account. And… ugh, I can’t type anymore.

So here sit a bunch of extroverts and me. The extroverts love this. People in general love having opinions and telling people their opinions. (I’m not above this — you’ve been reading my rants here for years, so there’s clearly no high ground for me to claim.) But it’s the extroverts that draw energy from this exchange and work themselves into a lather to leave their marks on the eventual end-product via this back and forth. The more this conversation draws on, the more they want to interject with their opinions, wisdom and knowledge. The more trivial and detailed the discussion becomes, the more they get their adrenaline up and enjoy the thrill of the hunt.

I on the other hand, check out almost immediately. From an organizational realpolitik perspective, these meetings are typically full of sound and fury, signifying nothing. The initial meeting organizer turns on the firehose and then quickly loses control of it as the entire affair devolves into a cartoonish torrent of ideas being sprayed around the room as the hose snakes, thrashes, and contorts with no guiding hand. Nobody is really capturing all of this, so the extroverts leave the meeting flush with the satisfaction of shouting their opinions at each other, but most likely having neglected to agree on anything. But, my inclination to check out goes deeper than the fact that nothing is particularly likely to be accomplished; it’s that neither the forum, nor the ideas and the opinions are interesting or important to me.

scan0003

I earnestly apologize if this sounds arrogant or stand-offish, but it’s the honest truth. And this is where the part about me being an introverted problem solver and pattern-matcher comes in. The meeting I want to have is one where I come prepared with statistical analysis and data about the most efficient flows of information in triage scenarios. I want performance records and response times for Bill and Susan, including in her former role in the case of the latter. I want to have synthesized that data looking for patterns that coincide with issue types and resolution rates, and I want to make a recommendation on the basis of all of that. To me, those are table stakes to the meeting. Whoever has the best such analysis should clearly have his or her plan implemented.

But that’s not what happens in extrovert meetings. As soon as the meeting organizer loses control of the firehose, we’ve entered the realm of utter unpredictability. I start to present my case study and the patterns I’ve noticed, and then someone interrupts to ask if I captured that data using the new or old ticketing system. And, by the way, what power point template am I using because it’s really snazzy. And, anyway, the thing about Susan is that she’s really not as much of a people person, but Doug kind of is. Now the extroverts are firmly in command. All prior analysis goes out the window, and, as people start jabbering over one another reasoned analysis and facts are quite irrevocably replaced with opinions, speculation, gossip, and non sequitur in general. The conversation floats gently down stream and washes up on a distant shore when everyone decides that it’s time for lunch. All of the analysis… unconsidered and largely ignored.

And that, the extroverts taking over and leaving me to space out, is the best case scenario. In the worst case scenario, they start peppering me with a series of off-topic, gotcha questions to which I have to reply, “I don’t know off the top of my head, but I can look into it later.” This puts me at a huge disadvantage because extroverts, buoyed by the rush of the occasion, have no qualms about guessing, fudging, hand-waving, or otherwise manufacturing ‘analysis’ out of thin air. When things take this kind of turn, and someone else “wins the meeting,” it’s even more exhausting.

Regardless of which kind of meeting it is though, the result is usually the same. After lunch and everyone has a chance to forget the particulars of the discussion, it becomes time to email the real decision maker or chat one on one with that person, and re-present the analysis for consideration. Usually at that time, the analysis wins the day or at least heavily informs the decision. The meeting robbed me of an hour of my life to accomplish nothing, as I knew it would, when I looked sadly at my Outlook calendar that morning.

There are two kinds of meeting that have no chance to fit this pattern, however (I’m omitting from consideration meetings that are actually policed reasonably by a moderator to keep things on-agenda, since these are far more rare than they should be). These are meetings where I’m passively listening to a single presenter, or actively presenting to the group. It’s not especially interesting that I’d find the former kind of meeting not to be exhausting since it’s somewhat akin to watching a movie, but the latter is, apparently, somewhat interesting. Presenting is not exhausting to me the way that a night out at a party is exhausting. There are sometimes pre-speech/talk jitters depending on the venue, but the talk is entirely predictable to me. I control exactly what’s going to be said and shown, and the speed at which I’ll progress. There is a mild element of unpredictability during the Q&A, but as the MC for the talk, you’re usually pretty well in control of that, too. So, that is the reason I find typical corporate meetings more exhausting than presenting in front of groups.

A strange thing, that. But I think in this light it’s somewhat understandable. Having reasoned analysis, cogent arguments, and a plan is the way to bring as much predictability (and, in my opinion, potential for being productive) to the table as possible. For me, it’s also the way most likely to keep the day’s meetings from sucking the life and productivity right out of you.

[thrive_leads id=’7177′]

Mar
14

By

Get Fed Up Every Now and Then

Category: The Life of a Programmer Tags: , | 7 Comments

In SQL Server management studio, all of objects in the database are listed in the object explorer in the format [schema].[object]. In large databases of the legacy variety, it’s not uncommon to find that the only schema for application tables/views/sprocs is dbo. In this case, navigating to the object you want requires the infuriating step of typing “dbo.” before the table name. This may not seem like a big deal, but you have to type fast for that style of navigation, and typing that period, far from home row, creates a problem. This has annoyed me for years, but today, I’d had enough.

With a few minutes of googling, I found this Q&A exchange. Clearly others feel the same way and while I don’t consider that to be ideal, it’s certainly an improvement over what I was doing. I can hit “F7” on a folder and bring up an “object explorer” window that lets me search by object name alone because it separates schema as a different column. Win. Sort of.

I have been using SQL Server Management Studio for nearly a decade and I never knew this. But, after a few minutes with google, now I know. Sometimes it’s google, sometimes it’s a tweet, sometimes it’s asking a coworker. But, the common thread is that one day I just say “enough” and decide to do something about it. It might not be a total solution, but I decide right then and there that the situation and my life need to be improved somehow, immediately.

I think this is a pretty valuable activity. Obviously, you pick up new tips and tricks this way, but more subtly, you’re embracing a philosophy that your routines and habits can always be improved and you’re mentally setting an expiration date on mindless, sub-optimal, or obtuse activities. In a way, this is fairly agile (using lower case a in a nod to the recent blogosphere brouhaha over “taking back agile” — I just mean it’s predicated upon the idea of iterative, steady progress). You’re not paralyzing yourself by analysis to figure out the best way to do things up front all of the time, but rather leaving yourself open to the possibility (certainty) that you can improve the way you do things.

ThisEndsNow

So pick something. Today. Pick something that’s a minor irritant that you’ve simply put up with for a long time and say to yourself, “This. Ends. Now.” in a dramatic, action hero voice. Spend a few minutes doing research and I’d imagine you’re going to be happy. I’ve personally never regretted anything about this time investment except for the regret that I didn’t allow myself to get fed up sooner. So, go ahead. You don’t have to take it anymore.

« Older Posts
Newer Posts »