DaedTech

Stories about Software

By

Defining Developer Collaboration

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at the pieces written by other authors as well.

A certain ideal of rugged individualism has always permeated programmer culture, at least in some circles. It’s easy enough for writing code to be a highly solitary activity. There’s a clear set of rules, output is a function of input, feedback is automated, and the profession tends to attract night owl introverts in many cases.

The result is a history punctuated by tales of late night, solo efforts where someone stares at a computer until overcome by sleep. Obsessed, brilliant hackers expend inconceivable efforts to bring amazing open source tools or useful libraries into existence. It squares with movies, popular culture, and our own knowledge of our profession’s history.

SuperFastTyping

And yet, how many significant pieces of software are developed this way anymore? This ideal was born into a world where complex software might have required 10 thousand lines of code, but does it carry forward in a world where 10 million lines are common? Even projects started by individuals on a mission tend to wind up on Github and to gather contributors like a snowball rolling down a mountain.

Today’s technical landscape is a highly complex, highly specialized, and highly social one. In a world where heroic individual contributions are increasingly improbable, collaboration becomes the name of the game. Like it or not, you need other people to get much done because the work and the breadth of knowledge tends to be too much for any one person.

Defining Collaboration for Developers

I’ll spare you the obligatory, “Webster’s Dictionary defines collaboration as…” It means what you think it means: people working together. I’d like, instead, to establish some axiomatic ground rules in applying the term to the world of software development.

The first requirement is, of course, that you need to have more than one human being involved to consider the effort to be collaboration. The mechanisms, protocols and roles can vary widely, but table stakes require more than one person.

The second requirement is that the participants be working toward a shared goal. Without this, a bunch of people in a coffee shop could be said to be ‘collaborating’ simply by virtue of colocation and the occasional, polite interaction. Collaboration requires multiple people and it requires them to be united in purpose for the activity in question.

A final and developer-oriented requirement is that the participants must be working on the same work product (i.e. codebase). Again, consider a counter-example in which iOS and Android developers could be said to be ‘collaborating’ since there are more than one of them and they’re united in the purpose of improving users’ smartphone experience. Their shared purpose has to bring them together to work on the same actual thing.

Really, though, that’s it. More than one person, united in purpose and working on the same thing, are necessarily collaborating. Whether they do it well or not is another matter.

Read More

By

5 Reasons Architect and Developers Argue

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, check out NDepend and download a trial.

There’s a cute term for a blog post or article that advertises, in its title, a number of points of interest. For example, “9 Tips for Getting out of Debt,” as a title would quality. This is called a “listicle,” which is a conjoining of list and article into one word (though, for me, this somehow manages to evoke the vague image of someone licking an icicle).

This template is not normally my style, but I thought it might be fun to try it on and see how it goes. The topic about which I’d like to talk today is the various vectors for architect-developer tension and this seems, somehow, uniquely suited to the listicle format.

Where the developer role is pretty standard, the architect role is often vague in its definition and can vary widely from organization to organization. In some shops, the architect is just the longest tenured developer, whereas in others the architect is a specialized role that generates mountains of UML diagrams.

The ambiguity and variance, combined with the fact that architect is nominally ‘above’ developers, creates a breeding ground for interpersonal friction. While not always present, this is a common theme in the industry. So, I’d like to examine 5 reasons for strife between developers and architects.

Spies

Read More

By

What It Really Means to Niche Down

It’s been a rather frustrating few weeks for me, at least in terms of getting things done at home.  One of the cables on my garage door got off of its track somehow, and my time is at a premium, so I set about hiring someone to fix it.  I went onto Angie’s List to see if I could find a contractor that specialized in solving this sort of problem.

Looking for that was probably stupid, however.  I realized my mistake when I got onto the site and did a search for contractors.  I tried searching for terms like “fixes garage doors” and got empty results back.  Stymied, I started looking at contractor profiles and seeing that they really didn’t match in any way even remotely like that.  Here’s what a typical one looked like.

  • Extremely proficient in hammer, table saw, drill driver, and crowbar.
  • 5 years of experience cutting cables, tying knots, and winding metal cables around spring-loaded spools.
  • Limited experience with reciprocating saw and lathe.
  • Regularly determines the correct situation for using a screw versus a nail.
  • Strong preference for DeWalt tools.
  • Capable of carrying tools in a bag, box, or wheeled assembly as dictated by the job.
  • Excellent oral and written communication skills.
  • FFL, AFF, UON, IBEW, ECB, SE

*Smacked forehead*  Of course!  I’d been going about this all wrong.  I was looking for an expert to solve my problem, when what I really needed to do was spend a lot of time learning the minutiae of what exact skills, tools, and techniques were necessary to solve that problem.  Once I’d spent a few days doing that, I could then make a still ill-informed guess as to which contractor’s experience might prove relevant to my situation.

That’s exactly what I did, and, though you’d assume this would go well, somehow, it didn’t.  The first guy said he had a lot of experience with steel cables, things that twist, and larger fixtures.  As a bonus, he expressed an intimate knowledge of how water would impact the garage door apparatus.  I had no idea how this was relevant, but he sounded like he knew what he was doing, so I hired him.  After two days, I came and found that he hadn’t fixed the door, but he had installed a sink that was blocking my car in.  When I demanded to know why he’d done this, he confessed that he was really more of a plumber, but that he wanted to learn about garage doors and just assumed that they were more or less the same thing.

Sink in Garage

The next guy didn’t build anything that blocked my car in.  As a matter of fact, he didn’t build anything at all.  He just came in for a few days, laid all kinds of screws, nuts, bolts, and magnets on the ground, and then proceeded to arrange, re-arrange, and re-re-arrange them ad nauseum.  Each time he’d do it, he’d squint at the broken garage door apparatus and mutter to himself about it being important to have the right organizational framework to tackle this problem.  When I finally let him go after a few days, he’d managed to build a small pyramid out of 2 inch screws.  I’m not going to lie; it was impressive.  But it was also useless.

Knowing that this was stupid, I did what any reasonable person would do.  Instead of hiring someone to solve my problem, I hired someone that could both understand what I was trying to do and who could also make sense of all of these contractor profiles.  All it cost me was an extra 20% of the job total.

Read More

By

Dealing with Legacy Code for Developers: Managing your Manager

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

By

Creating Your Code Review Checklist

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