DaedTech

Stories about Software

Aug
25

By

How to Actually Reduce Software Defects

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

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Have a look around while you’re there and see what some of the other authors have written.

As an IT management consultant, probably the most frequent question I hear is some variant of “how can we get our defect count down?” Developers may want this as a matter of professional pride, but it’s the managers and project managers that truly burn to improve on this metric. Our software does thousands of undesirable things in production, and we’d like to get that down to hundreds.

Fumigation

Almost invariably, they’re looking for a percentage reduction, presumably because there is some sort of performance incentive based on the defect count metric. And so they want strategies for reducing defects by some percentage, in the same way that the president of the United States might challenge his cabinet to trim 2% of the unemployment percentage in the coming years. The trouble is, though, that this attitude toward defects is actually part of the problem.

The Right Attitude toward Defects

The president sets a goal of reducing unemployment, but not of eliminating it. Why is that? Well, because having nobody in the country unemployed is simply impossible outside of a planned economy – people will quit and take time off between jobs or get laid off and have to spend time searching for new ones. Some unemployment is inevitable.

Management, particularly in traditional, ‘waterfall’ shops, tends to view defects in the same light. We clearly can’t avoid defects, but if we worked really hard, we could reduce them by half. This attitude is a core part of the problem.

It’s often met with initial skepticism, but what I tell these clients is that they should shoot for having no escaped defects (defects that make it to production, as opposed to ones that are caught by the team during testing). In other words, don’t shoot for a 20% or 50% reduction – shoot for not having defects.

It’s not that shooting for 100% will stretch teams further than shooting for 20% or 50%. There’s no psychological gimmickry to it. Instead, it’s about ceasing to view defects as “just part of writing software.” Defects are not inevitable, and coming to view them as preventable mistakes rather than facts of life is important because it leads to a reaction of “oh, wow, a defect – that’s bad, let’s figure out how that happened and fix it” instead of a reaction of “yeah, defects, what are you gonna do?”

When teams realize and accept this, they turn an important corner on the road to defect reduction.

Read More

Jul
31

By

The Human Cost of Tech Debt

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

Editorial Note: I originally wrote this post for the Infragistics blog.  Head over to their site and check out the original.  While you’re there, have a look at the other blog authors and their product offering.

If you’re not already familiar with the concept of technical debt, it’s worth becoming familiar with it.  I say this not only because it is a common industry term, but because it is an important concept.

Coined by Ward Cunningham, the term introduces the idea that taking shortcuts in your software today not only means paying the price eventually — it means paying that price with interest.  In other words, introducing that global variable today and saving half a day’s work ahead of shipping means that you’re going to pay for it with more than half a day’s labor down the line.

Man holding heavy chest

The Power of the Metaphor

I’ve spent significant time doing IT management consulting in recent years, after spending years and years writing code.  And I can tell you that this metaphor for shortcuts in the codebase is a powerful one when it comes to communication between the business and the software development group.  When you explain software decisions to managers and MBAs using the language of economics, they get it.

Because of the metaphor’s power and subsequent effectiveness for business concerns, it is often used to describe the health of projects, particularly vis a vis deadlines and milestones.  The developers may communicate that an aggressive deadline will result in technical debt, making features in the future take longer to ship.  Analysts and project managers might account for technical debt when discussing slipped deadlines.  IT upper management might ask for an assessment of the amount of technical in an application when making a strategic, replace/retire/rewrite decision.

The problem of technical debt is for most people, in essence, a problem of time to market.

But I’d like to talk today about the human side of the problem.  And, make no mistake — in business, all human problems are also business problems,viewed with a wide enough lens.  Unhappy humans are unhappy workers, and unhappy workers are less productive.  Yet, this angle of technical debt is seldom discussed, in my experience.

Read More

Jul
27

By

The Business-Personal Value Continuum

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

While out on a jog recently, I found myself listening to an episode of .NET Rocks, in which the discussion covered the surprising percentage of developers still using Winforms and the general topic of using licensed controls written by third parties.  This started a train of thought in my head that might end in mild controversy, but I think it’s worth exploring a bit.

Two profiles (well, more like caricatures) of developer came to mind, standing in stark contrast to one another.  First is this Winforms developer that is more or less cobbling together spare parts to build applications. He uses a WYSIWYG editor, employs some kind of “database form wizard” to bind a GUI widget directly to a table, plops a slew of obscure third party controls into the code, and ships some kind of Franken-app not actually involving much code.  The second profile rounds out the dichotomy and consists of the foundational crafter.  This person builds her own tools and controls using low level language constructs and the command line, and assembles these works of art into ever-higher layers of abstraction until shipping a hand-crafted app.

If I’m running a business, give me the first person.

Undoubtedly, the crafter harbors a better, more fundamental grasp of the principles of computer science, and she undoubtedly offers the most versatility.  If she can build a compiler, use that to build a text editor, use that to build a source control system, use that to build a web server, and use that to build the sexiest, popping-ist, UX-friendliest website you’ve ever seen, she is the most employable, most full stackable programmer ever.  The business will never encounter a situation beyond her grasp.  But who cares, if the business just needs a checkbox added to a battleship gray, outdated Windows application?

Female Artist

I practice test driven development.  I rail against the evils of copy and paste programming.  I counsel clients on the dangers of technical debt and feature slow down.  I advocate wholesale for clean code.  And because of all these things, I understand that every single line of code you write is an incremental business liability.  So why would I take the cobbler over the crafter?  Don’t get me wrong — if I had to pick one of the two of them to write a given module, I would take the crafter.  But for approach, I would take the cobbler because the cobbler makes most of the code someone else’s problem while the crafter makes it all my problem.

What I really want is someone with the chops of a crafter and the reluctance to write more code than necessary of a cobbler.

Read More

Jul
13

By

How Collaboration Humanizes the Enterprise

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

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original, here, at their site.  While you’re there, take a look at their product offering and blog posts by their various authors.

I’ve spent enough time walking the halls of large-ish to massive organizations to have formed some opinions and made some observations. If I had to characterize the motor that drives these beasts, I’d say it is comprised of two main components: intense risk aversion and an obsession with waste elimination that sits somewhere on a spectrum between neurotic and quixotic.

Battleship

Let me explain.

Large organizations all started as small organizations, and all of them survived organizational accretion, besting competitors, dodging bad breaks, and successfully scaling to the point where they have a whole lot to lose. It is this last concern that drives the risk aversion; upstarts are constantly trying to unseat them and rent-seekers trying to sue them because they’re sitting on a pretty nice pot of gold. It is the scaling that motivates the waste elimination. Nothing scales perfectly and few things scale well, so organizations have to become insanely efficient in a number of ways to combat the natural downturns in efficiency caused by scale.

Risk Minimizing and Process Efficiency

With risk minimizing and waste elimination as near-universal goals, organizations tend to do some fairly predictable and recognizable things. Risk elimination takes the form of checks and balances, with pockets of “need to know” being created to isolate problems. For instance, a “security compliance” group may be created to review work product independently from the people producing the work, and it may even go so far as to seek outside certification. This sort of orthogonality and redundancy make it less likely the organization will be sued or compromised.

Unfortunately, though, redundancy exacerbates the other struggle, which is to eliminate waste in the name of efficiency. It’s not exactly efficient to have two separate groups spend time going over the same product and doing the same things, but with slightly altered focus. The organization compensates for this with hyper-specialty and process.

Read More

Jun
30

By

Does Github Enhance the Need for Code Review?

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

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Take a look around while you’re there and check out their products and other posts.

In 1999, a man named Eric S. Raymond published a book called, “The Cathedral and the Bazaar.”  In this book, he introduced a pithy phrase, “given enough eyeballs, all bugs are shallow,” that he named Linus’ Law after Linux creator Linus Torvalds.  Raymond was calling out a dichotomy that existed in the software world of the 1990s, and he was throwing his lot in with the heavy underdog at the time, the bazaar.  That dichotomy still exists today, after a fashion, but Raymond and his bazaar are no longer underdogs.  They are decisive victors, thanks in no small part to a website called Github.  And the only people still duking it out in this battle are those who have yet to look up and realize that it’s over and they have lost.

Cathedral

Cathedrals and Bazaars in the 1990s

Raymond’s cathedral was heavily-planned, jealously-guarded, proprietary software.  In the 1990s, this was virtually synonymous with Microsoft, but certainly included large software companies, relational database vendors, shrink-wrap software makers, and just about anyone doing it for profit.  There was a centrally created architecture and it was executed in top down fashion by all of the developer cogs in the for-profit machine.  The software would ship maybe every year, and in the run up to that time, the comparably few developers with access to the source code would hunt down as many bugs as they could ahead of shipping.  Users would then find the rest, and they’d wait until the next yearly release to see fixes (or, maybe, they’d see a patch after some months).  The name, “cathedral” refers to the irreducible nature of a medieval cathedral — everything is intricately crafted in all or nothing fashion before the public is admitted.

The bazaar, on the other hand, was open source software, represented largely at the time by Linux and Apache.  The source code for these projects was, obviously, free to all to look at and modify over the nascent internet.  Releases there happened frequently and the work was crowd-sourced as much as possible.  When bugs were found following a release, the users could and did hunt them down, fix them, and push the fix back to the main branch of the source code very quickly.  The cycle time between discovery and correction was much, much smaller.  This model was called the bazaar because of the comparably bustling, freewheeling nature of the cooperation; it resembled a loud, spontaneously organized marketplace that was surprisingly effective for regulating commerce.

Read More

« Older Posts
Newer Posts »