Zero Day: A Review

Geek Thrillers are hard to come by.  The last such thriller I can remember was the Cuckoo’s Egg, a novel that focuses on the nitty gritty of tracking down a hacker in the pre-WWW days.

Zero Day is a novel about a security consultant that is hired to fix the damage a virus has caused; and during this time the virus causes havoc with other computer systems as it propagates through the internet, resulting in the deaths of civilians in many walks of life: Hospital patients, nuclear power engineers, Automobile factory workers, Ships running aground, and airplanes in flight.  The virus turns out to be more sinister than first thought; and it’s a race against the clock to figure out who made it and how to stop it.

Zero Day is written as if it’s going to be turned into a movie. There isn’t a lot of backstory or internal thinking; most of the action happens ‘on the screen’, where it would be relatively simple to turn it into a movie. It’s extremely well written, and there were times that I couldn’t put it down and if I did I’d just pick it up again.  It delves into the worst-case scenario and shows just how plausible it is.  

Mark draws on his real-world experience as a Security researcher at Microsoft to bring the plausible nature of Zero Day to life.  The tools used in Zero Day mirror real-world applications; but unfortunately he doesn’t take it to the depths that followers of his blog might expect.  As a programmer I hoped for more technical information about the virus or the tools used to track it down; but the author chose to forgo that to entice a larger audience.  

If you’re expecting a thriller that goes into the depth that Cuckoo’s Egg did, you’ll be sorely disappointed. If however, you’re expecting an exciting adventure that keeps you hooked until the last page, give Zero Day a read, or five.

A Code Sample is worth Ten References

Stack Overflow recently announced that they will start linking a user’s Careers account to their GitHub account. As the reason for this addition, they quote John Resig, the founder of JQuery:

When it comes to hiring, I’ll take a Github commit log over a resume any day.

I have to agree with him, and I’ll go even further: a code sample (commit log) is worth ten references.  The great thing about GitHub is that it’s a giant code-sample. Any developer on the internet can download your code, inspect it, and find the good and the bad instantaneously. Not only that, but they can view how often you commit, where your code has grown, and your interactions with the wider community as a whole.  That makes Github the perfect companion to your Stack Overflow profile (You have one of those, right? RIGHT?)

References, on the other hand, can be bought with a beer and good networking. I’ve had people come with references galore, but they couldn’t even code Fizzbuzz. I’ve never had a candidate with a good code sample turn into a bad employee. Github takes care of code sample problem writ large.

If you have a personal project and it isn’t a money-making venture, why not commit it to Github?


Image courtesy

Lent is a yearly Catholic Tradition that involves sacrifice, penance and generally a lot of guilt (When you’re Catholic, what *doesn’t* involve guilt?).  Last year, as Lent approached far more rapidly than I would have liked, I panicked because I had no idea what to ‘give up’ for Lent.  As Catholics, we generally ‘give something up’ that is near and dear to us, as a measure of sacrifice.  One year I gave up being nice; although in hindsight that wasn’t a very good idea.  

So for lent last year, I gave up caffeine.  That miracle drug that enables programmers to leap tall buildings in a single bound or to write reams of code in no time at all.  The same caffeine that is in just about every soda known to man. I gave it up.

I guess if you don’t consume caffeine at the rate I did, this isn’t a shock. It’s just caffeine.  It stops being ‘just caffeine’ when you consume upwards of 2 liters per day of the stuff. I’d have a soda in the morning, then a coffee, then another soda for lunch, then a soda and coffee in the mid afternoon.  I’d have soda with dinner and one or two sodas after dinner. My energy levels also fluctuated with the amount of caffeine I had. If I had caffeine in me, I was energetic, but the second it wore off I’d almost fall asleep (I drank sugar free soda, so it wasn’t a sugar crash).  Headaches were common when I went more than a few hours without caffeine, and I was generally irritable without it.

So I gave it up.

For the next 30 days, my life was a living hell.  Advil every 6 hours, lots of water, and irritableness as I came off of the caffeine.  After that, something strange happened: I was no longer tired at work, nor did I have a problem going to bed at night. I no longer got headaches, and my moods were mellower without caffeine.

A year later, I still don’t consume caffeine. If I feel the craving for a soda, I’ll buy a caffeine free diet drink (though there’s talk that even that’s ‘bad for you’); and at home I make Decaffeinated Iced-tea with Splenda.  If I have guests over, I’ll make them coffee (my mom would probably kill me if I didn’t have coffee for when she came to visit!), but otherwise I keep very little caffeine in the house.  At restaurants, where caffeinated sodas are the norm, I’ll either have water or a beer.

Caffeine changed my life: And being without caffeine has made my life immeasurably better. It may not be for everyone, but for me, it was worth it.


The First Step to Agile is Feedback

Implementing Agile in Microsoft Project

Image Courtesy: The Daily WTF

A little over a year ago I became the team lead for a software team in a company that specialized in government contracting, and in particular the US Army.  The company had been awarded “CMMI Level 3” compliance, and that was good enough for the government; but unfortunately CMMI doesn’t mean good software. It just means a reliable process was involved, even if it’s a crappy process.

Before I took over as Dev lead, our development cycles were 3 months from prioritization to delivery, with the product being a .NET 2.0 Winforms client.  We spent a lot of time responding to customer requests (aka putting out fires), and when we weren’t doing that, we were planning. Lots and lots of planning.  Planning is almost a pastime in government contracting.  The planning also fails, consistently.  Plan for 3 months away and in a month we found out that everything we had planned for had changed. 

You probably know where this is heading.  I started to institute agile within my team. Our meetings had been weekly meetings that lasted two hours and included people from other teams who were not acting in a supervisory role but were supervising. They included minutes, and they included the on-site customer rep taking every little thing we talked about back to his hierarchy.  In short, they were useless.  Those meetings were the first to go; and in their place was the daily standup. 15 minutes, 3 questions and we were done. I built a virtual kanban board that pulled the data from our bug repository, and we used that to keep track of where everything was at for the release.  Having no formal agile experience, I didn’t know where else to go from there.  The rest of our organization (1 other dev team, plus a QA team and System Engineering team) were still under the previous constraints, and because of the pain of our release cycle, there was no way we’d release code faster than every 3 months… unless we changed the rules.

Change the rules I did. I found a way to be able to update the clients without new installs (Click Once was a no-go, due to customer ‘concerns about security’) in RemoteApp, and it also alleviated the load pain we were feeling (due to complex object graphs serializing using .NET Remoting).  So I started to push for this upgrade; knowing it would pave the way for us to be able to shorten our feedback loop from the time we found out about a problem until we were able to release a fix for it.  It also meant we’d be able to deploy features much faster and get feedback on them much faster.

In the meantime, the project suffered from the same problems it had before: poor communication through ‘official channels’,  feedback not being given or received in a timely fashion, and features the users didn’t want or need. In the end, we didn’t communicate enough to the customer about all of the ways to improve the software or the problems with the approach we chose. We failed to communicate, and we   For all my efforts, I failed to make the project better.

I failed because I didn’t put the feedback first.  Agile is first about feedback. It’s about that communication loop between the people that use the software and the people that create it.  Before the technology, before the kanban board, and before anything else, the communication has to be fixed first.

We didn’t have communication across teams: Our teams were silo’d so that only the QA lead would talk to QA guys, the Sys-Engineering lead to the System engineering guys, and the other Dev lead to his team. I even exhibited “Don’t fuck with my territory” behavior. We were scared, we were defensive, and we didn’t knock down the walls that keep that feedback loop from happening.

The easiest thing to do is to improve feedback. Improve feedback by cutting the planning the release cycle, improve feedback by mixing the teams. Improve feedback by shuffling management around, or abolish it completely. Get rid of anything that hinders actual honest-to-god communication. That includes punishing people when they do speak up. Punish people when they’re disrespectful, not when they’re vocal.

Looking back on the many failures in that project, feedback was the worst, and it was also the easiest to fix.

Agile fixes communication in multiple ways, the first is that it requires cross-functional teams. A team in the Agile world is made up of the customer, the developers, QA, the scrum master, and any other business representative that has a stake in the process.  Secondly, Agile mandates constant communication to the customer and to the rest of the team about the state of the project.  It improves feedback by limiting the scope of work to what can be delivered in two weeks.  The most a team can ever be behind what the end-user wants is two weeks, instead of the three months we were previously. It also does away with those fiefdoms that crop up in silo’d organizations.  It may not be the answer, but it is a better answer than the status quo.

Little Gems: ToShortDate Extension Method

I’m really surprised that the DateTime struct doesn’t have a way to compare if two dates are equal, disregarding the time.  To help that, I’ve created an extension method:


public static class DateTimeExtensions
	public static DateTime ToShortDate(this DateTime dateTime)
		return new DateTime(dateTime.Year, dateTime.Month, dateTime.Day);


With this you can compare dates without worrying about the time they were posted, which is useful when you want to group items into blocks of days.

Have a better way? Share it in the comments.

Update:  That didn’t take long. In the comments, Andy West points out that Stack Overflow has a question on this very subject: How do I compare dates in C#? Time for me to do some reverting.