DaedTech

Stories about Software

By

The Opportunist’s Guide to Start Consulting (Abridged)

Given the recent launch of Developer Hegemony, I decided to address a reader question.  This question hits near and dear to my heart and to the subject matter of the book. I’m going to paraphrase for the sake of anonymity.  But, either way, it amounts to a question about how to start consulting.

But First, Some Housekeeping

Before I dive into that, though, I’d like to make offer some links.  If you want to hear and read more from me, I offer you the chance.  Check these out.

And now, back to your regularly scheduled post.

The Reader Question

Without additional preamble, I’ll offer up the (paraphrased) reader question.

I’m currently a developer, and want to transition to freelance consulting. But I’m not quite sure where to start.. Do you have any advice on that? How did you manage to start a consultancy business?

First of all, understand the dichotomy here.  He asks for my advice and he also asks how I did it.  I ask everyone reading to understand that these aren’t necessarily the same thing.  In other words, I can tell you exactly what I did, but that doesn’t mean I think you should do it in exactly that way.

Oh, don’t get me wrong.  I don’t think I made any horrible mistakes or anything like that.  But I kind of wandered my way through the experience, not entirely sure at the time what I wanted.  Unlike the reader asking the question, I never explicitly decided to become a freelance consultant.  In fact, I just had some free time and wanted some extra money.

Read More

By

Have You Seen the NDepend API?

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, download NDepend and give it a try.

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, however, 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.

Read More

By

Making Devs, Architects, and Managers Happy with the Static Analysis Tool

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  I use NDepend to drive my custom static analysis of .NET codebases — you should check it out.

Organizations come to possess static analysis tools in a variety of ways.  In some cases, management decides on some kind of quality initiative and buys the tool to make it so.  Or, perhaps some enterprising developers sold management on the tool and now, here it is.  Maybe it came out from the architecture group’s budget.

But however the tool arrives, it will surprise people.  In fact, it will probably surprise most people.  And surprises in the corporate context can easily go over like a lead balloon.  So the question becomes, “how do we make sure everyone feels happy with the new tool?”

A Question of Motivation

Before we can discuss what makes people happy, we need to look first at what motivates them.  Not all folks in the org will share motivation — these will generally vary by role.  The specific case of static analysis presents no exception to this general rule.

When it comes to static analysis, management has the simplest motivation.  Managers lack the development team’s insights into the codebase.  Instead, they perceive it only in terms of qualitative outcomes and lagging indicators.  Static analysis offers them a unique opportunity to see leading indicators and plan for issues around code quality.

Architects tend to view static analysis tools as empowering for them, once they get over any initial discomfort. Frequently, they define patterns and practices for teams, and static analysis makes these much easier to enforce.  Of course, the tool might also threaten the architects, should its guidance be at odds with their historical proclamations about developer practice.

For developers, complexity around motivation grows.  They may share the architects’ feelings of threat, should the tool disagree with historical practice.  But they may also feel empowered or vindicated, should it give them voice for a minority opinion.  The tool may also make them feel micromanaged if used to judge them, or empowered if it affords them the opportunity to learn.

Read More

By

What’s Next: Epilogue of a Book Launch

Yesterday, I launched a book.  I went back through my email and my history with Leanpub to find out exactly when I started writing the book.  It turns out, I created Developer Hegemony on Leanpub on May 2nd, 2015.  So with completely unplanned symmetry, I launched the book exactly 2 years after starting.

The launch went as well as I could have hoped.  Many thanks to all of you that tweeted, shared, purchased, reviewed, and just generally offered kind words and support.  We ended day 1 with Developer Hegemony ranked in the top 50 in 3 different categories.

Not too shabby for something written on Leanpub and self-published!

But, as launch day becomes launch week and (hopefully) sales continue at a brisk pace, I’ve started to think about what comes next.

Transitions

For my part, I’ve spent the last few years doing a combination of training developers, assessing codebases, and doing IT management consulting.  As you might imagine, this combination of activities led to a lot of time at client sites, and a lot of time on the road.

So these years have seen me traveling and working with clients by day.  And then, by night, I wrote blog posts and a book in hotel rooms.   I got a lot done.

But this gets to be a grind after a while.  I can work all day and then also work in the evenings.  In fact, I’ve done that for years.  But, add to that 10+ hours per week of travel, constant packing and unpacking, cramming all bills and chores into tight windows of time, and tons of other little considerations, and you wind up needing a break.

Last Friday, I wrapped an extended travel engagement and came home.  This morning, I launched a book 2 years in the works.  Starting tomorrow, I have no book in the works and no plans to do traveling, open-ended, hourly consulting.

Instead, I’m going to start making some changes, and doing new, different things.  I’m going to have different sets of priorities and new activities that focus on building businesses instead of just doing hourly labor.  As I’ve heard others say, I’m looking to get away from simply trading hours for dollars.

Read More

By

Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development

Well, today we officially launch the book, Developer Hegemony.  I’d like to thank everyone who followed along, offered feedback, bought books, and generally supported the efforts.  I’ve enjoyed the ride and I hope you all love the book.  Also, congratulations to the winners of the Thunderclap raffle: Justin Neff, Jim Wang, and Gintautas Miselis!  I will be sending free copies their way.  Thanks to them and to everyone that participated!

In the final days of writing Developer Hegemony and throughout launch preparation, I wrestled with an elevator pitch.  As regular readers know, you wouldn’t find “brevity” listed on my resume, even if making resumes was something I did.  And so I struggled.  But I think I have it now.

“Why aren’t software developers in charge of the software development industry?  Developer Hegemony explains why not, and it explains how we fix that problem.”

Today, I’ll explain the book by expanding on this elevator pitch a bit.

Who’s In Charge Here, Anyway?

So, if software developers don’t run the industry, who does?  To answer that question, understand the context in which most developers write software.  It happens in the corporate world, which consists of companies shaped like pyramids.

 

Reminiscent of military organizations, a tree-like chain of command serves as the scaffolding for most companies.  The CEO gives orders to a handful of C-suite members.  These people, in turn, give orders to a larger number of vice presidents, who then give orders to a whole bunch of directors.  The directors then give orders to hordes of managers, who pass those orders down to legions of grunts.  Finally, with the grunts, you arrive at the leaves of the tree and the bottom of the pyramid.

And those leafy grunts write the world’s software, carrying pyramids of management upon their backs.  So who is more important than software developers in the business of software development?  Literally gigantic pyramids of management.  Oh, and you can also toss in some people who technically exist in the same level of the reporting organization but have titles like “analyst” or “project manager.”

So the question shifts from “who is more important than software developers in the business of software development?” to “who isn’t?”

Read More