DaedTech

Stories about Software

Aug
1

By

What DevOps Means for Static Analysis

Category: Language Agnostic Tags: , , | 2 Comments

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, have a look at NDepend’s static analysis offering.

For most of my career, software development has, in a very specific way, resembled mailing a letter.  You write the thing, and then you go through the standard mail piece rigmarole.  This involves putting it into an envelope, addressing the envelope, putting a stamp on, it and then walking it over to the mailbox.  From there, you stuff it into the mailbox.

At this point, you might as well have dropped the thing into some kind of rip in space-time for all you understand what comes next.  Off it goes into the ether, and you hope that it arrives at its destination through some kind of logistical magic.  So it has generally gone with software.

We design it, architect, and lovingly write it.  We package it up, test it, correct defects in it, and then we call it done.  From there, we fire it into the mailbox-black-hole of the software world: operations.  They take it and deploy it, or whatever, and then, by some magic we don’t concern ourselves about, it runs in the real world.  Or so it has generally gone.

Problems with the Traditional Approach

With the benefit of hindsight, you can probably guess the main problem with this state of affairs.  So rather than enumerate it dryly in a series of bullet points, let me offer it up in story format.

You work as an application developer in some very large enterprise.  There, you build web apps.  And you take pride in your work.  You write clean code, you maintain the unit test suite, you collaborate dutifully with QA, and you generally do your best.

In fact, this effort even extends beyond your own dev environment and into as many environment as you can see.  You run load, smoke, and integration tests in QA and sandbox environment.  And, as a whole unit, your team does everything it can to ensure the integrity of the work.  But beyond the pre-prod environment, the fate of your application becomes an utter mystery.  Some group of folks located in a different timezone take it from there.  You wish it well as it heads to production.

And then, one day, six months later, you get some incident report.  Apparently, some guy in Hungary or somewhere was doing something when somehow he get a null reference exception.  But don’t worry, here’s a brief description of what he said and a few thousand lines of some random log file.  Good luck with your repro!

Read More

Jul
31

By

From Employable Generalist to Successful Efficiencer

Category: You Asked For It Tags: , | 7 Comments

For regular followers, I bet you thought I forgot about reader question Fridays last week.  I didn’t.  Friday is a relatively low traffic day for bloggers, so I’ve decided to switch over to reader question Monday.  But, on Sunday night, I did forget about the post draft, so the first reader question Monday is actually Tuesday’s post.  I know.  I’m a little disoriented too.  But we’ll figure it out.

About a year ago, I wrote a post about niching down.  I asked readers to imagine if, instead of listing the services that they provided, housing contractors described the number of years they’d spent using their tools.  “I have 6 years of hammer, 3 years of reciprocating saw, etc.”  From that, they left it up to you to figure out if you could translate those skill into something useful, like fixing your garage door.  That’s us, in the software development world.  “Here are my experience tuples, and now I just need some kind of manager to figure out how to turn me into a useful resource.”

Given my tone, you can probably infer that I advise against this approach.  In fact, I frequently suggest specializing and figuring out how to solve business problems.  But as a few people have now pointed out via reader questions, I’ve not offered a lot in the way of advice to bridge the gap.   A reader in the Developer Hegemony Facebook group put it quite succinctly, in the parlance of my old post.

How do you translate 3 years C#, 6 years C++, etc… into “I can fix your garage”?

It’s a good question.

Read More

Jul
30

By

Choosing an Acceptance Test Framework

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

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 their monitoring solutions.

I can still remember writing my first automated tests in a professional setting.  Notice that I didn’t say unit tests, and for good reason.  At the time, some 14 years ago, I hadn’t heard of unit tests.  Instead, I simply automated the process of manually testing my software.

This may sound somewhat facile, but it actually speaks to core principles in the programming profession.  As a relatively inexperienced programmer, I understood the importance of testing my work.  I also understood the importance of automating manual, error-prone process.  And so, of my own accord, I examined and then automated my previously manual testing efforts.

Don’t get me wrong.  By doing this, I reinvented a wheel simply because I did not know of its existence.  Folks had created automated unit test frameworks for this exact purpose.  Had I known, I could have better spent my time learning and using these things.  But, in spite of the waste, I did learn something.  I learned that, under the covers, test frameworks just represented yet another instance of automating an important manual process.

What is User Acceptance Testing (UAT)?

I led with a tale about unit tests because testing software components applies to everyone that writes software.  I mean, you always test your own software, even if you don’t think you’re doing so.  Whenever you compile, you test your code to see if it compiles.  Granted, you aren’t executing the most sophisticated, high-value test known to man.  But you are performing a test of sorts.

But what if we look beyond our own dev boxes a bit?  What if we look at other forms of testing?

For almost any software that we write, other stakeholders will perform other sorts of tests.  These stakeholders includes users or user-proxies, who perform an activity known as user acceptance testing (UAT).  In its simplest incarnation, this involves users or their proxies using the software and evaluating whether or not they find it acceptable.

This can come in various shapes and sizes.  In some cases, actual users perform formalized beta tests, perhaps for pay.  In other cases, someone from the QA group might do a quick run-through and give a thumbs-up or thumbs-down.  But whatever happens, these tests capture the user’s experience and perspective.

Read More

Jul
27

By

CodeIt.Right Rules Explained, Part 4

Category: .NET Tags: , , | 4 Comments

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at CodeIt.Right to help you perform automated code reviews.  

Today, I’ll do another installment of the CodeIt.Right Rules, Explained series.  I have now made four such posts in this series.  And, as always, I’ll start off by citing my two personal rules about static analysis guidance.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More

Jul
26

By

Quality Gates with NDepend to Help You Fail Fast

Category: .NET Tags: , , |

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 Quality Gates and other NDepend features.

I had this car once.  I loved the thing, but, before the end of its life, my wife and I had developed sort of a running joke about it.  Specifically, if you wanted to see the “check engine” light come on, take the thing on a road trip.  About 100 miles in, that light would come on.

The fog of memory has probably colored this tale somewhat.  I can’t imagine that this happened before literally every driving trip we took.  But it sure seems like it did.  I can vividly recall the feeling of “something’s wrong” when we’d come too far to reasonably turn back but still had most of the trip in front of us.

Against this backdrop, the wisdom of the software aphorism, “fail fast” hits home.  Had the light come on as we sat in the driveway, about to leave, we’d have had options.  Take my wife’s car.  Go to the dealership on the way out of town to make sure we could safely drive.  Something.  But, 100 miles into the trip, those options narrowed to “just keep going and hope for the best.”

If you must fail, better to do so early.

Fail Fast with Software Builds

When I first started as a professional software developer, “the build” tended to mean something much different than now.  We’d code furiously for months or years, and then someone would blow the “code freeze” whistle.  Then, after some testing, the “build guy” would pull the latest stuff out of CVS or Visual Source Safe and work on turning it into something that could be burned on a CD and distributed.  The first inkling of possible build problems would come something like 96% of the way through the project.  Heck, at that time, we had “merge parties,” wherein merging integrating one another’s separately developed source code could take days.

This created serious risk for projects.  We had the ability to unwittingly introduce defects that would not manifest until perilously close to project release time.  Like my potentially ill-fated driving trips, a too-late warning could create unacceptable delays and logistical problems.

So we, as an industry, learned to fail faster.  We brought in the concept of continuous integration and a build machine.  At the very beginning of a project, set the thing up for regular integration and delivery to a production (like) environment.  Know quickly if you introduced something that would gum up the downstream works.

Read More

« Older Posts
Newer Posts »