DaedTech

Stories about Software

By

Valuing Behaviors that Indicate Organizational Mediocrity

Hello!  Once again, I’m feeling pretty excited to be doing some actual free-form writing on the blog.  As best I can tell, I typically write an average of about 1,500 words per day.  And since many of those no longer go toward my (now draft complete) book, they can go toward other things.  For instance, sharing my thoughts on organizational mediocrity.

Over time, I’ve observed a growing list of organizations in action.  Usually, these heavily involve tech, or else I wouldn’t get a phone call.  But the actual purpose, shape and size of these places varies considerably.

All organizations tend to share some common ground, however.  For instance, at any kind of scale, they tend to form themselves into pyramids.  They also tend to make rules targeting their lowest common denominator.  But today I’d like to focus on a different, subtler commonality.

Organizations trend toward mediocrity by valuing apparently beneficial behaviors.  I’ll chalk these behaviors up as locally maximizing; they make tactical sense and create strategic messes.   Companies and society both value them in individuals.  But, counter-intuitively, encouraging them in your organization paves the road to hell with good intentions.

Read More

By

Measure Your Code to Get Back on Track

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.

When I’m called in for strategy advice on a codebase, I never arrive to find a situation where all parties want to tell me how wonderfully things are going.  As I’ve mentioned before here, one of the main things I offer with my consulting practice is codebase assessments and subsequent strategic recommendations.

Companies pay for such a service when they have problems, and those problems drive questions.  “Should we scrap this code and start over, or can we factor toward a better state?”  “Can we move away from framework X, or are we hopelessly tied to it?”  “How can we evolve without doing a forklift upgrade?”

To answer these questions, I assess their code (often using NDepend as the centerpiece for querying the codebase) and synthesize the resultant statistics and data.  I then present a write-up with my answer to their questions.  This also generally includes a buffet of options/tactics to help them toward their goals.  And invariably, I (prominently) offer the option “instrument your code/build with static analysis to raise the bar and prevent backslides.”

I find it surprising and a bit dismaying how frequently clients want to gloss over this option in favor of others.

Using the Observer Effect for Good

Let me digress for a moment, before returning to the subject of preventing backslides.  In physics/science, experimenters use the term “observer effect” to describe an experimental problem.  This occurs when the act of measuring a phenomenon changes its behavior, inextricably linking the two.  This presents a problem, and indeed a paradox, for scientists.  The mechanics of running the experiment contaminate the results of the experiment.

To make this less abstract, consider the example mentioned on the Wikipedia page.  When you use a tire pressure gauge, you measure the pressure, but your measurement lets some of the air out of the tire.  You will never actually know what, exactly, the pressure was before you ran the experiment.

While this creates a problem for scientists, businesses can actually use it to their advantage.  Often you will find that the simple act of measuring something with your team will create improvement.  The agile concept of “big, visible charts” draws inspiration from this premise.

In discussing this principle, I frequently cite a dead simple example.  On a Scrum team, the product owner has ultimate responsibility for making decisions about the software’s behavior.  The team thus needs frequent access to this person, despite the fact that product owners often have many responsibilities and limited time.  I recall a team who had trouble getting this access, and put a big piece of paper on the wall that listed the number of hours the product owner spent with the team each day.

The number started low and improved noticeably over the course of a few weeks with no other intervention at all.

Read More

By

The Pyramid Corporation: Your Grade School Teacher for Adults

I can now proudly say that I have finished the initial draft of Developer Hegemony.  Currently, it weighs in at a robust 376 pages that contain my blood, sweat, and tears.  Digitally speaking, anyway.

I haven’t yet published the preview of it because I want to give the people I interviewed a chance to peruse the draft before I make their words available.  But I promise that you’ll have a chance to read in its entirety soon.  I have a lot more coming on that front as well, including the announcement of a launch date, so stay tuned.

I mention completing the book because this should leave me with more time and material to post here on DaedTech.  I’ve mostly cross posted from the other blogs I write for of late, but look for an uptick in posts here.  Alongside that change, I’m going to be shuffling some other things around in my life as well, and changing my focus somewhat in the coming months.  I’ll get to all of this later, but for now, suffice it to say that I plan to post more about the suboptimal current state of the corporate entity and what I believe we can do about it.

And, I’ll start that tonight, with a theme that I wanted to address but didn’t fit particularly well in the book itself.  I’m talking about all of the ways that the corporation has come to simulate a sort of parental/teacher hybrid for adults.

Caveats

Before I go too far, I want to say that I’m not intending to serve up a blistering critique of society, per se.  I feel more philosophical and observational about this.  In other words, think less “this is all so stupid and people are sheep” and more “how and why did we get to this place?”

I understand the how, to some degree.  I think, anyway.  Pyramid shaped corporations (the standard corporate structure) have a knack for becoming less than the sum of their parts.  You can get buy with common sense up to a certain level of scale, and then finally you get some weirdo that likes to clip his fingernails next to the coffee machine no matter how much anyone asks him not to.  Then, bam.  You’ve got a sign next to your coffee machine exhorting people not to clip their fingernails, and your whole company looks ridiculous.

I think that organizational childishness tends to scale more than linearly with the average marginal childishness of individuals hired.  The bigger you get, the more your collective adulthood escapes.  Still, though, it’s amazing we don’t blink more often and scratch our head at the state of things.

Read More

By

Managing Code Analysis Statistics with the NDepend API

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Also, NDepend just released a new version that addresses tech debt extensively — check it out while you’re there!

If you’re familiar with NDepend, you’re probably familiar with the Visual Studio plugin, the out of the box metrics, the excellent visualization tools, and the iconic Zone of Uselessness/Zone of Pain chart.  These feel familiar to NDepend users and have likely found their way into the normal application development process. NDepend has other features as well, however, some of which I do not necessarily hear discussed as frequently.  The NDepend API has membership in that “lesser known NDepend features club.”  Yes, that’s right — if you didn’t know this, NDepend has an API that you can use.

You may be familiar, as a user, with the NDepend power tools.  These include some pretty powerful capabilities, such as duplicate code detection, so it stands to reason that you may have played with them or even that you might routinely use them.  But what you may not realize is the power tools’ source code accompanies the installation of NDepend, and it furnishes a great series of examples on how to use the NDepend API.

NDepend’s API is contained in the DLLs that support the executable and plugin, so you needn’t do anything special to obtain it.  The NDepend website also treats the API as a first class citizen, providing detailed, excellent documentation.   With your NDepend installation, you can get up and running quickly with the API.

Probably the easiest way to introduce yourself is to open the source code for the power tools project and to add a power tool, or generally to modify that assembly.  If you want to create your own assembly to use the power tools, you can do that as well, though it is a bit more involved.  The purpose of this post is not to do a walk-through of setting up with the power tools, since that can be found here.  I will mention two things, however, that are worth bearing in mind as you get started.

  1. If you want to use the API outside of the installed project directory, there is additional setup overhead.  Because it leverages proprietary parts of NDepend under the covers, setup is more involved than just adding a DLL by reference.
  2. Because of point (1), if you want to create your own assembly outside of the NDepend project structure, be sure to follow the setup instructions exactly.

A Use Case

I’ve spoken so far in generalities about the API.  If you haven’t already used it, you might be wondering what kinds of applications it has, besides simply being interesting to play with.  Fair enough.

One interesting use case that I’ve experienced personally is getting information out of NDepend in a customized format.  For example, let’s say I’m analyzing a client’s codebase and want to cite statistical information about types and methods in the code.  Out of the box, what I do is open Visual Studio and then open NDepend’s query/rules editor.  This gives me the ability to create ad-hoc CQLinq queries that will have the information I need.

But from there, I have to transcribe the results into a format that I want, such as a spreadsheet.  That’s fine for small projects or sample sizes, but it becomes unwieldy if I want to plot statistics in large codebases.  To address this, I have enlisted the NDepend API.

Read More

By

Automate Your Documentation

Editorial Note: I originally wrote this post for the SmartBear blog.

Few things, I’d say, strike boredom into the developer heart faster than the subject of documentation.  Does anyone out there really just love wrapping up development on a feature and then cranking out a Word document with a bunch of screen shots and step by step instructions.  Or, perhaps you fancy the excitement of pasting a legal header above a class you’ve just written, and then laboriously documenting all of methods, variables, and function parameters in the class?  If not that, how about the thrill of going back and updating comments that no longer make sense after the code has changed?

I suspect I don’t have a lot of takers at this point.

Documentation is boring, at least for the overwhelming majority of us.  After you’ve built a thing, you want to go build another thing — not rehash in laborious detail what you just did.  And yet, documentation is essential for communicating across time and teams to other people.  Your users will need documentation.  Future maintenance programmers need documentation.  Unless you’re going to be around in perpetuity to handle all that comes, you need to leave some sort of persistent knowledge transfer vehicle.

But that doesn’t mean it has to be tedious, repetitive, or boring.

Repetitive labor offers a certain counter-intuitive appeal, since it creates a “pain is gain” feeling of diligence and accomplishment when complete  But don’t be fooled.  People make many sloppy mistakes when doing repetitive tasks and drudgery is a terrible use of company money when you’re collecting a salary as a knowledge worker.  As people in the software industry, we earn a living automating grunt work out of existence, so let’s take a look at how we can help ourselves when it comes to documentation.

Read More