DaedTech

Stories about Software

Jun
14

By

Three Martini Open Office Plans

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

A tweet came into my Twitter feed last night, and I noted that (1) I was a little late to the party and (2) it was wildly popular.  I found myself a bit surprised, because it was critical of the open plan office construct, which I figured was by now just an accepted condition of salaried employment, like status meetings or PTO limits.  Apparently, however, this is one particular management fad that has not met with universal approval.  The tweet (shown below), is trending toward 10K likes and retweets.

Personally, I love open plan offices.  Granted, I don’t actually work in one with any regularity, but I enjoy them immensely when I have occasion to park for a few hours at a client site.  It’s sort of like going to the gym, but without the sweating.  Actually, I’d say, it’s more like going to a bar (more on that later).

Three Martini Lunchers

I’m a type A introvert, and I work predominantly from home (or a hotel wherever I happen to be, since I travel a lot).  This means that it’s not uncommon for me to get swept up in my work and log 10+ hour stints of heavy concentration.  For instance, I recently wrote an E-Book for a client in 2 days.  It’s like I go into a sensory deprivation chamber and I get things done, delivering code, write-ups, posts, or whatever to clients on or ahead of schedule.

But following a productivity ‘binge’ like that, there are typically human connection things that have to happen.  I travel to a client site to present something in person or I get on a series of conference calls to collaborate.  It is in these situations that hyper-productivity ends and human connection begins in the meatspace.  Consulting requires more than just output — it requires relationship management.

More and more these days, when I pull that part of a tour of duty, it happens in an open plan office, simply because there are more and more open office plans.  Even clients that don’t have them now talk sheepishly about how they should.  For me, fresh off a week or two of minimal human interaction and intense productivity, I fly somewhere and meet with people for a couple of days, wherein the goal is mainly relationship forging.  In this capacity I’m greeted by someone who proudly demonstrates the egalitarian nature of the office space, and ushers me to a high top or to a focus room or whatever they’re calling it.

At this point, it’s as if I were in a college Starbucks that served a single company.  Some patrons are sitting alone, studying glowing screens, while others gather in impromptu circles, having animated discussions.  There’s the occasional jerk making lots of noise and distracting everyone and the occasional good-natured hijinks in the form or Nerf guns or whatever.  The result is a Dionysian experience to my Appolonian, introverted sensibilities.  I wouldn’t want to try to get serious, thought-intensive work done in such a place (if I needed to do that, I’d obviously leave), but it’s a nice way to obtain social camaraderie without much pressure.

Read More

May
5

By

A Manager’s Guide to Legacy Code

Category: Language Agnostic Tags: , | 2 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  Go check out the original here, at their site.  If you like posts about static analysis, code quality, and architecture, head on over and check it out.

If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it.  If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself.  After all, this is legacy software, and the reaction of the team is likely to be quite predictable.

Alright, let’s take a look at this thing.  Oh, man, look at that right there.  A global variable.  And — oh my god — there are dozens of these things.  Who even wrote this?  And, look at this over here.  That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current.  But even when it was current, this code was horrible.  This was obviously written by a trained ape.

When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago.  Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.

CodersBlock

But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bother developers precisely because it renders them less effective.  They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.

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
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 »