How I got An Army Medal for Programming in VBA

I read a story on Hacker News a few days ago about an individual who received an Army Commendation Medal for programming, and thought I’d share mine. 

During start of Operation Iraqi Freedom, lots of National Guard and Reservists were placed on Active Duty orders to deploy to Iraq.  In October of 2003, I received a set of orders to do just that, along with the rest of my National Guard brigade.  After four months of training, to include NTC and JRTC, we deployed to Iraq.  After a brief stint in country, I found myself returning to the States for medical reasons.  

When I arrived back at Fort Bragg, I was a part of what was then known as a Medical Holdover Unit, or “MedHold” for short.

There’s a hierarchy in the Active Army.  First it’s SFOD-D (“Delta”), then SF, then Rangers, then Airborne and Air Assault, then the line units, and then the Combat support units, then the support units, then the garrison units, then the TRADOC units, and then, after all that, the Medical Holdover units.  

It is quite literally the lowest of the low to the rest of the Army.  If you can’t fight, you can’t be a soldier, and if you can’t be a soldier, then you’re just getting a paycheck.  

During my first few months at the MedHold unit (at that point re-aligned to be a part of the Garrison, and rebranded as the “Medical Retention Processing Unit”), I witnessed hundreds of National Guard and Reserve soldiers coming back to be placed in Medhold status (we were segregated into different units from the Active Duty soldiers for administrative reasons).  Some were combat wounded, but for the most part, they were returned because they should have never been deployed in the first place (due to medical issues).

Very quickly, the size of the unit increased from 150 to around 450 or so.  At this point, I was recuperating from the first of two knee surgeries, and because of my computer skills, was placed in the S-1 shop (The Administrative section, responsible for inprocessing, outprocessing, and handling the administrative issues for these 450 soldiers).

One of the first things I noticed is that the entire database that held all the administrative information about these soldiers was kept in an Access Database.  Moreso, it was kept in one large table. There were no backups, no disaster recovery, nothing — just one Access database shared by 6 people. Luckily we’d be able to re-type in everything from paper records — but even so it is a scary thought.

This Access database was not only used for CRUD operations; but also for reporting to the various commands that wanted to know what was going on.  At this time there was a lot of scrutiny placed on MedHold soldiers, and that timely reporting important.

One E-6’s job on a Monday was to gather together that morning’s strength report, compare it with the previous week, and send a tally to 1st Army that included all relevant information about the size of our unit; and the number of soldiers in each status (inprocessing, under care, going through the Medical Review Board Process, Outprocessing, or discharged)

It took him an entire day to compile this information.

The S-1 shop went on like this for some time; and then one day we were assigned an Administrative NCO, someone whose MOS was actually Administrative in nature (42A, IIRC) and he was able to help us get on the right track and do things the way a “real” S-1 shop would.

But that report still took an entire day to do.  

One of his first assignments to me was to figure out what was taking so long to do that report and to find a way to make it faster.

Using VBA and Access Forms, I was able to create a form that made it dead simple for me to correlate daily strength with weekly changes and trends, and use that to output a Crystal Report  (I think it was crystal reports; it could have been Access’s own internal Reporting utility) that compiled this information.  The time to compile that report went from a whole day to about 15 minutes, all told.

And that’s the interesting part of how I received my Army Commendation medal.

Advertisements

How to be a Productive Programmer

A few months ago, I wrote about How to Destroy Programmer Productivity.  Since then, I’ve had people ask me how to be productive.

There’s no One Weird Trick! to being productive, and anyone who says there is is selling you something.  What makes you productive may not make me productive, and vice versa.

I rail against open floor plans, but that’s because they make an easy foil. I’ve never met a programmer who thought they were good for getting actual programming done, and I’ve never met a business person who thought they were bad for business.  If anything, when a company goes to an open floor plan, there’s almost a cultish reverence of it, complete with tours and media opportunities (never mind the documented negative effects it has on productivity).  See? There I go again.

Open Floor Plans are just like everything else on that list: They’re a vehicle for distraction. Distraction is easy; concentration is hard. As many times as not, I’m not productive because of me, because of something I’ve let distract me.

It may seem tautological, but:

Remove anything that distracts you, and you’ll be productive. If you’re lucky

 

Don’t Trust the Cloud

If someone hacked your Cloud account, could they knock you out of business?

For the company CodeSpaces, the answer was a resounding yes:

The beginning of the end was a DDoS attack initiated yesterday that was accompanied by an intrusion into Code Spaces’ Amazon EC2 control panel. Extortion demands were left for Code Spaces officials, along with a Hotmail address they were supposed to use to contact the attackers.

“Upon realization that somebody had access to our control panel, we started to investigate how access had been gained and what access that person had to the data in our systems,” Code Spaces said. “It became clear that so far no machine access had been achieved due to the intruder not having our private keys.”

 

Code Spaces said it changed its EC2 passwords, but quickly discovered the attacker had created backup logins, and once recovery attempts were noticed, the attacker began deleting artifacts from the panel.

“We finally managed to get our panel access back, but not before he had removed all EBS snapshots, S3 buckets, all AMI’s, some EBS instances and several machine instances,” Code Spaces said. “In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted.

ThreatPost adds:

Within 12 hours, Code Spaces went from a viable business to devastation. The company reported that all of its svn repositories—backups and snapshots—were deleted. All EBS volumes containing database files were also deleted.

When it comes to platforms, there is a constant refrain from the programmer community to “not to put your eggs in someone else’s basket“, or “What Apple Giveth, Apple taketh away“, and yet we still do it. We still think that just because someone else promises redundancy, we’ll be OK.

We won’t.  Gmail goes down. AWS goes down

Being in the ‘cloud’ doesn’t change your disaster recovery plan. Scott Hanselman refers to it as the Backup Rule of Three:

  • 3 copies of anything you care about – Two isn’t enough if it’s important.
  • 2 different formats – Example: Dropbox+DVDs or Hard Drive+Memory Stick or CD+Crash Plan, or more
  • 1 off-site backup – If the house burns down, how will you get your memories back?

As a business, who do you trust with your data? More importantly, who do you trust to make sure you don’t go out of business?