DaedTech

Stories about Software

Jun
11

By

Are You Ready for Zero Day Software Deployment?

Category: Language Agnostic Tags: , |

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

Jun
9

By

Freelance Software Development: Speaking to Your Buyers

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

I believe that at two, you have to call it a streak.  And so I’d like to celebrate my illustrious streak of reader question Fridays successfully delivered.  Today’s topic?  Freelance software development.

This actually follows pretty naturally from last Friday’s post.  Toward the end of that post, I pleaded with software developers to stop worrying about impressing one another.  I did this because software developers are not your buyers — they’re your peers.  Just as you don’t see Target’s CEO calling Walmart’s to show him what great deals Target has this week, you shouldn’t market toward your peers.  Instead, you should direct your marketing efforts (blog included) at your buyers.

Doesn’t This Make You a Hypocrite, Erik?

If you dig through the archives of this blog, you will find an awful lot of posts directed at software developers.  So I’ll just head off the inevitable comment about my hypocrisy with a caveat heading.

First, I treated my blog as half journal, half catharsis for a lot of years.  That is, I didn’t set out to speak to my buyers because I didn’t have any when I started, prospective or otherwise.  I wouldn’t go off on my own until I’d already been blogging for years and, at that point, I had my own pipeline pretty well stocked.  Due to preparation through other means, I never relied on this blog to keep work rolling in.  I do get inquiries and business through the site, but usually about developer training and the assumption that I can teach/setup anything I blog about.

The other thing that I’ll say in defense of me speaking to developers through the blog is that developers now are my buyers.  You can buy my recent book if you don’t believe me, or check out my other developer-oriented offerings.  Over years and years of blogging, I learned that it makes sense to offer your audience things it might value monetarily.  (I encourage you prospective bloggers to be less obtuse than me and have this figured out from day one.)

So, yes, I speak to software developers on this blog and always have.  But I don’t do it in the hopes that someone will notice it and hire me to do custom app dev.

Onto the Reader Question(s)

Now that we have that out of the way, let’s move on to the reader question(s) that pertain to freelance software development.  Usually, I try to do a FIFO scheme, but I actually received more than one variant of the same question after last week’s post.  I figure that bumps it to the top of the list.  So here’s a composite of that question.

Do you have any tips on how to write for buyers, rather than fellow developers?  My interests (and my prospective freelancing) run heavily technical, and that’s what I know how to talk about.  So how do you recommend that I speak to buyers through the blog?

Short answer is, sure, I absolutely have tips for that.  And I’ll get to topic ideas in a bit.  But first, let’s get both a little blunt and a little philosophical, so that you understand what you’re up against.

Read More

Jun
7

By

Adding Static Analysis to Your Team’s DNA

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, download NDepend and play with adding it to your team’s build.

Stop me if this sounds familiar.  (Well, not literally.  I realize that asynchronous publication makes it hard for you to actually stop me as I type.  Indulge me the figure of speech.)  You work on a codebase for a long time, all the while having the foreboding sense of growing messiness.  One day, perhaps when you have a bit of extra time, you download a static analyzer to tell you “how bad.”

Then you have an experience like a holiday-time binge eater getting on a scale on January 1st.  As the tool crunches its results, you wince in anticipation.  Next, you get the results, get depressed, and then get busy correcting them.  Unlike shedding those holiday pounds, you can often fix the most egregious errors in your codebase in a matter of days.  So you make those fixes, pat yourself on the back, and forget all about the static analyzer, perhaps letting your trial expire or leaving it to sit on the shelf.

If you’re wondering how I got in your head, consider that I see this pattern in client shops frequently.  They regard static analysis as a one time cleanup effort, to be implemented as a small project every now and then.  Then, they resolve to carry the learning forward to avoid making similar mistakes.  But, in a vacuum, they rarely do.

A Better Course of Action: Incorporate the Tool

For the remainder of the post, I’ll refer to NDepend, both because of my familiarity with it and because it seems entirely appropriate for the NDepend blog.  But the principles here could apply to many static analyzers or other types of tools.

Simply put, you should not forget the tool.  On the contrary, you should expand your relationship with it.  You should add it to your build and to your process as a developer.

This approach requires very little effort.  At a bare minimum, you can modify your build to generate a report and run the tool prior to each commit.  Doing this tightly integrates code quality and trends into your development process.  They become constant fixtures, rather than periodic, one-off projects.

But that covers the “how” and not so much the “why.”  Let’s address that in the remainder of the post.  What benefits do you realize from using NDepend on a continuous basis?

Read More

Jun
7

By

Characteristics of Good APIs

Category: Language Agnostic Tags: , | 8 Comments

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.

The term “API” seems to present something of a Rorschach Test for software developers.  Web developers think of APIs as REST endpoints and WSDLs.   In contrast, desktop developers may think of APIs as “library code” written by developers from other organizations.  Folks writing low level code like drivers?  API provides the hooks into OS system calls (emphasis mine).

I understand this mild myopia that can happen, but the bigger picture matters.  API offers a much more generic way of thinking.  I personally like the definition from “tech terms.”

An API is a set of commands, functions, protocols, and objects that programmers can use to create software or interact with an external system. It provides developers with standard commands for performing common operations so they do not have to write the code from scratch.

An API defines how other programmers interact with your software.  Thus each of the personas I mentioned have the right answer, but a small slice of it.  As you write code, ask yourself about the user of that code.  If that user interacts with your code via code of their own, you’re building an API.  And before you ask, yes, that even applies to other developers in your company or even your team that use your code.

Consequently, understanding properties of good APIs carries vital importance for our industry.  It makes the difference between others building on your work or avoiding it.  And, let’s be honest — there’s a certain amount of professional pride at stake.  So what makes APIs good?  Let’s consider some characteristics of good APIs.

Read More

Jun
5

By

Recovering from a Mission Critical Whiff

Category: The Life of a Programmer 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, 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

« Older Posts
Newer Posts »