DaedTech

Stories about Software

By

Make Alerting Apps Work for You

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, take a look at the monitoring solutions and integrations they have to offer.

Some years back, I worked as the CIO.  During my tenure, I had a head of IT support reporting to me.  He did his job quite well and had a commendable sense of duty and responsibility, and I will always think of him as a model employee.

I recall an oddly frustrating conversation that I had with him once, however.  He struggled to explain what I needed to know, and I struggled to get him to understand the information I needed.

Long story short, he wanted me to sign off on switching data centers to a more expensive vendor.  Trouble was, this switch would have put us over budget, so I would have found myself explaining this to the CFO at the next executive meeting.  I needed something to justify the request, and that was what I sought.

I kept asking him to make a business case for the switch, and he kept talking about best practices, SLAs, uptime, and other bits of shop.  Eventually, I framed it almost as a mad lib.  If we don’t make this change, the odds of a significant outage that costs us $_____ will increase by _____%.  In that case, we stand to recoup this investment in _____ months.   In the end, he understood.  He built the business case, I took it to the executive meeting, and we made the improvements.

As much as we might like it, people in technical leadership position often cannot get into the weeds when talking shop.  If this seems off-putting, to techies, I’d say think of it this way.  Techies hack tools, code, and infrastructure, while managers and leaders hack the business.

Read More

By

The Relationship Between Team Size and Code Quality

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 NDepend and see how your code stacks up.

Over the last few years, I’ve had occasion to observe lots of software teams.  These teams come in all shapes and sizes, as the saying goes.  And, not surprisingly, they produce output that covers the entire spectrum of software quality.

It would hardly make headline news to cite team members’ collective skill level and training as a prominent factor in determining quality level.  But what else affects it?  Does team size?  Recently, I found myself pondering this during a bit of downtime ahead of a meeting.

Does some team size optimize for quality?  If so, how many people belong on a team?  This line of thinking led me to consider my own experience for examples.

A Case Study in Large Team Dysfunction

Years and years ago, I spent some time with a large team.  For its methodology, this shop unambiguously chose waterfall, though I imagine that, like many such shops, they called it “SDLC” or something like that.  But any way you slice it, requirements and design documents preceded the implementation phase.

In addition to big up front planning, the codebase had little in the way of meaningful abstractions to partition it architecturally.  As a result, you had the perfect incubator for a massive team.  The big up front planning ensured the illusion of appropriate resource allocation.  And then the tangled code base ensured that “illusion” was the best way to describe the notion that people could be assigned tasks where they didn’t severely impact one another much.

On top of all that, the entire software organization had a code review mandate for compliance purposes.  This meant that someone needed to review each line of code committed.  And, absent a better scheme, this generally meant that the longest tenured team members did the reviewing.  The same longest tenured team members that had created an architecture with no meaningful partitioning abstractions.

This cauldron of circumstances boiled up a mess.  Team members bickered over minutiae as code sprawled, rotted, and tangled.  Based solely on this experience, less is more.

Read More

By

How Much Code Should My Developers Be Responsible For?

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 see if your code manages to avoid the dreaded zone of pain.

As I work with more and more organizations, my compiled list of interesting questions grows.  Seriously – I have quite the backlog.  And I don’t mean interesting in the pejorative sense.  You know – the way you say, “oh, that’s… interesting” after some drunken family member rants about their political views.

Rather, these questions interest me at a philosophical level.  They make me wonder about things I never might have pondered.  Today, I’ll pull one out and dust it off.  A client asked me this once, a while back.  They were wondering, “how much code should my developers be responsible for?”

Why ask about this?  Well, they had a laudable enough goal.  They had a fairly hefty legacy codebase and didn’t want to overtax the folks working on it.  “We know our codebase has X lines of code, so how many developers comprise an ideally staffed team?”

In a data-driven way, they asked a great question.  And yet, the reasoning falls apart on closer inspection.  I’ll speak today about why that happens.  Here are some problems with this thinking.

Read More

By

How to Prioritize Bugs on Your To-Do List

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 around at NDepend and explore its new tech debt measurement features.

People frequently ask me questions about code quality.  People also frequently ask me questions about efficiency and productivity.  But it seems we rarely wind up talking about the two together.  How can you most efficiently improve quality via the fixing of bugs.  Or, more specifically, how should you prioritize the list of bugs that you have?

Let me be clear about something up front.  I’m not going to offer you some kind of grand unified scheme of bug prioritization.  If I tried, the attempt would come off as utterly quixotic.  Because software shops, roles, and offerings vary so widely, I cannot address every possible situation.

Instead, I will offer a few different philosophies of prioritization, leaving the execution mechanics up to you.  These should cover most common scenarios that software developers and project managers will encounter.

Maximizing Self Interest

I’ll lead with the scenario probably most common to software developers.  Stop me if this sounds familiar.  The first interaction point you have with a bug is receiving an email from Jira or TFS or Rally or whatever.  From there, you log in, read the details, and check the pre-assigned priority.  You check that because of the bug-fixing algorithm imposed on you by management: fix any priority 1 bugs, or, if you have none of those, any priority 2 bugs, and so on down the line.

In this world, bug fixing becomes a matter of looking after your own self interest.  Prioritizing your own to do list, consequently, becomes simple.  Management and the business have made the important, strategic decisions already and will evaluate you on the basis of quantity of defects fixed.  Thus you should prioritize the easiest to fix first, so that you fix as many as possible.

This may sound cynical to you, but I’m fine with that.  I have a fundamental distaste for the specialization obsession we have that separates fixing and prioritization.  Organizations that freeze technical people out of the strategic discussion of priority reap what they sow.  Robbed of the ability to act in the organization’s best interests, developers should act in their own.  Of course, I would prefer developers participate in the “how do we act in the company’s best interests” discussions.

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