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:
https://s3.amazonaws.com/antoine.im/AIR+WING+COMD+COMMENDATI...
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.
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.
Sometimes. :D I say this as a former 98C who has seen the dumbest people in MI units.
But you're right about the need for programming support: during the Gulf War I discovered that the '386 (possibly '286) that we'd been using primarily as a Wing Commander Entertainment Console in one of our comms huts also had a copy of DBase III on it. Figured out how to create a table and query it, and applied it to my job. Didn't get a medal out of it, but it opened my eyes to the usefulness and power of databases.
Of course, sometimes a brain will invent a really weird pattern. You get agriculturally incompetent aliens, government employed blues brothers fans and all kinds of nonsense. I guess that's why intelligence gathering should be done in a group. More eyes results in less errors, right? :)
Now imagine you're not offering stock, and are offering well below market rates, but at least they'll have meals made for them.
Government pay scales are inflexible. A college graduate in CS would typically enter government service as an O-1 or GS-7, step 1. Both are less than $40k/year. Pay maxes out at around $150k/year after 18 years of unremarkable service. If you somehow manage to become a 4-star general of the cyberbrigades, in essence the CEO of Army Programming, Inc., you could possibly earn $180k per year, with no equity, but a nice pension plan.
But you won't get even half that far. The mental processes involved in creating military procedures are fundamentally incompatible with those involved in software development. It is worth noting that everything Original Poster did to improve anything was completely against the rules, and was only permitted because it actually worked out in the field, and did not negatively impact anyone's duties.
Government hiring is ridiculous. I once overheard a conversation about the possibility of converting contractors to employees. As it turns out, thanks to the preference ranking systems, the person most perfectly qualified to do the job, because that is exactly what he was currently already paid to do, with over 10 years of experience doing just that, would typically turn up no earlier than the third page of applicants. Every one of them would have to be individually considered and rejected before reaching the person already doing the job. Also, he would have to take a 50% cut in pay.
Essentially, the government cannot compete in the open job market for any skill that makes a person worth hiring. They are therefore forced to train existing military personnel in software wherever necessary. And as expected, they train for that in a similar manner to the way they train everything else. The person is ordered to transfer to Fort Wherever for six weeks, to become a programmer. You end up with a person that thinks Waterfall is a good process, better programs have more lines of code, and that unit tests are written from an Excel template.
You cannot solve a problem from the same state of mind that created it. The military is covered with leechlike contractor companies because they have been forbidden by law, by regulation, and by standing order from solving their own problems in an effective way. As always, the worst problem is bad management.
My concern is that while macros or simple programs would let people do things more productively or do things that would not be feasible manually, they also let them make bigger and more costly mistakes. We need to figure out how to get the former while minimizing the latter.
This spring, I put together a graphic novel. When I was creating the list of source files to drop into InDesign's batch processor (a tedious task that involved full file system paths to a bunch of sequentially numbered files), I left one out. I managed to miss the forest for the trees when proofing, and didn't realize I'd made this mistake until I was sitting down to relax and enjoy reading the advance copy. With 399 more sitting on a loading dock waiting to be shipped to me.
I had to do a new print run; this cost me about $6000, which pretty much puts the Kickstarter for this volume in the red.
I also wrote a simple little script that I can point at a directory full of files, and get a CSV of everything in it to feed to InDesign. I will not be making this particular mistake again on a larger project. There will be other ones, I'm sure. And I'll try to find ways to automate stuff I can, and improve my proof reading process as well.
You are going to make mistakes. By hand, and in creating automated systems. This is a fact of life.
Also, couldn't help but think of Grace Hopper, who was received a special promotion to Rear Admiral, post-retirement, because of her work on computing. I didn't realize until re-reading her Wikipedia entry how much of her work and leadership (serving as director of the Navy's programming languages group) occurred after her retirement at age 60:
Perhaps you did not have time to use Grace Hopper's language COBOL to truly understand opaque bureaucracies.
So I dumped the file to CSV, wrote a one-liner awk script that did the transformation, and imported the result back as a new column. No medal, but one very happy secretary!
What really astonished me, though, is that she didn't even think that this kind of thing was possible. In her worldview, one Machine spit out data in a fixed format and another Machine demanded it back in another, and it was just too bad if humans had to do mindless work to conform to their needs.
I touched on it in the mainteannce/ops space, but the admin space is also susceptable to this. I find that there's a very rapid change in fundamental understanding of capability between age groups. Of course there's exceptions in both parties but many people born after about 1980 really do underestimate the benefits they have by having grown up with personal computers. They simply just think about them differently.
It did make me wonder how often some variant of this happens every day. "Data entry" is still a job, after all...
I've met a lot of smart Soldiers during my time in the Army. SSGs with PhDs, Specialists in law school, etc. It helps being in a branch that has a higher ASVAB requirement but there are smart guys in all of the branches. The military (especially the reserve forces) needs the skills that talented civilians like the folks here on HN have. The military also has a lot to give back in return. Besides the leadership skills and the usual GI Bill stuff, there are some pretty solid technical skills to be acquired. My previous employer, Rackspace, has network engineering teams that are heavily populated by former enlisted signal personnel who got Cisco and Juniper training in the military and left to make some very attractive salaries on the civilian side. If you are young and smart but lacking in the big iron skills, it's not a bad way to jump-start a great career.
Being in the military does suck for various reasons also though, but even that experience gives you lessons & motivation to take away from it.
I also know a few of my friends who were in signals who came out of the military to get some pretty good jobs. Another good thing is that the Army encourages you to take courses online while you are deployed or even when you are serving. So you can get credits which you can transfer to a university when you try to get a real degree.
When we got back I was useless physically as I had to rehab after a surgery. The XO stuck me in the arms room and I also tried to help our (typical) overworked admin NCO with normal company business.
Here's where it gets interesting. The admin NCO was a super bright guy with zero programming background. In fact it turns out he was just one of man bright NCO's with no programming experience who had held that job at one time or another. Guess how he kept track of the company's business? In a custom Microsoft Access application with plenty of home spun Visual Basic. The funny thing is he didn't write the app, oh no, some NCO years before him had written it and like some odd cultural tradition handed down for generations every NCO after him just progressively enhanced it to suit their needs. There was an old Access book on the shelf in that office and each admin NCO had picked it up, learned what they needed too, and carried on. Said admin NCO is now a doctor.
As a consultant I've come across similar stories in different industries of people picking up VBA and building custom things with no programming background. They always warm my heart.
I recall the off-the-shelf satellite systems! We had one too (I was stationed on Camp Liberty) and an Iraqi engineer dude would show up to help us set it up. It only worked about 70-75% of the time and once we had a serious rainstorm that damaged the dish. It took us a while to get us a replacement.
Eventually I was able to find a PDF manual for the system and was able to do some of my own troubleshooting when issues came up.
Our operational database is still accessed via an emulated version of IBM 3270 terminal [1], where we have Windows emulator for the client that connects to the DB2 database. It's freaking ancient, to the point where the emulated version uses the mouse input to emulate the "light pen" [2] from the original system, which was used because the mouse barely existed at that time. The thing uses 4-letter terminal codes to access every function. Oldschool.
Our employee distribution is quite significantly skewed towards the older generations. Compounding it, many of the people who interact with it tend to be trade-staff who started in workshops then climbed their way into being semi-technical admin (roles such as fleet planning, etc.). It works, but the mind boggles when you imagine the degree of time wasted every day by these guys because they don’t have any sort of significant batch processing capability.
In the course of doing my work, I was exposed at some point to ODBC drivers for the database. I managed to get some credentials used for running reports against it (I think I found another reporting query with them saved in the file and ripped them out of it) which that allowed me to arbitrarily query the database. From that, I started to automate a great many things - for example, where previously a yard coordinator would type in the code to query each storage road individually in his maintenance yard to see what he had around for the day’s work, I gave him a 1-click query for doing the same job.
Our maintenance database was a similar affair, except that it runs Oracle and is a little less antiqued. It also has a windows-native GUI but it is similarly lacking in many batch processes.
A more recent example that I tackled is that every single morning, a yard coordinator would work out which groups of vehicles would be coming in that day and were due for their roadside inspection (info from the operational database). He would then print out a list of these (literally on paper, next to his keyboard) and manually enter each vehicle, 1 by 1, in to the maintenance database to check whether they were then due for their yearly scheduled maintenance before their next roadside inspection. If they were, they'd be flagged for dragging in to the workshop. This took him approximately an hour, every single morning of his work life, and that would then be summed up and presented at his morning planning meeting.
He’d asked the guys who normally support this sort of stuff, but had got nowhere in about 7 months because it sort of fell between “fully-fledged IT department that can do this easily but comes with bureaucracy” and “guy who kind of knows how to develop database queries, but doesn’t know how to query 2 different databases in the one query” and so it never got anywhere. I was on site one morning for some unrelated work and saw him doing this. When I asked about it, I told him to give me some time and I’d come back to him and proceeded to write a query to do it in one click.
I’ve been doing this sort of stuff for about 3-4 years now and have a (good) reputation amongst the maintenance, operations, etc. guys now. The problem is that IT tend not to support them, as it tends to be more effort spent on bureaucracy than the task at hand. Furthermore, the guys don't know who to talk to in order to get this stuff done / don’t know any better, so they just deal with it and do it by hand.
In the end, I guess I did get noticed by middle management because I've now been tasked with being the lead on developing/acquiring a next-gen operations business intel solution which will draw together all the disparate bits of data we gather and put it to better use, so that's cool.
I guess my take-home message is that many of you guys work in the IT space in technology companies. You tend to be exposed to people who just get this stuff and so it all just happens. There's so so many more companies out there though, particularly established ones running operations (think mining, transport & logistics, the army as per the OP, etc.) where this stuff simply isn't done and it's a completely different world. They tend to have a distrust of "IT" because their experience with them is the bloated bureaucratic mess that is many corporate IT departments. IT in large, non-high-tech corporations can also be the sort of place where a problem either is too small to care about, or significant enough that it warrants a legion of SAP/Oracle DBAs and a whole heap of project management to develop a “solution” over a 12+ month period.
There is an astounding amount of potential for someone who gets operations / the guys on the coal-face, and can bring high-tech solutions to their problems rapidly. They will quite literally treat you as some sort of wizard who has mastered the arcane forces if you do this, because you deliver a solution that is otherwise unattainable in many situations. Your business impact is huge because you cut out a whole heap of otherwise wasted time, which is a direct benefit to the bottom line.
The major challenge IT has is bridging this gap. I’m not quite sure how you go about leaning yourself down enough whilst still appealing to the more rigid constraints of “IT in a big corporation” but I am convinced that there is no end of value to be created in this area.
[1]: https://en.wikipedia.org/wiki/IBM_3270 [2]: https://en.wikipedia.org/wiki/Light_pen
It was 1984. I was stationed at Babenahusen, Germany - Field Artillery. Yes, I was a 13 Bang Bang (13B). At that time, I was the only one to have a PC in the barracks. I used to stretch a phone code to the wall phone in the next building and dial up BBS's.
Anyway, I ended up working on the brigade's Wang System. I got there cause the S2 saw me hacking away on my Commodore one night and thought I was perfect for the job. Next week I was reassigned. Classic for the Army.
The PBO (Property Book Officer) did something, I never found out what - but the system crashed. Many of the personal records were stored in that system (and on 8" Disc's - remember those?). And it was my job to fix it.
I had completed Wang's various training courses so I was familiar with the system. But I had no clue how to even figure out what happened. I ended up calling Wang in NYC. And over the phone their engineers and I got the system back up. It took almost 2 days. And I got at most an hour of sleep.
I got an Army Commendation Medal out of it.
To get the best product quality, it's important to monitor the shape of the rolling surface of each roll. If they distort out of tolerance, they have to be taken offline and machined to a new finish - something that would stop production for hours.
My father told me of the time when they bought an expensive new computerised lathe to reduce the time it takes to fix up the rolls - this was in the 1980s when a PC on a production line was still a thing of wonder. For a while, everything worked as planned. Then, for some reason, the quality of the reconditioned rolls dropped drastically. Despite the fact that the PC dump showed that the rolls had perfect surfaces and profiles, production defects skyrocketed and it was discovered that the reconditioned rolls were to blame.
To cut an even longer story short - they eventually discovered that the lathe operator had taught himself how to edit the PC logs (in hex!) to make the results look good, without having to get down and actually do the work.
Last one on this page:
http://en.wikipedia.org/wiki/Awards_and_decorations_of_the_U...
Apparently they had "modified" a clipper database and added new records, but it was one record per file, with each field delimited by new line and field/values in ini format (key=value). They were opening each file in notepad, then copying each value into a spreadsheet. They had over 20,000 thousand files^H^H^H^H^H records, needless to say this took a long time to compile the excel file which they used for reporting. Like 9 weeks long.
I was mucking around with Perl at the time, and I casually mentioned this is what Perl is good for, I got this skeptical look, so I said I'd prove it. They gave me 100 sample files, and then I spent some time using file globbing and some regexes to split out the data. Whilst I was about it, I fiddled with hashes and worked out how to use refs, mainly because I was a bit bored and learning some Perl concepts.
I then returned the next day with a working program, installed a Windows version of Perl, then copied the 10,000 records locally, ran my script, tweaked it, then emailed the guy the CSV file I created. The script took about 45 seconds to run (it was a bit inefficient).
I then walked over to the guy, asked him to open his email and watched his eyes bulge a little. I then walked to my desk and took some more calls about printers.
A few weeks later, I was surprised to discover I had been made employee of the quarter by Epson Australia.
I have a much, much less impressive story, but maybe someone will find it interesting: I was working at a military library as a civilian, and I automated repetitive parts of our workflow to add books to WorldCat using Autohotkey (We added books to WorldCat so other libraries could request them). I also came up with the idea of using our barcode scanners to check books out to people using a Word document - our library database at the time was slow, far away, and went down regularly. Up till then, no one had realized that you could scan bar codes into a document.
Unfortunately, I didn't realize that the automation I did was unauthorized; there was a shakeup that had to do with misuse of CAC cards, and as part of that, my scripts were discovered and I lost my job. Still, I think that kindled an interest in programming, and I now hack away happily at personal projects.
signed
Ed Snowden
