Stories about Software


What to do when Your Colleague Creates Spaghetti Code

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, take a look around and give NDepend a try.

I write for a number of different outfits and earn my living consulting around software and IT.  Because of the intersection of these three concerns — writing, offering advice professionally, and software — I field a lot of requests for advice on how to do the right technical thing without everyone around you shooting holes in it.  Consider an example.

“How can we get started with unit testing?”

Considered as a technical question alone, this invites a fairly obtuse response.  “First, write a unit test.  Second, run the unit test.”  Obviously, that’s not really what anyone is asking when they ask this question.

Instead, they want to know something orders of magnitude more complex.  “How can we overcome years of inertia, a nasty legacy codebase, Bill, who has been around for 40 years and hates everything new, and the fact that management doesn’t want to pay us to write ‘extra’ code… and then start unit testing?”  Oh, yeah, that.  Well, that’s complicated.

I frequently hear such apparently-innocuous-but-actually-complex questions about code quality.  “This idiot on my team is writing mountains of the most unmaintainable garbage imaginable — what should I do?”


Usually, this sort of question comes to me from people at client sites.  And, accordingly, I have to balance the answer that makes the most sense for the individual with the one that keeps the client’s best interests in mind.  The client pays my bill, and I have a charter to lower the cost of ownership and development of their code.

But when I’m in writer mode, and only the asker’s interests matter, I’l give a subtly different answer.  Today, I’d like to offer advice on what you should do in this situation.

Read More


Securing Yourself a Better Title

Tonight marked the vice-presidential debate and the start of the baseball playoffs.  With two spectator sports on television, I thought I’d draw some inspiration and answer a reader question about office politics.  This question came to me from a reader whose problem tracks back (in my opinion) to need for a better job title.  And it came in lengthy format, checking in about 1,100 words!

For the sake of both poster anonymity and brevity, I will summarize with as little information loss as possible.  My summary is as follows.

I finished a CS degree and took an entry level position.  From there, I took a job that involved writing code — automation around Selenium to be used by a QA group for testing.  I believe this mimics the role of Google’s “Software Engineer in Test.”  That said, the conferred upon me the title of “QA Engineer.”

For two years, I enjoyed the development work in this role and made inroads toward an advancement.  Before that happened, however, my company shuffled departments, and I found myself in a new part of the company, under a new boss.  This new boss only saw me for my title, rendering my progress moot.

I approached him about my situation and he agreed to put me on a more classic development team, but on a “probationary” basis.  He said that he’d consider a formal change in six months if I could work on defects and get my fix rate up to a certain number per week.  Six months later, at a review, he said that I had made definite progress, but that my rate of X per week was just not QUITE high enough and that we could talk again next year at performance review time.

What are my options?  What should I do next?  I feel that I’ve now fallen behind people of a similar, salary-wise, and I feel stuck in a rut.


Title Matters

Let me start by offering a quick bit of context.  Recruiters and people offering you jobs with bad titles will tell you that titles don’t matter.  Don’t listen to recruiters and people offering you bad titles because titles do matter.

They matter because a job title counts as what I’ll call passive bargaining material.  When you navigate the waters of your career, you will have negotiation points where you look for more salary or benefits or whatever.  The actual negotiating constitutes the active component of this dance, and that matters.  But so does the passive portion: your previous/current title, salary, benefits, etc.

Don’t believe me?  If you’re a developer, cold-apply to a bunch of dev manager or director gigs.  No responses?  Try adding a fictitious 5 year stint as “Director of Software Engineering” to the top and try again.  Bet you get at least a few calls.

Read More


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.


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


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.


Read More


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.

*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