The HQ was processing things like medical evacuations, support fire missions, contact reports. The way it was done was very inefficient, frustratingly so. For instance, a medical mission would go like this.
A unit would report an IED strike with critical injuries. The unit would pass a MEDEVAC request by radio to their company -> batalion -> brigade HQ (us). We would then be the dispatch center for the helicopters and synchronization of airspace and hospital and all.
When the request would come in, it would typically be ~30s to 1m after the actual strike. I would yell at an airman that would get up his chair, walk to the center map and with his rule, measure the distance in miles between the hospital landing pad and the strike. He would then compute ETAs and for the helicopters based on various parameters. He would then ask the helicopter HQ to send a chopper on site. He would then slowly type a message in a proformat, post that in the channel. That's ~5m later.
When I was there, I've picked up VBA (VB for Applications), the macro system behind Excel. I didn't even know what a programming language was back then.
This 5min latency in sending the request to choppers, and giving back ETD/ETA info to the unit on the ground would result in people dying off their wounds, or staying in dangerous/exposed locations longer than strictly necessary (waiting for chopper ETAs). This 5min latency was putting people at risk and killing folks.
So I wrote a tool to automate this man's job, in VBA. I picked up the language on site and reduced that latency to ~15s. Being the canadian army, they don't give medals but I got this:
Then, I wrote tools to automate many other parts of the HQ, like a database to handle multiple concurrent critical incidents or a tool to manage airspace for fire missions. Then I realized I liked this programming thing much more than running around with guns. Then I came back to Canada and started a degree in software engineering. Then I'm here today.
His job was fairly simple: controlling access to information. Other departments would send him requests for information about certain individuals, and his job was to send them the data that they required, but only that data, to prevent other departments from intentionally or inadvertently accessing the wrong data (and violating privacy laws).
So his day consisted of getting an e-mail with a request for data X about person Y, and then sending them that data. A fairly straightforward task, but when he was hired there was a three-month backlog.
After a week or two, he wrote an application in VB that would access the database directly; he could type in a name, choose a result, select fields, generate a PDF, and e-mail it to a given e-mail address. What used to be a 5-10 minute job became a 30 second job. His three-month backlog turned into a three-month headway. People were getting their results within minutes of sending the request, rather than hours, days, or weeks, and productivity everywhere increased.
At this point, his job consisted of sitting at his desk watching anime on his netbook until a request came in, typing for a few seconds, clicking a button, then watching anime again.
He was bored constantly; he asked his boss for more work, something else to do, automation or paperwork or anything, but his boss refused. Union job, defined role, can't give you more work.
Haven't talked to him in ages. For all I know he's linked his app into Outlook to pre-fill fields by now and he's running a startup out of his office in his eight hours a day of extra spare time.
It might sound corny, but this is what I like to think the profession is 'all about' - identifying real problems and using our talents with whatever resources are available to solve them.
Best of luck with your studies.
This sounds like an interesting startup idea: TOC software. It would be easy to write. I wonder how difficult it would be to sell to the Army.
I see from your Github that you, too, write Go. We should talk sometime.
I think the best way to make a difference with software would be as a consultant, deploying with units and doing work straight from there, in an ad-hoc way. Similarly I guess to the stories about how the Obama elections team worked. Deploying a small group of devs with a battle group, who have for purpose to write custom software to make the battle group more efficient. By participating in the pre-deployment training and exercise, the devs could familiarize themselves with the most important tools that need to be created for the deployment. Then while deployed, polish the rough edges and adapt the tools to new situations.
Otherwise, going through the procurement chain of the army will inevitably lead to insanity and bad software, and no actionable result. We had software when I went about writing those tools; it was just so bad and inappropriate that nobody used it.
I once worked on a project that spent 7 years in the planning stages and they decided to take a 6 month break from development after the first demo to reevaluate things. Not because the demo had issues, they where not sure if this was the correct approach.
A different project was considered a complete success except we increased productivity to much.
Really speaks volumes about how key it is to take the initiative upon yourself to solve problems and advance your own knowledge. Thanks again.
Heck, my brother is commander of the 10th medical wing in the USAF -- I should ask him what tools he thinks they are lacking.