DaedTech

Stories about Software

By

How to Write Test Cases

Editorial note: I originally this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, check out Stackify’s APM offering.

As I’ve mentioned before on this blog, I have a good bit of experience writing unit tests.  In fact, I’ve managed to parlay this experience into a nice chunk of my living.  This includes consulting, training developers, building courses, and writing books.  From this evidence, one might conclude that unit testing is in demand.

Because of the demand and driving interest, I find myself at many companies, explaining the particulars of testing to many different people.  We’d like some of testing magic here, please.  Help us boost our quality.

A great deal of earnest interest in the topic lays the groundwork for improvement.  But it also lays the groundwork for confusion.  When large groups of people set out to learn new things, buzzwords can get tossed around and meaning lost.

Against this backdrop, I can recall several different people at asking, “how should we/our people write good test cases?”  If you’re familiar with the terms at play more precisely, you might scratch your head at this question given my unit testing expertise.  A company brought me in to teach developers to write automated unit testing and someone is asking me a term loosely associated the QA group.  What gives?

But in fact, this really just begs the question, “what is a test case?”  And why might it vary depending on who writes it and how?

Read More

By

Choosing Among Text Editors and IDEs

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 offerings for monitoring all of your production concerns and infrastructure.

Few subjects in programming can get as contentious as quickly as, “what should I use to edit my code?”  Before you even get to the subject of “which one,” vigorous debates emerge over “what kind?”  This cordial Quora question with roughly 6 billion answers serves as an example of this.  Text editor or Integrated Development Environment (IDE)?

Only after that perilous decision do you arrive at the “which one debate.”  So furious has this debate proved that Wikpedia has an “Editor War” entry.  It describes the choice between the Emacs and VI editors.  The usage of “war” is a joke.  But only kind of.

So against this backdrop, you might regard the choice as one fraught with peril.  Pick incorrectly and risk the scorn of your peers.  That’s a joke.  But only kind of.

Fortunately, for the purposes of guidance, at least, I count myself a pragmatist mercenary.  In other words, I come from the relatively small camp of software developers without much strong preference about any of it.  I have spent years with each of the following: Visual Studio, Eclipse, IntelliJ, Emacs, Pico, Nano, Scite, SublimeText and Notepad++.  And I’m probably forgetting some.  All have their perks and foibles, but I prefer to keep my options open and let context guide me.

So, face with the need to pick new tooling, how should you handle it?  Today, I’ll offer some advice on heuristics for selecting an IDE or text editor.

Make a Quick List of Your Needs

First things first.  Do what you would do when contemplating any sort of consumer decision.  Make a list of your needs and wants.

For instance, say you were buying a refrigerator.  You’d need a certain size to fit your space, and you’d need a certain amount of storage capacity.  You might then want a chrome finish and an ice maker.  Contemplate the tool you’ll use for writing code in this same fashion, for starters.  You may have non-negotiable needs around operating system and programming language, and more fluid wants around features.

But also bear in mind context.  For example, do you specifically need a tool to work on one specific project at the office?  Or do you want something versatile that you’ll use everywhere, across various languages and technologies?

Now, combine these two lines of thinking and you will probably have narrowed the field considerably.  And you need to narrow the field, since a surprisingly daunting number of options exist out there.  Easier to choose among 2 or 3 than from hundreds.

Read More

By

Automation and the Art of Software Maintenance

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, check out CodeIt.Right for automating your code review process.

I have long since cast my lot with the software industry.  But, if I were going to make a commercial to convince others to follow suit, I can imagine what it would look like.  I’d probably feature cool-looking, clear whiteboards, engaged people, and frenetic design of the future.  And a robot or two.  Come help us build the technology of tomorrow.

Of course, you might later accuse me of bait and switch.  You entered a bootcamp, ready to build the technology of tomorrow.  Three years later, you found yourself on safari in a legacy code jungle, trying to wrangle some Sharepoint plugin.  Erik, you lied to me.

So, let me inoculate myself against that particular accusation.  With a career in software, you will certainly get to work on some cool things.  But you will also find yourself doing the decidedly less glamorous task of software maintenance.  You may as well prepare yourself for that now.

The Conceptual Difference: Build vs Maintain

From the software developer’s perspective, this distinction might evoke various contrasts.  Fun versus boring.  Satisfying versus annoying.  New problem versus solved problem.  My stuff versus that of some guy named Steve that apparently worked here 8 years ago.  You get the idea.

But let’s zoom out a bit.  For a broader perspective, consider the difference as it pertains to a business.

Build mode (green field) means a push toward new capability.  Usually, the business will regard construction of this capability as a project with a calculated return on investment (ROI).  To put it more plainly, “we’re going to spend $500,000 building this thing that we expect to make/save us $1.5 million by next year.”

Maintenance mode, on the other hand, presents the business with a cost center.  They’ve now made their investment and (at least partially) realized return on it.  The maintenance team just hangs around to prevent backslides.  For instance, should maintenance problems crop up, you may lose customers or efficiency.

Read More

By

Are You Ready for Zero Day Software Deployment?

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, take a look at CodeIt.Right and its automated code review capabilities.

As a teenager, I remember having a passing interest in hacking.  Perhaps this came from watching the movie Sneakers.  Whatever the origin, the fancy passed quickly because I prefer building stuff to breaking other people’s stuff.  Therefore, what I know about hacking pretty much stops at understanding terminology and high level concepts.

Consider the term “zero day exploit,” for instance.  While I understand what this means, I have never once, in my life, sat on discovery of a software vulnerability for the purpose of using it somehow.  Usually when I discover a bug, I’m trying to deposit a check or something, and I care only about the inconvenience.  But I still understand the term.

“Zero day” refers to the amount of time the software vendor has to prepare for the vulnerability.  You see, the clever hacker gives no warning about the vulnerability before using it.  (This seems like common sense, though perhaps hackers with more derring do like to give them half a day to watch them scramble to release something before the hack takes effect.)  The time between announcement and reality is zero.

Increased Deployment Cadence

Let’s co-opt the term “zero day” for a different purpose.  Imagine that we now use it to refer to software deployments.  By “zero day deployment,” we thus mean “software deployed without any prior announcement.”

But why would anyone do this?  Don’t you miss out on some great marketing opportunities?  And, more importantly, can you even release software this quickly?  Understanding comes from realizing that software deployment is undergoing a radical shift.

To understand this think about software release cadences 20 years ago.  In the 90s, Internet Explorer won the first browser war because it managed to beat Netscape’s plodding release of going 3 years between releases.  With major software products, release cadences of a year or two dominated the landscape back then.

But that timeline has shrunk steadily.  For a highly visible example, consider Visual Studio.  In 2002, 2005, 2008, Microsoft released versions corresponding to those years.  Then it started to shrink with 2010, 2012, and 2013.  Now, the years no longer mark releases, per se, with Microsoft actually releasing major updates on a quarterly basis.

Zero Day Deployments

As much as going from “every 3 years” to “every 3 months” impresses, websites and SaaS vendors have shrunk it to “every day.”  Consider Facebook’s deployment cadence.  They roll minor updates every business day and major ones every week.

With this cadence, we truly reach zero day deployment.  You never hear Facebook announcing major upcoming releases.  In fact, you never hear Facebook announcing releases, period.  The first the world sees of a given Facebook release is when the release actually happens.  Truly, this means zero day releases.

Oh, don’t get me wrong.  Rumors of upcoming features and capabilities circulate, and Facebook certainly has a robust marketing department.  But Facebook and companies with similar deployment approaches have impressively made deployments a non-event.  And others are looking to follow suit, perhaps yours included.

Read More

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