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

Jun
12

By

Dealing with Legacy Code for Developers: Managing your Manager

Category: The Life of a Programmer Tags: , |

Editorial note: I originally wrote this post for the NDepend blog.  Click here to check out the original, on their site.  While you’re there, take a look around at the other posts and the offering.

Here’s a campfire horror story of legacy code that probably sounds at least somewhat familiar.

One day, your manager strolls by casually, sipping a cup of coffee, and drops a grenade in your lap.  “Do you think we can add an extra field to the customer information form?”  Sure, it may sound innocuous to an outsider, but you know better.

The customer information form is supported by something written almost a decade ago, by a developer long departed.  Getting that data out of the database and onto the form prominently features a 60,000 line class called DataRepositoryManagerHelper and it also makes use of a gigantic XML file with odd spacing and no schema.  Trying to add a field to that form casts you as Odysseus, navigating between Scylla and Charybdis.  In fact, you’re pretty sure that author of the legacy code made it necessary for the assigned developer to cut off and sacrifice a finger to get it working.

Scylla

Aware of all of this, you look at your manager with a mix of incredulity and horror, telling her that you’ll need at least 6 weeks to do this.  Already swirling around your mind is the dilemma between refactoring strategically where you can and running exhaustive manual testing for every character of the source code and XML that you change.  It’s now her turn to look incredulous and she says, “I’m just asking for a new field one one form.”  You’ve told her before about this, and she’s clearly forgotten.  You’re frustrated, but can you really blame her?  After all, it does sound a little crazy.

The Nature of Legacy Code

I’ve talked in the past about legacy code as code that developers are afraid to touch (which I correlate closely with Michael Feathers’ definition as “code without tests”).  If you accept this definition as axiomatic, there’s a critical implication here: legacy code creates a disconnect between the developers and everyone else.

As “everyone else” you see a form that needs a conceptually simple tweak.  As a developer, you see a mythological monster that threatens to rip your digits from your body; you see something that inspires fear.  And, while the bodily fear I’m referring to is an exaggeration, the visceral fear of unknown and lack of understanding is not.  Management is asking you to do something it thinks of as simple, and your head is flooded with an overwhelming number of possibilities as to how this could all go quite wrong.  And, worst of all, it’s really hard to explain this without it sounding as though you’re making excuses, being lazy, or being melodramatic.

If you want to understand how to manage expectations around the legacy code in your codebase, understanding this expectation mismatch is critical.  From that starting point, let’s look at some things you can do to make your life easier.

Read More

Jun
9

By

Creating Your Code Review Checklist

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

Editorial Note: I originally wrote this post for the SmartBear blog.  You can read the original here, at their site.  There’s a lot of other good stuff over there as well, so look around.

In any line of work, there are a number of rites of passage by which you can mark your career and feel good about milestones achieved.  Programming is no different.

Think back to the first time you were asked to perform a code review.  How exciting! (Though you probably laugh at your younger self now for being excited to review code.)  You spent time as the newest programmer in the organization, under the impression that code reviews were something done to you rather than by you, but now you have confirmation that your opinion is valued.

If you’re anything like me, the first thing you did in such a situation was to scramble to Google and start punching in things like, “how to conduct a code review,” “code review checklist,” or “code review best practices.” Being asked to weigh in on someone’s code is a lot of responsibility, and who wants to screw that up?  In such a Google search, you’ll probably find recommendations that steer you toward a list like this:

  • Does every method have an XML comment?
  • Do classes have a copyright header?
  • Do fields, methods, and types follow our standard naming convention?
  • Do methods have too many parameters?
  • Are you checking validity of method parameters?
  • Does the code have “magic” values instead of named constants?

Seems pretty reasonable, right?  If we brainstormed for an hour or two, we could probably flesh this out to be a comprehensive list with maybe 100 items on it.  And that’s what a lot of code review checklists look like — large lists of things for reviewers to go through and check.  So code review becomes an activity reminiscent of a line supervisor inspecting factory equipment with a clipboard.

Clipboard

There are two problems with this.

  1. You can’t keep 100+ items in your head as you look at every method or clause in a code base, so you’re going to have to read the code over and over, looking for different things.
  2. None of the checks I listed above actually require human intervention. They can all be handled via static analysis.

Read More

Jun
2

By

Why is Github Taking over the World?

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

Editorial Note: I originally wrote this article for the SmartBear blog.  Click here to check out the original.  If you like this content, take a look around at their offerings and their posts from other authors.

There’s a word out there that you’d be a lot more likely to hear from journalists, pundits, and authors than you would from techies: zeitgeist.  The dictionary definition of the word, “the general beliefs, ideas, and spirit of a time and place,” is straightforward enough.  But when used by the people I mentioned, zeitgeist, as a descriptor, imparts gravity on the thing it describes.  It I say that Github captures the zeitgeist of the programmer world of the 2010s, I am thus saying that Github is at the absolute core of the software development universe.

And I do say that.

If you’re not familiar with Github, I’ll offer a brief description.  It is a website that wraps a software version control system called “Git” and allows software developers to host their code online for free (though there are paid models available).  If you’re a software developer, Github is a repository for you to store, exchange, trade, and talk about code.  This may not sound like the stuff of which zeitgeists are made.

The sheer, raw popularity of Github alone doesn’t explain this classification, either, though it is popular.  Alexa, a web analytics company (not to be confused with Amazon’s Echo personality), ranks Github as the 83rd most popular site on the planet, as of the time of this writing.  That’s particularly impressive when you stop to consider that Github’s audience is the slice of software developers that feel like freely exchanging source code with one another.  Other popular sites occupying top rankings, like, Facebook, Amazon, or Google, on the other hand, have an audience of literally everyone on Earth.

It isn’t the improbable, raw volume of traffic to Github that elevates it to Zeitgeist level, however.  It isn’t even the growth or the market cap of the company or the number of contributing developers.  Those things alone can’t explain why Github is a zeitgeist — why it’s taking over the world.  To do that, let’s look at it in a bit more detail.

From Improbable Beginnings

Let’s take a little known, somewhat pedantic approach to storing code, wrap it in a cute user interface package, sprinkle a little social media on it, compete with an entrenched market dominator (sourceforge), give it away largely for free and change the world!

If I could go back to around 2008, when Github was just starting out, I can’t say I’d be clamoring at the bit to become an investor.  At least, not without 20/20 hindsight.  It doesn’t really sound like a game-changer, and yet that’s what it became.

And yet, if you look at tech trends, the makings were there, if subtle.

Distributed Version Control for a Remote World

If you’ve been writing code for a long time, you no doubt remember the bad old days of remote work when it comes to source code version control.  At the time Github first started attracting notice, centralized version control schemes were the standard, and when you were somewhere the source control server wasn’t, things could get painful.  I remember using a tool called Rational Clear Case that was setup in such a way that it took me most of the morning to commit a few files to source control if I was working from home.  As bad as that sounds, it could be worse — if you were on a plane or somewhere without internet access, you wouldn’t be able to work at all, unless you had planned ahead of time to acquire an “offline” version of the code.  And then, getting it back online could be quite painful once you re-connected.

CodersBlock

Git, the version control system upon which Github is based, changed all that with distributed version control.  Git was the version control of Linux — a decentralized, democratic tool that could support ad-hoc, global collaborations.  Github, the website, wrapped Git up and encouraged you to work with the full safety of source control wherever you were.  And, don’t worry, they reassured you, it’ll be a breeze to sync back up when you’re connected again.  And it was.

Github offered remote coding to an increasingly remote workforce.

Read More

Jun
1

By

Bridging the Communication Gap Between Developers and Architects

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the NDepend blog.  Go check out the original here, at their site.  While you’re there, have a look around at the other posts and at NDepend itself.

If you want to set off a ceaseless, spirited discussion, ask a roomful of people what makes some music good and other music bad.  The opinions are likely to be as spirited as they are diverse, with, perhaps, good points to be had.  But consensus is unlikely.

OppenheimerChoking

If you want to see a similar dynamic in the software development world, ask a roomful of software developers what a software architect is.  What makes a person an architect?  Does the architect write code?  What kinds of decisions should an architect make?  What is the relationship between architects and developers?  Do developers report to the architect, or is it a “dotted line” reporting relationship?  Maybe they’re peers?  Do architects need to have a lot of domain knowledge?  Do architects need to be the best programmers (or at least have been at some point)?  You get the idea.

Go out and observe enough software shops in action, and you will see every different imaginable answer to these questions in every possible combination.  This fact alone lays seeds for myriad communication complexities between developers and architects.  In any shop, a developer is more or less a developer.  But the architect role varies widely and, as developers move from company to company, this creates confusion.

Before going further down that path, let’s consider some things that are often true of a software architect.  And, I say “often true” because, as I just pointed out, the definition is fluid enough that it’s hard to pin things down definitively the way we might say, “software developers write computer programs.”

  • Architects tend to be the ones to make “big picture decisions” (which language/database/framework will we use?)
  • Architects tend to have more tenure at companies and more industry experience.
  • Architect tends to be a leadership role, meaning they supply either thought leadership, org chart leadership, technical leadership, or some combination.
  • Architects tend to have more face time with “the business” than developers.

What do all of these tendencies mean?  Well, simply put, they mean that architects have somewhat of a different area of focus than software developers.  Developers concern themselves primarily with the tactical, and architects concern themselves mainly with the strategic.  The concept of tactics versus strategy can be (perhaps over-) simplified to the idea that strategy is the “what” and tactics are the “how.”  If it comes to your personal finance, “diversification” may be the strategy and “spend X amount on stocks, Y on bonds, and Z on real estate” may be your tactics.

RobotWithMoney

Read More

« Older Posts
Newer Posts »