DaedTech

Stories about Software

May
3

By

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

Category: Language Agnostic Tags: , , | 4 Comments

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

May
2

By

What’s Next: Epilogue of a Book Launch

Category: Announcements | 2 Comments

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

May
1

By

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

Category: The Life of a Programmer Tags: | 12 Comments

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

Apr
30

By

Rethinking Retirement, Efficiencer Style

Category: The Life of a Programmer Tags: , |

Today, I offer post number 7 for Developer Hegemony week.  I had every intention of doing 9 days of posts in a row leading up to launch, but I wound up spending yesterday relaxing and recuperating (not a lot of Sunday traffic anyway).  I just finished up an engagement and had been on the road for weeks straight, finally getting home Friday night.  So I took a day off.

The good news is that even with me taking it easy yesterday, the internet did not.  The Thunderclap campaign reached its goal!  This means that I will now definitely give away 3 free copies of my book.  So signing up now gives you better odds than ever.  

A post about rethinking retirement might seem odd, but I have a method to this madness.  As you contemplate your working career, retirement may not come immediately to mind.  But it certainly looms large over decisions you make during your career, in much the same way that the college admissions process tends to loom large over high school.  You contribute to 401Ks, look at the compound effect of salary negotiations and the like, all with an eye toward retirement.

So let’s dive into the mechanics of normal wage work and retirement a bit today.  But first, I’ll lead in with a quick rationale for what brought this to mind.

Hourly Wage for Book Writing

Because I have some varied business interests, I tend to get politely restrained questions from people with salaried jobs as an exclusive source of income.  People regard direct questions about income quantity as gauche, so they kind of ask how things work in the abstract.  They beat around the bush a bit.

For this reason, I find myself speaking at times to a conceptual hourly wage for, say, writing a book or making a Pluralsight course.  I find this understandable, since wage employees tend to reason about earning income as if all income were wage income.  Understandable, yes.  But it misses the point.  And my explanation for why ties in with retirement and the idea of building what I’ll call “business properties.”

Retirement from Wage Earning, Simply Explained

Okay, so back to retirement.  I’ll start with an oversimplified version of how that works.  Specifically, let’s forget for the moment about any concept of social security, pensions, or investing in markets.  A wage earner spends most of his adult life collecting a paycheck.  He uses some percentage of that paycheck and sets some percentage aside, stuffing it into his mattress.  He continues to do this until he has more stuffed into his mattress than he’ll need before he dies.  At this point, he retires.

For the sake of easy math, let’s assume that this hypothetical person averages $100K per year as a salary throughout his career.  Let’s say that he decides he can live on $50K per year in retirement and that he saves 10% of his salary throughout his life.  If he starts working at 20 and retires at 70, he will have set aside a total of $500K.  This will allow him to live from 70 to 80 before he runs out of money.  So in a strange case of somewhat perverse incentives, he should hope not to live longer than 80 (or he should continue working).

Read More

Apr
28

By

The Efficiencer’s Guide: Getting Started

Category: The Life of a Programmer Tags: , , |

You thought Developer Hegemony Week stopped on Friday?  Nah.  Today I give you post 6.  It contains somewhat lighter fare, since it’s the weekend, but the show must go on.  We’re doing really well on the Thunderclap campaign — 83% as of this writing.  But that means I still need 17 more people to do the raffle.  So, please help me out and spend a few seconds signing up!

In the book, I coined this term, Efficiencer.  I also talked about it on the blog this week.  Today, I’d like to offer what I’ll call the efficiencer’s guide (or, at least, the start of it).  I’ve called out a number of idealized behaviors and philosophies, but haven’t given a lot of practical field advice.

For the purposes of the efficiencer’s guide, I’ll assume you work as a salaried software developer in some organization.  This probably describes most of my audience, and it makes for a natural starting point in this journey.  If you’re already a free agent or you don’t write software, don’t worry.  You can still get some info here.  I’m going to include reading materials and links, so I have something for everyone.

Defining Efficiencer

First things first.  I won’t ask you to go do a bunch of homework.  Instead, I’ll define this term again, off the cuff.  I’ve described it in the book, but I invite you all to participate alongside me in kind of an evolutionary definition of the term.

I think of software developers (or engineers or programmers or whatever) as people who collect a salary to write code.  I feel fairly confident that this definition has blown exactly 0 of your minds.  But consider it maybe a bit more literally.  You collect a salary to code… and, that’s it.

Therefore, you don’t worry about business considerations like sales or marketing.  You generally don’t participate in discussions about why you write the code that you do.  Nope, you just show up, get a spec or something, fire up your IDE, and get to work.

The efficiencer, on the other hand, does ask why.  In fact, the efficiencer doesn’t do any work without understanding and approving of the why.  You see, she doesn’t count herself a coder but an automation professional.  She specializes in making you more efficient.  That might mean writing some code, or it might just mean sending you a link to a COTS product that already does what you want.  She doesn’t accept specs or story cards or requirements or anything like that.  She listens to your business goals around cutting cost or increasing revenue, and she decides how that will happen.

Read More

« Older Posts
Newer Posts »