3 ms·

> The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That goes against much (but not all!) of th

> The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That goes against much (but not all!) of the DoD paradigm, it is interesting to see they might be changing. My (outside) impression has changed the more I've heard over the years, to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Those people in turn have those under them that "get shit done" they hand the important things to, and so on, all the way down to privates in the military. The important thing being that those people that get shit done are given a lot more leeway in how they accomplish things (which might later become doctrine of successful), and this is specifically how those orgs evolve over time. Again, that's my outside perspective from someone that's interested whenever I hear it and reads/listens to history sources (podcasts,etc).

Jtsummers 4y ago
> to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Within military troops, yes. That's an active goal, especially on the officer side where the whole career path is pointed towards increasing levels of responsibility and leadership. The problem is not in the troops, but in the program offices. I was on a spectacularly failed Waterfall (big-W, they were explicit about what they were doing) where they handed the task of managing a large, multi-billion dollar software system (from the DOD side) to a 1st Lt history major. She had no preparation for the role. Software acquisition in DOD is, mostly, a clusterfuck. I felt bad for her because she legitimately did not know anything more than the basic legal and financial side of things, she had no technical comprehension and had to trust people (contractors) who were lying about the system status and quality (what was delivered, after she had moved on, was years late and had a fraction of the target capabilities). Program offices are not generally composed of people who have real-world experience with software development. Remarkably they have great engineers, good finance people, but the software person (often singular, even in programs that are almost exclusively composed of software systems) is usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major).
- kbenson 4y ago
  > usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major). Ugh, I can see that being a problem. I remember my practical experience in projects after graduating with a CS degree, and it was close to non-existent (a class in development methodologies without experiencing it yourself is just a survey of all the things you can do badly if you were to be in charge).

Jtsummers 4y ago

> to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Within military troops, yes. That's an active goal, especially on the officer side where the whole career path is pointed towards increasing levels of responsibility and leadership. The problem is not in the troops, but in the program offices. I was on a spectacularly failed Waterfall (big-W, they were explicit about what they were doing) where they handed the task of managing a large, multi-billion dollar software system (from the DOD side) to a 1st Lt history major. She had no preparation for the role. Software acquisition in DOD is, mostly, a clusterfuck. I felt bad for her because she legitimately did not know anything more than the basic legal and financial side of things, she had no technical comprehension and had to trust people (contractors) who were lying about the system status and quality (what was delivered, after she had moved on, was years late and had a fraction of the target capabilities). Program offices are not generally composed of people who have real-world experience with software development. Remarkably they have great engineers, good finance people, but the software person (often singular, even in programs that are almost exclusively composed of software systems) is usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major).

kbenson 4y ago
> usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major). Ugh, I can see that being a problem. I remember my practical experience in projects after graduating with a CS degree, and it was close to non-existent (a class in development methodologies without experiencing it yourself is just a survey of all the things you can do badly if you were to be in charge).