Battle Captain, right? I know exactly how you must have felt. I did this job as a 1LT in a bunker in Korea with shitty outdated MS Office and I never even thought to write a VBA app.
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.
Yup, in the canadian forces, they call it 'Duty Officer', much less glorious sounding than Battle Captain =)
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.
The challenge of being a contractor embedded in a unit is that ultimately, someone procured the billet spot for you, and often thinks of you as another resource to be tasked. This tends, unless you're lucky to have a contract rep that let's you flex your expertise, to lead to you solving "good idea fairy" problems instead of solving observable needs.
Sadly, having done this type of work before replacing existing systems with better UI is seen as a waste of resources and Bulding new systems involves rediculus levels of paperwork and changing requirements.
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.
Better TOC software would be great (though I haven't been in uniform in almost 6 years). But I remember ASAS and ASAS-L being pretty terrible for what they were.
Comments
Battle Captain, right? I know exactly how you must have felt. I did this job as a 1LT in a bunker in Korea with shitty outdated MS Office and I never even thought to write a VBA app.
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.
http://github.com/chrissnell
Yup, in the canadian forces, they call it 'Duty Officer', much less glorious sounding than Battle Captain =)
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.
The challenge of being a contractor embedded in a unit is that ultimately, someone procured the billet spot for you, and often thinks of you as another resource to be tasked. This tends, unless you're lucky to have a contract rep that let's you flex your expertise, to lead to you solving "good idea fairy" problems instead of solving observable needs.
I'd like to write logistics software for the Army too. I could have replicated the system we were using in probably a month, maybe less.
Sadly, having done this type of work before replacing existing systems with better UI is seen as a waste of resources and Bulding new systems involves rediculus levels of paperwork and changing requirements.
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.
Better TOC software would be great (though I haven't been in uniform in almost 6 years). But I remember ASAS and ASAS-L being pretty terrible for what they were.
This the Chris Snell that I know from Bikeworld? 'sup, man?