DaedTech

Stories about Software

By

How to Add Static Analysis to Your Process

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’e there, take a look at the other posts and download a trial of NDepend, if you’re so inclined.

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.

Lumbergh

If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

What is Static Analysis (Briefly)?

You can read up in great detail if you want, but I’ll summarize by saying that static analysis is analysis performed on a codebase without actually executing the resultant compiled or interpreted code.  Most commonly, this involves some kind of application (e.g. NDepend) that takes your source code files as input and produces interesting output by running various analyses on the code in question.

Let’s take a dead simple example.  Maybe I write a static analysis tool that simply looks through your code for the literal string “while(true)” and, if it finds it, dumps, “ruh-roh” to the console.  I’m probably not going to have investors banging down my door, but I have, technically, written a static analysis utility.

Read More

By

Solve Small Problems

Editorial Note: I originally wrote this post for the Infragistics blog.  Go check out the original at their site.  While you’re there, go check out their developer tools and controls.

It’s fun to think of great moments in the history of science, particularly the ones that have a memorable anecdote attached to them.  In the 3rd century BC, a naked Archimedes ran down a city street, screaming Eureka, because he had discovered, in a flash, how to measure the volume of irregular solids.  In the 1600s, a fateful apple bonks Issac Newton on the head, causing him to spit out the Theory of Gravity.  In the early 1900s, another physicist is sitting around, contemplating the universe, when out pops E=MC^2.

Newton Getting Bonked with an Apple

These stories all share two common threads: they’re extremely compelling and entirely apocryphal.  As such, they make for great Disney movies, but not such great documentaries.  Point being, we as humans like stories of “eureka moments” and lightning bolt inspiration much better than tales of preparation, steady work, and getting it right on attempt number 2,944, following 2,943 failed attempts.

But it goes beyond just appreciating the former type of story.  We actually manufacture them.  Perhaps the most famous sort of example was Steve Jobs’ legendarily coy, “oh yeah, there’s one more thing” that preceded the unveiling of some new product or service.  Jobs and Apple were masters of “rabbit from the hat” marketing where they’d reveal some product kept heretofore under wraps as though it were a state secret.  All that is done to create the magic of the grand reveal — the illusion that a solution to some problem just *poof* appeared out of thin air.

Unrealistic Expectations

With all of this cultural momentum behind the idea, it’s easy for us to internalize it.  It’s easy for us to look at these folk stories of scientific and product advancement and to assume that not having ideas or pieces of software fall from us, fully formed and intact, constitutes failure.  What’s wrong with us?  Why can’t we just write that endpoint in one shot, taking into account security, proper API design, backward compatibility, etc?  We’re professionals, right?  How can we be failing at this?

You might think that the worst outcome here is the ‘failure’ and the surrounding feelings of insecurity.  But I would argue that this isn’t the case at all.  Just as the popular stories of those historical scientists are not realistic, and just as Apple didn’t wave a magic wand and wink an iPod Nano into existence, no programmer thinks everything through, codes it up, and gets it all right and bulletproof from the beginning.  It simply doesn’t happen.

Read More

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