DaedTech

Stories about Software

Sep
2

By

Surviving Software Heroes

Category: You Asked For It Tags: , , | 7 Comments

There’s an entertainer named Garrison Keillor who talks about the fictional town of Lake Wobegon.  At the end of live monologues on this subject, he ‘signs off’ with the following summation.

Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average.

Heroes of Software

Most of our life is spent in search of a place where all of the children are above average — a place where we can all grow up to be heroes.  Society idolizes its ready-made heroes: royalty, athletes, celebrities, and even, to some lesser extent, great thinkers, executives, and artists.  There are also situational, role-based heroes, such as first responders or even people who perform some bit of heroism in a pinch, such as pulling a potential drowning victim from an icy lake.  The key here is specialness.  Heroes are special.

For the rest of us ordinary mortals that don’t knock in World Series clinching home runs or play home run hitters in movies, we’re left to manufacture our own specialness narratives.  Smartest lady in the room?  The guy with the legendary collection of beer steins from each year’s Oktoberfest?  Sometimes you have to dig pretty deep to find a venue in which you’re significantly above average.  It is to this need that I attribute hardcore conspiracy theorists and people who fret endlessly about organic food, holistic medicine and ‘ancient’ treatments — being in possession of some kind of uncommon knowledge that the ‘sheeple’ lack is a path to specialness, if not heroism, per se.

We have heroes in the software world.  They’re the ones with encyclopedic knowledge of the domain and the existing code base.  They’re the ones who are known for being reliable when the chips are down — getting in early, staying late, and coming through in the clutch with a put-upon, but satisfied expression.  They make project managers swoon and gush during their academy award speeches.  They come in late sometimes and leave early other times, when there isn’t delivery pressure, because they’re trusted with the special privileges that fall to A players on teams.  But they do it knowing that, at any moment, they might need to swoop in and take over entirely while the rest of the team twiddles their thumbs and gets out of the way.

SuperDev

And you know what?  They love it.  Because in the narrow scope defined by their cube farm, they are heroes.  They are Michael friggin’ Jordan.  They’ve found their specialness in life. Read More

Aug
30

By

Chess TDD 46: En Passant Expiration Date

Category: You Asked For It Tags: , , , , | 4 Comments

This installment of Chess TDD was another episode focused on en passant.  It’s been a while since I was in this code base.  I’d been on the road a lot and without my main development/recording rig.  But now I’m back and was able to take the opportunity to record a little Chess TDD ahead of my wedding next week.  This episode went pretty smoothly.  I cleaned up a method from last time that had become unwieldy and then got the next acceptance test to pass without any flailing.  Not bad for so much time between episodes!

What I accomplish in this clip:

  • Refactored the Board.MovePiece method away from mounting ickiness.
  • Implemented functionality to prevent en passant from lasting beyond one turn.

Here are some lessons to take away:

  • When extracting methods during a refactor, if you have a hard time giving the new method a coherent name, it might be a sign that you’ve selected non-cohesive functionality to extract.
  • Spend a few extra brain cycles contemplating the names that you give things.  This investment will pay off because it’s easier to give things good names when their functionality is fresh in your mind.
  • If you start to have code that no longer seems to belong in a class, make sure you’re keeping that visible to yourself as you go so that you can have a nice cue for refactoring.
  • Take care to keep communication between methods and classes at an appropriate level of abstraction.  Make sure they’re communicating in obvious domain concepts.

Aug
28

By

Musing on Agile’s Built In Caveat Emptor

Category: The Life of a Programmer Tags: , |

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

Aug
25

By

Ask Me Questions, Help Me Be a Scientist

Category: Announcements |

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

Aug
23

By

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

Category: .NET Tags: |

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

« Older Posts
Newer Posts »