DaedTech

Stories about Software

By

Musing on Agile’s Built In Caveat Emptor

First things first.  I’d like to thank the folks who submitted “Ask Erik” questions (I’m thinking I might need to come up with a title that’s not as lame — iterate all the things!)  I’m pleased with the results so far, and early returns on my hypothesis look good.  Interestingly, I received more than one question related to my take on capital-A Agile as a movement.  I plan on answering these questions directly, but I have opined on this subject a bit in the past:

Reading the questions I received and letting them kick around in my head a bit as I was jogging earlier today, I started to think obliquely about the topic and how it’s approached and regarded in the industry.  What’s going to follow is fairly raw riffing on this topic, and please forgive me if I seem a little loopy.  It’s about 1:30 AM, I just got back from a concert, and, given that I’ll be off the grid for a couple of weeks starting September 5th, I didn’t want to let a Friday lapse sans post.

1 Agilius

So, story time.  What would you think if I laid the following narrative on you?

17 well known, well respected elders from different villages came to realize that the prevailing methods for tending and cultivating crops were not sufficient to feed the growing populations of their villages.  These elders had some ideas, both mystical and practical, for how to solve that problem.  They’d gained much knowledge on their own and needed to spread the word.

They decided to convene a summit, but the odds were stacked against them.  Each village had its own ways of doing things and cultural preferences, and the elders were each accustomed to those around deferring to them.  Initially, they could not even agree on a location for the summit!  How were they ever going to agree on providing food for the known world?

Against all odds, however, they made progress.  They retreated into the mountains and toiled for 2 days and 2 nights, expecting little to come out of the gathering, but when the sun rose on the 3rd morning, not only had they made strides — they’d all agreed, as if by Divine Providence.  What emerged from this gathering were stone tablets containing the 4 Core Values and the 12 Principles of food cultivation.

Over the years, the Word spread far and wide.  What started as 17 quickly became dozens, and eventually hundreds, thousands, and hundreds of thousands.  Great centers of learning and cultural exchange emerged, devotees made annual pilgrimages to important sites, and the new methods for food cultivation spread far and wide.  And, lo, it was good.  There was much rejoicing.

In case this doesn’t ring a bell with you off the cuff, it’s basically the history of the Agile Manifesto.  And, before you bristle, read that history that I linked.  It says epistle in there to describe one of the communications between signatories, for goodness sake — if that doesn’t invite religious comparisons, I don’t know what does.  Try googling that word and finding a reference in the top 10 that doesn’t prominently mention the Bible.

Guru

This post isn’t actually about comparing capital-A Agile to religion.  This is well trod ground, and a well placed google search will let you tread it to your heart’s content.  But if you temporarily accept the premise as axiomatic, there’s an interesting plank to the agile canon that’s generally missing from religion, at least in my experience with it.  What I’m talking about is self-reference in a way that isn’t begging the question.   Read More

By

Ask Me Questions, Help Me Be a Scientist

If you visit my site and ever pay attention to the side gutter, you may have noticed this.

AskErik

 

I get a fair number of questions via various media: Twitter, Twitter DM, email, etc.  A lot of the answers to these questions wind up being blog posts or even series.  The Chess TDD series actually got started this way.

But something occurred to me recently.  I formed a hypothesis.  It’s probably only the most outgoing folks or those with whom I already have a relationship that will engage me in this way, meaning that a good chunk of the readership may want to ask questions but not have a comfortable venue for it.

As such, I’m drawing on the lessons of science classes growing up and running an experiment: I’m introducing this form.  It seems like a lower barrier entry way to submit a question, at least to me.  If I were reading a blog and wanted to ask the author a question, I might hesitate to email her since it’s not clear that she actually wants such questions.  But if she had a form on her blog saying, “ask me questions,” I wouldn’t feel any such reservations.

So, the experiment works if I wind up with more submissions to the form than I get email questions. Read More

By

Let’s Build a Metric 2: Getting the Units Right

This is a post originally written for the NDepend blog.  Go check it out there and see some other posts that are up as well.

Last time in this series, there was definitely some housekeeping to accomplish.  I laid the groundwork for the series by talking a bit of theory — what are code metrics and what is static analysis?  I also knocked out some more practical logistics such as taking you through how to get the code base I’m using as well as how to create and attach an NDepend project to it.  The culmination was the creation of our very own, tiny, and relatively useless code metric (useless since NDepend already provides the metric we ‘created’).

So, seems like a good next thing to do is make the metric useful, but there may be an interim step in there of at least making it original.  Let’s do that before we get to “useful.”  But even before that, I’m going to do a bit of housekeeping and tell you about the NDepend feature of managing the queries and rules in the Queries and Rules Explorer.

Group Housekeeping

Last time around, I created the “My Rules” group under “Samples of Custom rules.”  This was nice for illustrative purposes, but it’s not where I actually want it.  I want to bring it up on the same level as that, right after “Defining JustMyCode”.  To do that, you can simply drag it.  Dragging it will result in a black bar indicating where it will wind up:

Metrics2 (1)

Once I’ve finished, it’ll be parked where I want it, as shown below.  In the future, you can use this to move your groups around as you please.  It’s pretty intuitive. Read More

By

Don’t Be a Human Resource

It’s easy to wince when someone uses the term “resource” to describe a human being.  At least, it is until you’re desensitized to the word being thrown around in a business context.  After that, I think it’s a subtle form of signaling.  But I’ll get back to that in a minute.  Let’s do a thought exercise, first.

Imagine if one day you received a call from your friend who, after a bit of small talk, said, “I’ve been having something of a rough time since the breakup, but I think I’m turning a corner.”  Fair enough, but then things got weird.  “I’ve decided to get into the dating market to find a companionship resource.”  Wait, what?  “Yeah, and it’d obviously be great if they could also supply nice-to-haves like sex, dinners out, and small vacations, but I think companionship is a good starter offering.”  Holy crap, what?!

TooMuchConfidence

At that point, you’d probably be reconsidering the friendship and wondering when this person morphed into a sociopath.  Context is king, it would appear.

Read More

By

Let’s Build a Metric 1: What’s In a Metric?

I originally wrote this post for the NDepend blog where I’m doing a whole series on this.  Go check out all of the posts over there — we’re doing some cool stuff.

A while back, I made a post on my blog announcing the commencement of a series on building a better, composite code metric.  Well, it’s time to get started!

But before I dive in headfirst, I think it’s important to set the scene with some logistics and some supporting theory.  Logistically, let’s get specific about the techs and code that I’m going to be using in this series.  To follow along, get yourself a copy of NDepend v6, which you can download here.  You can try to follow along if you have an older version of the tool, but caveat emptor, as I’ll be using the latest bits.  Secondly, I’m going to use a codebase of mine as a guinea pig for this development.  This codebase is Chess TDD on github and it’s what I use for my Chess TDD series on my blog and Youtube.  This gives us a controlled codebase, but one that is both active and non-trivial.

What are Static Analysis and Code Metrics, Anyway?

Now, onto the supporting theory.  Before we can build meaningful code metrics, it’s important to understand what static analysis is and what code metrics are.  Static analysis comes in many shapes and sizes.  When you simply inspect your code and reason about what it will do, you are performing static analysis.  When you submit your code to a peer to have her review, she does the same thing.  

Like you and your peer, compilers perform static analysis on your code, though, obviously, they do so in an automated fashion.  They check the code for syntax errors or linking errors that would guarantee failures, and they will also provide warnings about potential problems such as unreachable code or assignment instead of evaluation.  Products also exist that will check your source code for certain characteristics and stylistic guideline conformance rather than worrying about what happens at runtime.  In managed languages, products exist that will analyze your compiled IL or byte code and check for certain characteristics.   The common thread here is that all of these examples of static analysis involve analyzing your code without actually executing it.

Read More