Stories about Software


How to Get an Edge As a Consultant

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, have a look around at some of the documentation around code metrics and queries.

I’ve made no secret of, and even frequently referred to my consulting practice, including aspects of IT management consulting.  In short, one of my key offerings is to help strategic decision makers (CIOs/CTOs, dev managers, etc) make tough or non-obvious calls about their applications and codebases.  Can we migrate this easily to a new technology, or should we start over?  Are we heading in the right direction with the new code that we’re writing?  We’d like to start getting our codebase under test, but we’re not sure how (un) testable the code is — can you advise?

This is a fairly niche position that’s fairly high on the organizational trust ladder, so it’s good work to be had.  Because of that, I recently got a question along the lines of, “how do you get that sort of work and then succeed with it?”  In thinking about the answer, I realized it would make a good blog post, specifically for the NDepend blog.  I think of this work as true consulting, and NDepend is invaluable to me as I do it.

Before I tell you about how this works for me in detail, let me paint a picture of what I think of as a market differentiator for my specific services.  I’ll do this by offering a tale of two different consulting pitfalls that people seem to fall into if tasked with the sorts of high-trust, advisory consulting engagements.


Read More


Code Review Beyond Meeting Rooms and Projectors

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re over there, have a look at their Collaborator offering.

It must have been a decade ago.  I was sitting in a spaciously appointed conference room around a large, round table, surrounded by fellow software developers from my company.  Coffee and bright lights notwithstanding, we were all struggling to varying degree to keep alert.

The reason for our struggle was that we were spending the day doing a marathon code review, and we were barely halfway through the morning.  A representative of the team that had written the code was on hand, walking us through it, showing the code against a pull down screen with a projector.  We were being treated to file after file after file, in alphabetical order, in a text editor.

There were hours of this yet to go.  And yet, it was an unavoidable matter of due diligence.  In spite of our wandering attention spans, we believed this, as did our management.  Our company had contracted with a custom software vendor to write an application that our company would take over and maintain.  This firm had scurried off for 9 months or so, and they were now presenting “phase 1” to us.  This was our chance to raise concerns and provide input.  Theoretically, anyway.


As you can imagine, this was not an especially effective way to spend a day (or several, as it would turn out).  We technically saw all of the code that was being delivered, but it wasn’t as though this activity produced a lot of meaningful output.  There were some obvious reasons for this, such as the enormous batch of reviewing 9 months of code and the marathon, all-in nature of the session.  But there were also some issues related to tooling and process that were pretty limiting compared to what we have now.

10 years have elapsed since this yawn-inducing series of days I spent in review.  And, while you’re still going to be in trouble if you try meaningfully to review 9 months of a team’s code in a few days, tools and workflows have emerged in the interceding years that make code review much easier.  You should be taking advantage of them.

Read More


Undercover Testability Killers

Editorial Notes: I originally wrote this post for the Infragistics blog.  You can check out the original here, at their site.  While you’re there, take a look around at the other posts by their contributing authors.

If you were to take a poll of software development shops and ask whether or not they unit tested, you’d get varied responses.  Some would heartily say that they are, and some would sheepishly say that they totally mean to get around to that next year and that they’ve totally been looking into it.  In the middle, you’d get a whole lot of responses that amounted to, “it’s complicated.”

In my travels as a consultant, I witness the reason for this firsthand.  The adoption rate of automated testing has increased dramatically in the last decade, and that increased adoption means that a lot of shops are taking the plunge.  And naturally, this means that a lot of shops with a lot of legacy code and awkward constructs in their codebases are taking the plunge, which leads to interesting, complicated results.


It’s Complicated

“It’s complicated” generally involves variants of “we tried but it wasn’t for us” and “we do it when we can, but the switch hasn’t flipped yet.”  And, at the root of all of these variants lies a truth that’s difficult to own up to when talking about your group – “we’re having trouble getting any good at this.”

If this describes you or folks you know, take heart, though.  The “Intro to TDD” and “NUnit 101” guides make it look really, really easy.  But those sources of learning usually show you how to write unit tests for things like “in-memory calculator,” intending to simplify the domain and code so that you understand the mechanics of a unit test.  But, in doing this, they paint a deceptive picture of how easy covering your code with tests should be.

If you’ve been writing code for years with nary a thought to testing at the unit level, it’s likely that familiar, comfortable coding practices of yours are proving to be false friends.  In other words, your codebase is probably littered with things that are actively making your life extremely difficult as you try to adopt automated testing.  What follows are some of the most common ones that I see.

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


Habits that Help Code Quality

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you like posts about static analysis, code quality, and the like, check out the rest of the blog.

When I’m called in to do a strategic assessment of a codebase, it’s never the result of everything being awesome.  That is, no one calls me up and says, “we’re ahead of schedule, under budget, and knocking it out of the park, so can you come in and tell us what you think of our code?”  Rather, I get calls when something isn’t going according to plan and the business people involved want to get some insight into what underlying causes there are in the code and in the team’s approach.

When the business gets involved this way, there is invariably a fiscal operational concern, either overtly or lurking just beneath the surface.  I’ll roll this up to the general consideration of “total cost of ownership” for the codebase.  The business is thus asking, “why are things proving more expensive than we thought?”


Typically, I come in, size up the situation, quantify it objectively, and then use analogies and examples to make clear what’s happening.  After I do this, pretty much without exception, the decision-makers to whom I’m speaking want to know what small things they can do, internally, to course correct.  This makes sense when you think about it.  If your doctor told you that your health outlook wasn’t great, you’d cross your fingers and say, “but I can fix it by changing my diet and exercise a little, right?”  You wouldn’t throw yourself on the table and say, “cut me open and make sure whatever you do is expensive!”

I am thus frequently asked, by both developers and by management, “what are the little things we can do to improve and maintain code quality.”  As such, this seems like excellent fodder for a blog post.  Here are my tips, based on years of observation of what correlates with healthy codebases and what correlates with distressed ones.

Read More