DaedTech

Stories about Software

By

CodeIt.Right Rules Explained, Part 4

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 to help you perform automated code reviews.  

Today, I’ll do another installment of the CodeIt.Right Rules, Explained series.  I have now made four such posts in this series.  And, as always, I’ll start off by citing my two personal rules about static analysis guidance.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More

By

Quality Gates with NDepend to Help You Fail Fast

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 at Quality Gates and other NDepend features.

I had this car once.  I loved the thing, but, before the end of its life, my wife and I had developed sort of a running joke about it.  Specifically, if you wanted to see the “check engine” light come on, take the thing on a road trip.  About 100 miles in, that light would come on.

The fog of memory has probably colored this tale somewhat.  I can’t imagine that this happened before literally every driving trip we took.  But it sure seems like it did.  I can vividly recall the feeling of “something’s wrong” when we’d come too far to reasonably turn back but still had most of the trip in front of us.

Against this backdrop, the wisdom of the software aphorism, “fail fast” hits home.  Had the light come on as we sat in the driveway, about to leave, we’d have had options.  Take my wife’s car.  Go to the dealership on the way out of town to make sure we could safely drive.  Something.  But, 100 miles into the trip, those options narrowed to “just keep going and hope for the best.”

If you must fail, better to do so early.

Fail Fast with Software Builds

When I first started as a professional software developer, “the build” tended to mean something much different than now.  We’d code furiously for months or years, and then someone would blow the “code freeze” whistle.  Then, after some testing, the “build guy” would pull the latest stuff out of CVS or Visual Source Safe and work on turning it into something that could be burned on a CD and distributed.  The first inkling of possible build problems would come something like 96% of the way through the project.  Heck, at that time, we had “merge parties,” wherein merging integrating one another’s separately developed source code could take days.

This created serious risk for projects.  We had the ability to unwittingly introduce defects that would not manifest until perilously close to project release time.  Like my potentially ill-fated driving trips, a too-late warning could create unacceptable delays and logistical problems.

So we, as an industry, learned to fail faster.  We brought in the concept of continuous integration and a build machine.  At the very beginning of a project, set the thing up for regular integration and delivery to a production (like) environment.  Know quickly if you introduced something that would gum up the downstream works.

Read More

By

Weaponized Mastery, Autonomy, And Purpose

Years ago, I published a post called How to Keep Your Best Programmers.  In it, I discussed what drives programmers out of jobs and what keeps them happy.  This discussion touched heavily on the concepts of mastery, autonomy, and purpose as important motivators for knowledge workers.  If you want to keep skilled programmers, you can’t just throw money and bonuses at them — you need to appeal to these other forms of motivation.

This post became quite popular and has remained so over the years.  I think the popularity results from the resonant idea of wanting our lives and careers to mean more than just a paycheck.  We want to be proud of what we do.

Since my own discovery of it years ago, I’ve seen frequent reference to these motivators and to Daniel Pink’s talk about them.  People use it to explain the difference between work that pays the bills and work that deeply satisfies.  More and more, we exhort our employers to appeal to mastery, autonomy, and purpose.  And more and more, they seem to do it, to our benefit and that of the industry at large.

But with this trend, I’ve noticed an interesting and unanticipated side effect.  People can appeal to autonomy, mastery, and purpose to enrich our lives, but they can also do so to manipulate us.

Mastery, autonomy, purpose -- they make us happy, but they can mesmerize us.

Mastery, Autonomy, and Purpose as Vices

To understand how that works, consider our desires in a different light.  Consider what happens when you take them to extremes.

We enjoy getting better at things (mastery), but that can lead to obsessive behavior.  I think most of us can relate, at some point in our life or another, to playing way too much of some kind of stupid video game.  We know it wastes our time and that we should probably delete it, but… just… one… more level.  Mastering the game drives us even when we know it wastes our time.

We also enjoy autonomy, but chasing that can lead to problems as well.  Have you ever known someone serially unemployed because they bristled at the thought of anyone telling them what to do?  Some people with that demeanor become entrepreneurs, but some become angry criminals.

And purpose as a vice can be, perhaps, the scariest of all.  Think about the phrase, “the ends justify the means.”  What is this if not a statement that purpose trumps all?  As long as you’re chasing a lofty enough goal, it doesn’t matter who you step on to get there.

We can chase mastery, autonomy, and purpose into problematic territory.  But other people can also use them to chase us there.

Read More

By

APIs and the Principle of Least Surprise

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at some of the other authors for their blog.

I remember something pretty random about my first job.  In my cubicle, I had a large set of metal shelves that held my various and sundry programming texts.  And, featured prominently on that shelf, I had an enormous blue binder.

Back then, I spent my days writing drivers and custom Linux kernel modules.  I had to because we made use of a real time interface to write very precisely timed machine control code.  As you might imagine, a custom Linux kernel in 2005 didn’t exactly come with a high production quality video walking users through the finer points.  In fact, it came with only its version of the iconic Linux “man pages” for guidance.  These I printed out and put into the aforementioned blue binder.

I cannot begin to tell you how much I studied this blue binder.  I pored through it for wisdom and clues, feeling a sense of great satisfaction when I deciphered some cryptic function example.  This sort of satisfaction defined a culture, in fact.  You wore mastery of a difficult API as a badge of honor.  And, on the flip side, failure to master an API represented a failure of yours.

Death of “Manual Culture”

What a difference a decade makes.  No longer do we have battleship gray windows applications with dozens of menus and sub-menus, with hundreds of settings and thousands of “advanced settings”.  No longer do we consider reading a gigantic blue documentation binder to be a use of time.  And, more generally, no longer do we put the onus of navigating a learning curve on the user.  Instead, we look to lure users by making things as easy as possible.

Ten years ago, a coarse expression described people’s take on this responsibility.  I’ll offer the safe-for-work version: “RTM” or “Read the Manual.”  Ten years later, we have seen the death of RTM culture.  This applies to APIs and to user experiences in general.

Read More

By

Manual Code Review Anti-Patterns

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 around at some of the other posts and at their offerings.

Today, I’d like to offer a somewhat lighthearted treatment to a serious topic.  I generally find that this tends to offer catharsis to the frustrated.  And the topic of code review tends to lead to lots of frustration.

When talking about code review, I always make sure to offer a specific distinction.  We can divide code reviews into two mutually exclusive buckets: automated and manual.  At first, this distinction might sound strange.  Most reading probably think of code reviews as activities with exclusively human actors.  But I tend to disagree.  Any static analyzer (including the compiler) offers feedback.  And some tools, like CodeIt.Right, specifically regard their suggestions and automated fixes as an automation of the code review process.

I would argue that automated code review should definitely factor into your code review strategy.  It takes the simple things out of the equation and lets the humans involved focus on more complex, nuanced topics.  That said, I want to ignore the idea of automated review for the rest of the post.  Instead, I’ll talk exclusively about manual code reviews and, more specifically, where they tend to get ugly.

You should absolutely do manual code reviews.  Full stop.  But you should also know that they can easily go wrong and devolved into useless or even toxic activities.  To make them effective, you need to exercise vigilance with them.  And, toward that end, I’ll talk about some manual code review anti-patterns.

Read More