DaedTech

Stories about Software

By

Are You Aggressively Trying to Automate Code Review?

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 their automated analysis and documentation tooling.

Before I talk in detail about trying to automate code review, do a mental exercise.  Close your eyes and picture the epitome of a soul-crushing code review.

You probably sit in a stuffy conference room with several other people.  With your IDE open and laptop plugged into the projector via VGA cable, you begin.  Or, rather, they begin.  After all, your shop does code review more like thesis defense than collaboration.  So the other participants commence grilling you about your code as if it oozed your incompetence from every line.

This likely goes on for hours.  No nit remains unpicked, however trivial.  You’ve even taken to keeping a spreadsheet full of things to check ahead of code reviews so as not to make the same mistake twice.  That spreadsheet now has hundreds of lines.  And some of those lines directly contradict one another.

When the criticism-a-thon ends, you feel tired, depressed, and hungry.  But, looking on the bright side, you realize that this is the furthest you’ll ever be from the next code review.

It probably sounds like I speak from experience because I do.  I’ve seen this play out in software development shops and even written a blog post about it in the past.  But let’s look past the depressing human element of this and understand how it proves bad for business.

Read More

By

Addressing Malware Detection from the Outside In

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, have a look around at the different types of production monitoring that they offer.

I worked as a software engineer for almost the entire decade of the 2000s.  While I was earning a living this way, computers were making their way from CS student dorm rooms to Grandma’s den.  Like so many other programmers of the time, I thus acquired the role of unofficial tech support for computer illiterate friends and family.  I do not miss those days in which malware detection became an involuntary hobby.

Back in 2005, everyone had computers with Windows XP or Windows 98.  And every computer with Windows XP or Windows 98 seemed to attract malware like flies to flypaper.  So I found myself sitting in front of CRT monitors next to dusty towers, figuring out why nothing worked.

I still kind of remember the playbook.  For instance, Lavasoft had a product called Ad Aware.  I also seem to recall something called MalwareBytes.  I favored these because I could download them for free.  At least, I could download them for free assuming the victim’s computer was even capable.  With those tools in place, and with a heaping helping of googling from my own laptop, I would painstakingly scan, sweep, remove, tweak, and repeat.  Eventually, I won. Usually.

It seems strange to think about now.  Ten or twelve years ago, consumers compared brands of antivirus software the way we compare music apps on our phones.  Malware detection dominated our computing consciousness, even for casual users.  But today?  I can’t remember the last time I ran an antivirus scan on my laptops.  I suspect you can’t either.  So what happened to all of this malware?  Did it simply disappear?

The Silencing of Malware

Well, no.  Malware didn’t disappear.  The criminals and spammers of the world didn’t just one day decide to do something better with their lives.  In fact, you might argue that they became more effective.

Most of the pieces of malware from my younger days had lots of bark and little bite.  They’d install themselves on your computer and hijack your browser with obnoxious graphics or spew error messages until your machine crashed.  Some came from would-be vandals, while others tried unsuccessfully to do things sneakily.

But causing some computer neophyte to say “this doesn’t seem right” and call up a young me to fix things — well, it hardly constitutes successful sneaking.  It always seemed, in those days, that malware authors sought mainly to annoy.  And malware detection and removal sought to fix the inconvenience.

In more recent years, however, the consumer annoyance factor has mostly disappeared.  Why?  Because there’s no profit in it.  Today’s malware instead aims to help its authors and users make money.  It does this by quietly gathering data, sending out spam, gaming search engines, and stealing information.  And it does all of this under the radar.

Read More

By

Automated Code Review to Help with the Unknowns of Offshore Work

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, which offers automated code review feedback.

I like variety.  In pursuit of this preference, I spend some time management consulting with enterprise clients and some time volunteering for “office hours” at a startup incubator.  Generally, this amounts to serving as “rent-a-CTO” for for startup founders in half hour blocks.  This provides me with the spice of life, I guess.

As disparate as these advice forums might seem, they often share a common theme.  Both in the impressive enterprise buildings and the startup incubator conference rooms, people ask me about offshoring application development.  To go overseas or not to go overseas?  That, quite frequently, is the question (posed to me).

I find this pretty difficult to answer absent additional information.  In any context, people asking this bake two core assumptions into their question.  What they really want to say would sound more like this.  “Will I suffer for the choice to sacrifice quality to save money?”

They assume first that cheaper offshore work means lower quality.  And then they assume that you can trade quality for cost as if adjusting the volume dial in your car.  If only life worked this simply.

What You Know When You Offshore

Before going further, let’s back up a bit.  I want to talk about what you actually know when you make the decision to pay overseas firms a lower rate to build software.  But first, let’s dispel these assumptions that nobody can really justify.

Understand something unequivocally.  You cannot simply exchange units of “quality” for currency.  If you ask me to build you a web app, and I tell you that I’ll do it for $30,000, you can’t simply say, “I’ll give you $15,000 to build one half as good.”  I mean, you could say that.  But you’d be saying something absurd, and you know it.  You can reasonably adjust cost by cutting scope, but not by assuming that “half as good” means “twice as fast.”

Also, you need to understand that “cheap overseas labor” doesn’t necessarily mean lower quality.  Frequently it does, but not always.  And, not even frequently enough that you can just bank on it.

So what do you actually know when you contract with an inexpensive, overseas provider?  Not a lot, actually.  But you do know that your partner will work with you mainly remotely, across a great deal of distance, and with significant communication obstacles.  You will not collaborate as closely with them as you would with an employee or an local vendor.

Read More

By

What Problems Do Microservices Solve?

Editorial note: I originally wrote this post for the TechTown blog.  You can check out the original here, at their site.  While you’re there, have a look at the tech courses they offer.

Do you find that certain industry buzzwords set your teeth on edge?  If so, I assure you that you have company.  Buzzwords permeate every professional space, but it seems that tech really knows how to attract them.  Internet of things.  The cloud.  Big data. DevOps.  Agile and lean.  And yes, microservices.

Because of our industry’s propensity for buzzwords, Gartner created something it calls the hype cycle.  It helps their readers and clients evaluate how much attention to pay to emergent ideas.  They can then separate vague fluff from ideas that have arrived to stay.  And let’s be honest — it’s also a funny, cathartic concept.

If you’ve tired of hearing the term microservices, I can understand that.  As of 2016, Gartner put it at the peak of inflated expectations.  This means that the term had achieved maximum saturation a year ago, and our collective fatigue will drive it into the trough of disillusionment.

And yet the concept retains value.  Once the hype fades and it makes its way toward the plateau of productivity, you’ll want to understand when, how, and why to use it.  So in a nod toward pragmatism, I’m going to talk about microservices in terms of the problems that they solve.

First, What Are Microservices?

Before going any further, let me offer a specific definition.  After all, relying on vague, hand-waving definitions is the main culprit in buzzword fatigue.  I certainly don’t want to contribute to that.

Industry thought leader Martin Fowler offers a detailed treatment of the subject.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Now, understand something.  The architectural trade-off here is nothing new.  In essence, it describes centralizing intelligence versus distributing it.  With a so-called monolith, clients have it easy.  They call the monolith, which handles all details internally.  When you distribute intelligence, on the other hand, clients have more burden to figure out how to compose calls and interactions.

The relative uniqueness of the microservices movement comes from taking that tradeoff and layering atop it delivery mechanisms and the concept of atomic business value.  Organizations touting valuable microservices architectures tend to offer them up over HTTP and providing functionality that stands neatly alone.  (I make the distinction of valuable architectures since I see a lot of shops just call whatever they happen to deliver a microservices architecture.)

For example, a company may offer a customer onboarding microservice.  It can stand alone to create new customers.  But clients of this service, internal and external, may use it to compose larger, more feature-rich pieces of functionality.

So, having defined the architectural style, let’s talk about the problems it solves.

Read More

By

Getting Started with Behavior-Driven Development

Editorial note: I originally wrote this post for the TechTown blog.  You can check it out here, at their site.  While you’re there, have a look around at the different training courses they offer.

You’ve probably heard of behavior-driven development (BDD).  However, if you’ve never practiced it, you may perceive it as one of many in a nebulous cloud of acronyms.  We have BDD, TDD, DDD, and ATDD.  All of these have a “D” standing for “driven” and another one standing for either “development” or “design.”  Apparently, we software developers really like things to drive us.

I won’t engage in a full “DD” taxonomy here, as this post concerns itself with behavior-driven development only.  But we will need to take a tour through one of these in order to understand BDD’s motivations and backstory.

Behavior-Driven Development Origins and Motivation

To understand BDD, we must first understand test-driven development (TDD).  Luckily, I wrote a recent primer on that.  To recap briefly, TDD calls for you to address every new thing you want your production code to do by first writing a failing test.  Doing this both verifies that the system currently lacks the needed functionality and gives you a way to later know that you’ve successfully implemented it.

With TDD, you deal in microtests.  These distinguish themselves by being quite specific and granular.  For instance, you might assert that you get a null reference exception when invoking a method with a null parameter.  You’ll pardon non-technical project stakeholders for a distinct lack of interest in these microtests.

BDD evolved from asking the question, “Why don’t we do this for tests that the business might care about?”  It follows the same philosophical approach and logic.  But instead of worrying about null parameters and exceptions, these tests address the system’s behavior at the capability or feature level.

Behavior-driven development follows the TDD cadence: express a current system deficiency with a failing test. But this time the failing test is, for example, when I deposit money into my checking account, I can see the reflected balance.  Work then proceeds on that feature until the test passes.  At this time, the team considers the card complete.

Read More