DaedTech

Stories about Software

Jun
30

By

Does Github Enhance the Need for Code Review?

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

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Take a look around while you’re there and check out their products and other posts.

In 1999, a man named Eric S. Raymond published a book called, “The Cathedral and the Bazaar.”  In this book, he introduced a pithy phrase, “given enough eyeballs, all bugs are shallow,” that he named Linus’ Law after Linux creator Linus Torvalds.  Raymond was calling out a dichotomy that existed in the software world of the 1990s, and he was throwing his lot in with the heavy underdog at the time, the bazaar.  That dichotomy still exists today, after a fashion, but Raymond and his bazaar are no longer underdogs.  They are decisive victors, thanks in no small part to a website called Github.  And the only people still duking it out in this battle are those who have yet to look up and realize that it’s over and they have lost.

Cathedral

Cathedrals and Bazaars in the 1990s

Raymond’s cathedral was heavily-planned, jealously-guarded, proprietary software.  In the 1990s, this was virtually synonymous with Microsoft, but certainly included large software companies, relational database vendors, shrink-wrap software makers, and just about anyone doing it for profit.  There was a centrally created architecture and it was executed in top down fashion by all of the developer cogs in the for-profit machine.  The software would ship maybe every year, and in the run up to that time, the comparably few developers with access to the source code would hunt down as many bugs as they could ahead of shipping.  Users would then find the rest, and they’d wait until the next yearly release to see fixes (or, maybe, they’d see a patch after some months).  The name, “cathedral” refers to the irreducible nature of a medieval cathedral — everything is intricately crafted in all or nothing fashion before the public is admitted.

The bazaar, on the other hand, was open source software, represented largely at the time by Linux and Apache.  The source code for these projects was, obviously, free to all to look at and modify over the nascent internet.  Releases there happened frequently and the work was crowd-sourced as much as possible.  When bugs were found following a release, the users could and did hunt them down, fix them, and push the fix back to the main branch of the source code very quickly.  The cycle time between discovery and correction was much, much smaller.  This model was called the bazaar because of the comparably bustling, freewheeling nature of the cooperation; it resembled a loud, spontaneously organized marketplace that was surprisingly effective for regulating commerce.

Read More

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

« Older Posts
Newer Posts »