3 ms·

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 t

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 http://github.com/chrissnell

vivin 12y ago
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.
- Retric 12y ago
  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.
AYBABTME 12y ago
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.
- mattlutze 12y ago
  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.
thearn4 12y ago
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.
mrbill 12y ago
This the Chris Snell that I know from Bikeworld? 'sup, man?

vivin 12y ago

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.

Retric 12y ago
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.

AYBABTME 12y ago

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.

mattlutze 12y ago
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.

thearn4 12y ago

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.

mrbill 12y ago

This the Chris Snell that I know from Bikeworld? 'sup, man?