DaedTech

Stories about Software

By

Modern Software Development at Its Core

I spend a lot of time in hotels, so it’s pretty unremarkable that I would spend the first week of 2016 on the 6th floor of some Marriott.  I unpacked and put my things in their usual places.  I make coffee in the room’s coffee-maker the same way each morning.  And I hit the hotel gym each day for a 3-4 mile jog between end of business and going for dinner.  In terms of my routine, the first week in January is like every other week of the year that I’m on the road.

What’s not the same as every other week of the year is what awaits me when I arrive at the hotel gym.  In December, it’s a roomful of softly humming treadmills and a TV firing out staccato bursts of salacious, 24 hour news at a mercifully low volume — the exercise room equivalent of a ghost town.  This week, it’s full of newly New Years-resolved exercisers, armed with old walkmans, weird headbands, and pitted out T-shirts that, until this day, were reserved for painting the house.

A Pitched Battle with a Treadmill

One such man came in at the same time as me, and took the treadmill next to mine.  I punched in my workout settings and started out at my usual 6 miles per hour, while the man next to me fiddled with his treadmill for a few minutes.  Once he got started, he peered at me every few seconds, as if I were taking a midterm via treadmill and he wanted to copy my answers.  He worked himself up to a speed similar to mine, and everything seemed to be in rhythm for 2-3 minutes, until his breathing became extremely labored and ragged.

Naturally, at this point, rather than pausing the treadmill or slowing the speed, he lifted himself off of the belt like a gymnast performing on the parallel bars.  Once this became untenable, he set one foot down on either side of the belt, tottered awkwardly a bit, and then jumped off the treadmill.  I assumed he was done, wanting to live to fight another day, but a few minutes later, he returned with a towel and leapt back onto the treadmill, using his arms to resume his former pace.  Luckily for him, he did then figure out how to adjust his speed, allowing him to alternate between sprinting and walking until he decided he’d had enough.

TreadmillBattle

A lot of gym regulars, as I understand it, find New Years resolvers to be annoying.  I understand this sentiment if you take them as an entire group, seriously clogging up the gym for the first 3-4 weeks of the year.  But it’s hard to fault any individual for wanting to engage in some self improvement and overcoming inertia (and annoyed veterans) to get started.  In fact, it’s downright laudable.

Read More

By

Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More

By

Do Programmers Practice Computer Science?

I’ve gotten some questions about the idea of what we do being scientific or not, and that raises some interesting discussion points.  This is a “You Asked for It” post, and in this one, I’m just going to dive right into the reader question.  Don’t bury the lead, as it were.

Having attended many workshops on Agile from prominent players in the field, as well as working in teams attempting to use Agile I can’t help but think that there is nothing Scientific about it at all. Most lectures and books pander to pop psychology, and the tenants of Agile themselves are not backed up by any serious studies as far as I’m aware.

In my opinion we have a Software Engineering Methodology Racket. It’s all anecdotes and common sense, with almost no attention on studying outcomes and collecting evidence.

So my question is: Do you think there is a lack of evidence based software engineering and academic rigor in the industry? Do too many of us simply jump on the latest fad without really questioning the claims made by their creators?

I love this.  It’s refreshingly skeptical, and it captures a sentiment that I share and understand.  Also notice that this isn’t a person saying, “I’ve heard about this stuff from a distance, and it’s wrong,” but rather, “I’ve lived this stuff and I’m wondering if the emperor lacks clothes.”  I try to avoid criticizing things unless I’ve lived them, myself, and I tend to try something if my impulse is to criticize.

ScientificMethod

I’ll offer two short answers to the questions first.  Yes and yes.  There is certainly a lack of evidence-based methodology around what we do, and I attribute this largely to the fact that it’s really, really hard to gather and interpret the evidence.  And, in the absence of science, yes, we collectively tend to turn to tribal ritual.  It’s a God of the Gaps scenario; we haven’t yet figured out why it rains, so we dance and assume that it pleases a rain God. Read More

By

Prediction Markets for Software Estimates

The ongoing kerfuffle over the “No Estimates” movement is surreal to me.  So before I get to prediction markets for software estimates, I’ll discuss the surreal a bit. Instead of attempting to describe it, which, I can only imagine, would be meta-surreal, I’ll make use of an allegory of sorts.

No Wedding Estimates

Imagine that wedding planners have long struggled with an important issue.  For years and years, their clients have asked them to help pick a date on which it would not rain so that they could have outdoor weddings.  And, for years and years, their predictions have been spotty at best, resulting in irate clients, wet formal wear, and general heartburn.

In all that time, wedding planners have pored over weather patterns and diligently studied farmers’ almanacs.  And yet, the predictions did not substantially improve.  It got so bad that a group of upstart wedding planners met one year in the mountains and authored a document called “The Contingency Manifesto.”  This resulted in an important advance in wedding planning for outdoor weddings: reserving a backup plan not dependent on the weather.

RainyWedding

And yet, not all was fixed.  People still wanted outdoor weddings, and continued to be disappointed when it rained, contingency notwithstanding.  They still demanded wedding planners help them figure out months and months in advance whether or not it would rain on a particular day.  And, this is understandable after all — weddings are important.

Quite recently, a group of wedding planners emerged under the hashtag #NoOutdoorWeddings.  Their message was simple: “we can’t predict the weather, so have your wedding inside and stop whining.”  The message was, of course, music to the ears of frustrated wedding planners everywhere.  But some planners and most clients balked.  “How can you tell the clients not to have weddings outside?  They’re the ones paying, so it’s our obligation to facilitate their wishes!”

This schism, it seemed, was irreparable.  And surreal.

  • Why is it necessary for wedding planners all to agree?  Can’t the ones that don’t want to deal with weather contingency just not do it and the ones who want to can?
  • Why can’t people figure out that trying to predict a chaotic system like the weather is a fool’s errand?
  • Why would you ask a wedding planner to make a prediction that could easily be influenced by his own interest?
  • Frankly, if one person is dumb enough to ask another to predict the weather on a day 9 months from now, and the other person is dumb enough to do it, can’t we just agree that the two deserve each other and the inevitable lawsuit?

How Estimation Actually Works Today

Read More

By

Agile Methodologies or Agile Software?

Over the last couple of months, I’ve been doing mostly management-y things, so I haven’t had a lot of trade craft driven motivations to pick Pluralsight videos to watch while jogging. In other words, I’m not coming up to speed on any language, framework, or methodology, so I’m engaging in undirected learning and observation. (I’m also shamelessly scouring other authors’ courses for ways to make my own courses better). That led me to watch this course about Agile fundamentals.

As I was watching and jogging, I started thinking about Agile Manifesto and the 14 years that have passed since its conception. “Agile” is undeniably here to stay and probably approaching “industry standard.” It’s become so commonplace, in fact, that it is an industry unto itself, containing training courses, conferences, seminars, certifications — the works. And this cottage industry around “getting Agile” has sparked a good bit of consternation and, frequently, derision. We as an industry, critics might say, got so good at planning poker and daily standups that we forgot about the relatively minor detail of making software. Martin Fowler coined a term, “flaccid Scrum” to describe this phenomenon wherein a team follows all of the mechanics of some Agile methodology (presumably Scrum) to the letter and still produces crap.

It’s no mystery how something like this could happen. You’ve probably seen it. The most common culprit is some “Waterfall” shop that decides it wants to “get Agile.” So the solution is to go out and get the coaches, the certifiers, the process experts, and the whole crew to teach everyone how to do all of the ceremonies. A few weeks or months, some hands on training, some seminars, and now the place is Agile. But, what actually happens is that they just do the same basic thing they’d been doing, more or less, but with an artificially reduced cycle time. Instead of shipping software every other year with a painful integration period, they now ship software quarterly, with the same painful integration period. They’re just doing waterfall on a scale of an eighth of the previous size. But with daily standups and retrospectives.

There may be somewhat more nuance to it in places, but it’s a common theme, this focus on the process instead of the “practices.” In fact, it’s so common that I believe the Software Craftsmanship Manifesto and subsequent movement was mainly a rallying cry to say, “hey, remember that stuff in Agile about TDD and pair programming and whatnot…? Instead of figuring out how to dominate Scrum until you’re its master, let’s do that stuff.” So, the Agile movement is born and essentially says, “let’s adopt short feedback cycles and good development practices, and here are some frameworks for that” and what eventually results is the next generation of software process fetishism (following on the heels of the “Rational Unified Process” and “CMM”).

That all played through my head pretty quickly, and what I really started to contemplate was “why?” Why did this happen? It’s not as if the original signatories of the manifesto were focused on process at the exclusion of practices by a long shot. So how did we get to the point where the practices became a second class citizen? And then, the beginnings of a hypothesis occurred to me, and so exists this post.

The Agile Manifesto starts off with “We are uncovering better
ways
of developing software…” (emphasis mine). The frameworks for this type of development were and are referred to as “Agile Methodologies.” Subtly but very clearly, the thing we’re talking about here — Agile — is a process. Here were a bunch of guys who got together and said, “we’ve dumped a lot of the formalism and had good results and here’s how,” and, perversely, the only key phrase most of the industry heard was “here’s how.” So when the early adopted success became too impressive too ignore, the big boys with their big, IBM-ish processes brought in Agile Process People to say, “here’s a 600 page slide deck on exactly how to replace your formal, buttoned-up waterfall process with this new, somehow-eerily-similar, buttoned-up Agile process.” After all, companies that have historically tended to favor waterfall approaches tend to view software development as a mashup of building construction and assembly line pipelining, so their failure could only, possibly be caused by a poorly engineered process. They needed the software equivalent of an industrial engineer (a process coach) to come in and show them where to place the various machines and mindless drones in their employ responsible for the software. Clearly, the problem was doing design documents instead of writing story cards and putting Fibonacci numbers on them.

The Software Craftsmanship movement, I believe, stands as evidence to support what I’m saying here. It removes the emphasis altogether from process and places it, in very opinionated fashion, on the characteristics of the actual software: “not only working software, but also well-crafted software.” (emphasis theirs) I can’t speak exactly to what drove the creation of this document, but I suspect it was at least partially driven by the obsession with process instead of with actually writing software.

MolotovCocktail

All of this leads me to wonder about something very idly. What if the Agile Manifesto, instead of talking about “uncovering better ways,” had spoken to the idea of “let’s create agile software?” In other words, forget about the process of doing this altogether, and let’s simply focus on the properties of the software… namely, that it’s agile. What if it had established a definition that agile software is software that should be able to be deployed within, say, a day? It’s software that anyone on the team can change without fear. It’s software that’s so readable that new team members can understand it almost immediately. And so on.

I think there’s a deep appeal to this concept. After all, one of the most annoying things to me and probably to a lot of you is having someone tell me how to solve a problem instead of what their problem is, when asking for help. And, really, software development methodologies/processes are perhaps the ultimate example of this. Do a requirements phase first, then a design phase, then an implementation phase, etc. Or, these days, write what the users want on story cards, have a grooming session with the product owner, convene the team for planning poker, etc. In both cases, what the person giving the direction is really saying is, “hey, I want you to produce software that caters to my needs,” but instead of saying that and specifying those needs, they’re telling you exactly how to operate. What if they just said, “it should be possible to issue changes to the software with the press of a button, it needs to be easy for new team members to come on board, I need to be able to have new features implemented without major architectural upheaval, etc?” In other words, what if they said, “I need agile software, and you figure out how to do that?”

I can’t possibly criticize the message that came out of that meeting of the minds and gave birth to the Agile Manifesto. These were people that bucked entrenched industry trends, gained traction, and pulled it off with incredible success. They changed how we conceive of software development and clearly for the better. And it’s entirely possible that any different phrasing would have made the message either too radical or too banal for widespread adoption. But I can’t help but wonder… what if the call had been for agile software rather than agile methods.