Stories about Software


Are You Aggressively Trying to Automate Code Review?

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at their automated analysis and documentation tooling.

Before I talk in detail about trying to automate code review, do a mental exercise.  Close your eyes and picture the epitome of a soul-crushing code review.

You probably sit in a stuffy conference room with several other people.  With your IDE open and laptop plugged into the projector via VGA cable, you begin.  Or, rather, they begin.  After all, your shop does code review more like thesis defense than collaboration.  So the other participants commence grilling you about your code as if it oozed your incompetence from every line.

This likely goes on for hours.  No nit remains unpicked, however trivial.  You’ve even taken to keeping a spreadsheet full of things to check ahead of code reviews so as not to make the same mistake twice.  That spreadsheet now has hundreds of lines.  And some of those lines directly contradict one another.

When the criticism-a-thon ends, you feel tired, depressed, and hungry.  But, looking on the bright side, you realize that this is the furthest you’ll ever be from the next code review.

It probably sounds like I speak from experience because I do.  I’ve seen this play out in software development shops and even written a blog post about it in the past.  But let’s look past the depressing human element of this and understand how it proves bad for business.

Read More


Pair Programming Benefits: The Business Rationale

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their Retrace product that consolidates all of your production monitoring needs into one tool.

During the course of my work as a consultant, I wind up working with many companies adopting agile practices, most commonly following Scrum.  Some of these practices they embrace easily, such as continuous integration.  Others cause some consternation.  But perhaps no practice furrows more brows in management than pair programming.  Whatever pair programming benefits they can imagine, they always harbor a predictable objection.

Why would I pay two people to do one job?

Of course, they may not state it quite this bluntly (though many do).  They may talk more generally in terms of waste and inefficiency.  Or perhaps they offer tepid objections related to logistical concerns.  Doesn’t each requirement need one and only one owner?  But in almost all cases, it amounts to the same essential source of discomfort.

I believe this has its roots in early management theories, such as scientific management.  These gave rise to the notion of workplaces as complex systems, wherein managers deployed workers as resources intended to perform tasks repetitively and efficiently.  Classic management theory wants individual workers at full utilization.  Give them a task, have them specialize in it, and let them realize efficiency through that specialty.

Knowledge Work as a Wrinkle

Historically, this made sense.  And it made particular sense for manufacturing operations with global focus.  These organizations took advantage of hyper-specialty to realize economies of scale, which they parlayed into a competitive advantage.

But fast forward to 2017 and think of workers writing software instead of assembling cars.  Software developers do something called knowledge work, which has a much different efficiency profile than manual labor.  While you wouldn’t reasonably pay two people to pair up operating one shovel to dig a ditch, you might pay them to pair up and solve a mental puzzle.

So while the atavistic aversion to pairing makes sense given our history, we should move past that in modern software development.

To convince reticent managers to at least hear me out, I ask them to engage in a thought exercise.  Do they hire software developers based on how many words per minute they can type?  What about how many lines of code per hour they can crank out?  Neither of these things?

These questions have obvious answers.  After I hear those answers, I ask them to concede that software development involves more thinking than typing.  Once they concede that point, the entrenched idea of attacking a problem with two people as wasteful becomes a little less entrenched.  And that’s a start.

Read More


Automated Code Review to Help with the Unknowns of Offshore Work

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, take a look at CodeIt.Right, which offers automated code review feedback.

I like variety.  In pursuit of this preference, I spend some time management consulting with enterprise clients and some time volunteering for “office hours” at a startup incubator.  Generally, this amounts to serving as “rent-a-CTO” for for startup founders in half hour blocks.  This provides me with the spice of life, I guess.

As disparate as these advice forums might seem, they often share a common theme.  Both in the impressive enterprise buildings and the startup incubator conference rooms, people ask me about offshoring application development.  To go overseas or not to go overseas?  That, quite frequently, is the question (posed to me).

I find this pretty difficult to answer absent additional information.  In any context, people asking this bake two core assumptions into their question.  What they really want to say would sound more like this.  “Will I suffer for the choice to sacrifice quality to save money?”

They assume first that cheaper offshore work means lower quality.  And then they assume that you can trade quality for cost as if adjusting the volume dial in your car.  If only life worked this simply.

What You Know When You Offshore

Before going further, let’s back up a bit.  I want to talk about what you actually know when you make the decision to pay overseas firms a lower rate to build software.  But first, let’s dispel these assumptions that nobody can really justify.

Understand something unequivocally.  You cannot simply exchange units of “quality” for currency.  If you ask me to build you a web app, and I tell you that I’ll do it for $30,000, you can’t simply say, “I’ll give you $15,000 to build one half as good.”  I mean, you could say that.  But you’d be saying something absurd, and you know it.  You can reasonably adjust cost by cutting scope, but not by assuming that “half as good” means “twice as fast.”

Also, you need to understand that “cheap overseas labor” doesn’t necessarily mean lower quality.  Frequently it does, but not always.  And, not even frequently enough that you can just bank on it.

So what do you actually know when you contract with an inexpensive, overseas provider?  Not a lot, actually.  But you do know that your partner will work with you mainly remotely, across a great deal of distance, and with significant communication obstacles.  You will not collaborate as closely with them as you would with an employee or an local vendor.

Read More


.NET Code Documentation So Easy It’s an Afterthought

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, take a look at GhostDoc if you want automated documentation for your API.

Though I’ll talk today about .NET code documentation, I want to start further back than that. And by “that,” I mean further back than .NET. I realize that may date me somewhat, but please bear with me.

Most things in the programming world date back further than you’d think. For a dramatic example of this, consider functional programming. All the rage today, it actually dates back to the 60s in practice and 30s in theory. Speculating about the reason for temporal myopia would go beyond the scope of this post, but understand that this tendency toward myopia does exist.

With that in mind, let’s talk about some GUI builders.

A Tale of Two GUI Builders

Now we get to the part that predates .NET. I’m going to reach back into my early career and compare my relatively simultaneous experience with two GUI building technologies.

First, I encountered Swing, a Java GUI toolkit. While Swing did not include a GUI builder at the time, my project packaged it with one. I cannot remember its name for the life of me, but this thing was a train wreck. Moving controls around on a form caused the spewing of improbable amounts of code into my Java classes. Attaching handlers to GUI events only half worked, requiring wire up by hand. I had such struggles with it that I gave up and just hand-coded everything in Java.

Shortly after working on that project, I found myself saddled with a VB6 application. At the time, .NET actually existed, but nobody had ported this thing to it. So I used VB6. And I loved it.

That probably sounds as weird to hear as it feels to type, but there it is. Compared to my experience with Swing and its nightmarish GUI builder, this was a refreshing summer breeze. I could move controls around to my heart’s content, wire up events easily, and get stuff done.

Read More


Transitioning from Manual to Automated Code Review

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at CodeIt.Right.

I can almost sense the indignation from some of you.  You read the title and then began to seethe a little.  Then you clicked the link to see what kind sophistry awaited you.  “There is no substitute for peer review.”

Relax.  I agree with you.  In fact, I think that any robust review process should include a healthy amount of human and automated review.  And, of course, you also need your test pyramid, integration and deployment strategies, and the whole nine yards.  Having a truly mature software shop takes a great deal of work and involves standing on the shoulders of giants.  So, please, give me a little latitude with the premise of the post.

Today I want to talk about how one could replace manual code review with automated code review only, should the need arise.

Why Would The Need for This Arise?

You might struggle to imagine why this would ever prove necessary.  Those of you with many years logged in the enterprise in particular probably find this puzzling.  But you might find manual code inspection axed from your process for any number of reasons other than, “we’ve decided we don’t value the activity.”

First and most egregiously, a team’s manager might come along with an eye toward cost savings.  “I need you to spend less time reading code and more time writing it!”  In that case, you’ll need to move away from the practice, and going toward automation beats abandoning it altogether.  Of course, if that happens, I also recommend dusting off your resume.  In the first place, you have a penny-wise, pound-foolish manager.  And, secondly, management shouldn’t micromanage you at this level.  Figuring out how to deliver good software should be your responsibility.

But let’s consider less unfortunate situations.  Perhaps you currently work on a team of 2, and number 2 just handed in her two week’s notice.  Even if your organization back-fills your erstwhile teammate, you have some time before the newbie can meaningfully review your code.  Or, perhaps you work for a larger team, but everyone gradually becomes so busy and fragmented in responsibility as not to have the time for much manual peer review.

In my travels, this last case actually happens pretty frequently.  And then you have to chose: abandon the practice altogether, or move toward an automated version.  Pretty easy choice, if you ask me.

Read More