DaedTech

Stories about Software

Apr
5

By

The Cost of Being Right

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

I stopped in the gas station today to pick up a few sodas and iced teas.  It was a time-poor man’s grocery run here in Lousiana, where it was in the 80s today.  This expedition left me with a plastic bag full of sweating drinks, a soggy receipt, and a lesson about the cost of being right.

First off, let me just say that I was and am right.  About what you ask?  About the fate of my receipt.

The receipt wound up in the bag with the sweating sodas, where it became sodden.  This wouldn’t have happened if the clerk had done the right thing and handed me the receipt, or even the slightly less wrong thing and asked me whether I wanted the receipt in the bag or not.  Instead, she did the wrong thing, and stuffed it into the bag where it became waterlogged.  “Receipt’s in the bag!” she informed me cheerfully.  Ugh.

Here’s the problem.  I take all of my credit card receipts, fold them, and put them in my wallet.  When I get home, I record the credit card transaction in Quicken so that when I download actual transactions from the financial institution in question, I can compare and make sure there are no spurious charges.  This scheme requires a dry, legible receipt.

Now, I know what you’re thinking — this is a matter of personal preference.  I prefer being handed my receipt whereas you prefer to have it in the bag.  That’s an understandable sentiment, but I assure you that it’s wrong.  I have empirical thinking on my side.  If the clerk hands me the receipt and I want it in the bag, it takes me less than a second to stuff it in there.  If the clerk stuffs it in the bag and I want it in my hand, I have to hold up the line while I go rooting around in the bag, looking for it, only to find it plastered between two Diet Mountain Dews.  So, as you can now see, I’m right.

SoakedReceipt

By the way, I’m willing to keep up this line of argument until you get exhausted and concede that I’m right.

You might, then, think that I explained the error of her ways to the clerk.  Or not, if you know me well at all.  I didn’t.  I thanked her, smiled, and left the store.  Once home, I extracted my soggy receipt, did my best to make out the figures on it, and entered them into quicken.

You see, it’s not that I’m any less convinced receipt-handing is optimal (though I could be persuaded).  It’s just that being right about this isn’t important.  It’s not important enough to me to think any further on (after adding a note to use this as a blog post intro), and it’s certainly not important enough for me to comment on to the clerk or anyone else in my life.

Read More

Apr
3

By

Software Rewrite: The Chase

Category: The Life of a Programmer Tags: , | 1 Comment

Editorial note: I’ve been on the road for the last week with a pretty hectic schedule — a mix of business and personal.  Luckily, I have a lot of cross posts stored that were fairly popular.  I originally wrote this one for the NDepend blog.  Go check out the original and stick around to look at other posts while you’re there.

Last week, a post I wrote, “The Myth of the Software Rewrite,” became pretty popular.  This generated a lot of comments and discussion, so I decided just to write a follow-up post to address the discussion, as opposed to typing a blog post’s worth of thoughts, distributed over 20 or 30 comments.  This is that post.

No Misconceptions

First of all, I want to be clear about what I’m talking about.  I’m talking specifically about a situation where the prime, determining factor in whether or not to rewrite the software is that the development group has made a mess and is clamoring to rewrite it.  In essence, they’re declaring bankruptcy — “we’re in over our heads and need outside assistance to wipe the slate clean so we can have a fresh start.”  They’re telling the business and their stakeholders that the only path to joy is letting them start over.

Here are some situations that the article was not meant to address:

  • The business decides it wants a rewrite (which makes me skeptical, but I’m not addressing business decisions).
  • Piecemeal rewrite, a chunk at a time (because this is, in fact, what I would advocate).
  • A rewrite because the original made design assumptions that have become completely obsolete (e.g. designed around disk space being extremely expensive).
  • Rewriting the software to significantly expand or alter the offering (e.g. “we need to move from web to mobile devices and offer some new features, so let’s start fresh.”)

A Lesson From Joseph Heller

Joseph Heller is the author of one of my all time favorite works of fiction, Catch 22.  Even if you’ve never read this book, you’re probably familiar with the term from conversational reference.  A catch 22 is a paradoxical, no-win situation.  Consider an example from the book.

John Yossarian, the ‘protagonist,’ is an anti-heroic bombardier in World War II.  Among other character foibles, one is an intense desire not to participate in the war by flying missions.  He’d prefer to stay on the ground, where it’s safe.  To advance this interest, he attempts to convince an army doctor that he’s insane and thus not able to fly missions.  The army doctor responds with the eponymous catch 22:  “anyone who wants to get out of combat duty isn’t really crazy.”

FigherJet

Read More

Mar
31

By

It’s Okay Not To Lead

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

I originally wrote this post for the Infragistics blog.  You can check out the original here.  While you’re there. take a look at posts by all of the various authors.

When I first entered the workforce, I was in awe of the programmers around me.  I’d spent 4 years of college learning how to implement Alpha-Beta pruning and various flavors of sort(), while these guys had been building things that real people used in the real world for years, or even decades.  I imagine it was, on a much smaller and more cerebral scale, the way a college football player feels upon turning pro.

FootballPlayers

This didn’t last.  After a while, I viewed them less with reverence and more as simple peers from whom I could learn, given their comparable wealth of experience.  As the years passed, the scales began to balance as I acquired more and more experience.  I was no longer the greenest developer around, and there was a healthy mix of people more and less experienced than I was.

The Path to Leadership

As this transformation took place, I started to develop opinions and preferences of my own, based on experience and on becoming a student of the craft.  I began to read books by people like Uncle Bob Martin and Michael Feathers.  And, sometimes, these opinions I was developing didn’t line up with those of some of the people around me.  I started to notice that the practices advocated by industry thought leaders were dismissed or ignored by some of the people around me.

At the same time, I began to notice that the people making technical decisions from positions with names like, “Architect,” “Principal Software Engineer,” and “Team Lead,” weren’t necessarily the best, technically.  Often, these leadership roles seemed to be as much a function of number of years with the company and familiarity with the domain as they were a function of technical acumen.  And where the developers more experienced than me seemed diverse in their skill, philosophy and approach, the decision-makers seemed disproportionately to value a “crank out reams of code” approach.  And, of course, when you have differences of opinion with the decision-makers, it doesn’t tend to go your way.

Read More

Mar
4

By

Value Theater and Pencil Sharpeners

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

I had some grand plans this week to do a Chess TDD post and a reader question post, but I wound up agreeing to do a quick contract gig that was very time sensitive, so I’ve been coding furiously all week, logging 50 billable hours in 4 days and still going strong.  That’s why, instead of any of my best laid plans, I offered cross posts.  Ah well, it turns out the cross posts tend to be quite popular, so I suppose everyone wins.

Given that I’m tired from all of this work and just kind of freewheeling a bit here, I’ll just type extemporaneously (or as close to that as you can manage with typing).  It’s been a while since I just typed what was on my mind in a stream without structure, so this is kind of fun.  This is a topic that’s bubbled near the surface for some years, but never quite made it into a post.  I’d like to talk about what people do in professional situations with a high degree of ambiguity.  This comes up a lot, often during transitional situations for groups or organizations.

To be a little more concrete about it, let’s say that you’re part of a team that’s just delivered a multi-year project, and it’s time to figure out what’s next for you as a group.  There’s an idea that, while the C-levels figure out the next long-term play, your team will spend a few months “cleaning up” an internal, legacy app.  What “cleaning up” means is yet to be determined.

At this point, all you know is that you’re going to do stuff to this application.  This lack of specifics is the ambiguity to which I’m referring.

Dealing with Ambiguity

Watching how people react in a situation like this is interesting.  Sure, at some point, circumstance will squeeze specifics out of some reluctant manager and the team will have their marching orders, but until that happens, you can witness a small study in human psychology.

Some people will interpret this situation as either quasi-time off, or else as unplanned “20% time,” triggering a period of some degree of coasting.  They’ll bone up on general knowledge, work on a little project they’ve always thought the company could use, work on a side project of their own, or maybe even just spend all day on Facebook.  The common theme here is that they’re content to wait for more specifics before proceeding.

Other people will fill the ambiguity with virtuous specifics according to their own office ethos.  I think of this as “sharpening the pencils,” and it’s usually accompanied by a crisp, earnest, and slightly urgent, “alright. come on, guys, let’s all {sharpen the pencils}.”   For some people, this means filling in the void with comfortable structure.  “Let’s decide who is going to be the liaison, the project manager, etc.”  For others, it’s haggling over tools of the trade — “alright, well, I think we should use that new text editor and it might make sense to update this code base to node.”  For others, it may simply be “time to lean, time to clean” activities, like “we don’t know what we need to do, but it couldn’t hurt for us to get started adding comments to every method in this thing.”

I call this “sharpening the pencils” because in my mind, it can be crystallized to this image.  “Well, we don’t know exactly what’s coming, but it can’t hurt to greet it with pencils sharp, ready and willing to take notes and get started on whatever comes!”

FranticStudent

Getting it Right

In my opinion, one of these camps is decidedly the ‘right’ camp, and it’s the former.  No, I didn’t confuse directional words.  I think the non-pencil sharpening loafers are doing the right thing, both for themselves and for the business.  And it’s not because I find “let’s all sharpen pencils” enthusiasm to be hard to take (though that can be the case).  It’s a lot more pragmatic than that.

Read More

Mar
1

By

Selling Your Boss On That Shiny New Tool

Category: The Life of a Programmer Tags: , |

Editorial Note: this was a post originally written for the SmartBear blog.  You can read the original here, at their site.  Check out the other authors over there, too.

Have you ever attended a trade show or conference that left you feeling like the proverbial kid in a candy store?  You had delectable food, met really smart people, attended eye-opening talks, and took tons and tons of notes.  The only complaint you had, in fact, was that you were forced to choose between multiple awesome sessions that were happening at once.  You were practically glowing as you said your goodbyes and headed back to your normal job, prepared to dazzle your coworkers with all of the new techniques that you knew would be real difference makers.

But even if they didn’t necessarily buy into everything to the extent that you did, there was that one tool that was just such a no brainer that it would sell itself once you explained it. But it didn’t. There’s nothing quite like having your proposal flatly and unenthusiastically rejected to shock you out of the post-conference glow and throw you right back into the daily grind. You were so convinced that people would see the incredible benefits that you find the actual results inconceivable: your coworkers shrug indifferently and your manager says, “We’re doing fine right now, so we really don’t need to introduce anything new.”  Is this situation avoidable?

I wish I could tell you that I had a bulletproof pitch that would never be rejected. Persuasion skills like that would be nothing short of a super power.  But while there’s no guarantee that you’ll succeed in selling your manager on a tool, you can certainly improve your odds.  The way to do this is by making a business case for the tool.

ProjectManager

Read More

« Older Posts
Newer Posts »