DaedTech

Stories about Software

By

Recovering from a Mission Critical Whiff

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.

A career in software produces a handful of truly iconic moments.  First, you beam with pride the first time something you wrote works in production.  Then, you recoil in horror the first time you bring your team’s project to a screeching halt with a broken build or some sort of obliteration of the day’s source history.  And so it goes at the individual level.

But so it also goes at the team or department level, with diluted individual responsibility and higher stakes.  Everyone enjoys that first major launch party.  And, on the flip side, everyone shudders to recall their first death march.  But perhaps no moment produces as many hangdog looks and feelings as the collective, mission critical whiff.

I bet you can picture it.  Your group starts charging at an aggressive deadline, convinced you’ll get there.  The program or company has its skeptics, and you fall behind schedule, but you resolve to prove them wrong.  External stakes run high, but somehow your collective pride trumps even that.  At various points during the project, stakeholders offer a reprieve in the form of extensions, but you assure them you get there.

It requires a lot of nights and weekends, and even some all nighters in the run up to launch.  But somehow, you get there.  You ship your project with an exhausted feeling of pride.

And then all hell breaks loose.

Major bugs stream in.  The technical debt you knew you’d piled up comes due.  Customers get irate and laugh sardonically at the new shipment.  And, up and down the organizational ladder, people fume.  Uh oh.

How do you handle this?  What can you learn?

Read More

By

The Most Commonly Reinvented Wheels in Software

Editorial note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, take a look at their developer tools and controls offerings — they’re quite extensive.

If you ever want to set off a heated argument among software developers, you could do worse than to ask about “build vs buy.”  This one touches the third rail to such an extent that it has many colloquial names attached to it.

If you want to see this debate in action, plenty of venues exist.  Developers may accuse one another of reinventing the wheel, only to hear that some wheels need reinventing for various reasons.  Opponents of the practice have even described it as a syndrome, called “not invented here syndrome.”  But I have also seen proponents turn the tables and call out “not ever invented here syndrome” to describe software shops that awkwardly buy when building makes more sense.

Suffice it to say opinions abound and no clear consensus exists.  The highly context-specific nature of a given example also muddies the waters.  What makes sense for your team in your situation may not apply to another team.

I’ve offered thoughts on navigating this issue in another post.  Today, I’d like to avoid controversy.  I won’t weigh in on whether reinventing wheels makes sense because it deepens your knowledge or whether it wastes time and money.  Instead, I’m just going to catalog the most frequent examples I see of wheel reinvention.  As a consultant that specializes in assessing codebases and application portfolios, I see a lot of code.  This gives me a bird’s eye view of what shops love to write themselves.

Read More

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