1. That "thin" line runs up a $686 billion tab every year. It's one of the thickest lines in the US budget.
2. Tech workers help pay a lot of that tab by working in productive sectors that generate the profits needed to keep the war industry going.
3. A very tiny percentage of the service members are ever deployed. Of those, only a tiny percentage ever see combat. Those that don't see combat are paid very well for their time. Why does this matter? Because $686 BILLION pays for a lot of software engineers.
IMO: if the military needs more technical expertise, then:
1. Get good management! Open up leadership positions to non-officers or, god forbid, civilians. No more officers who majored in Theology at bible colleges or History at an academy running "Cyber" teams. The business world stopped hiring blank slate MBAs to manage software projects a LONG time ago. Time for the military to catch up.
2. Especially in the Army, stop running pointless rural jobs programs and reallocate that headcount to salaries for skilled professionals in more productive locales.
We're spending 680 BILLION employing enormous numbers of people to run around in circles (sometimes literally). There's more than enough money to pay people for their work and more than enough patriotic talent willing to take the jobs. What's needed is competent management and headcount.
You'll find the complementary opinion in Mathematics departments -- a general chagrin about the type of mathematics that they have to teach in their service courses for engineers.
Mathematics is a very general tool. As with any very general tool, a lot of the devil is in the details of how to use it in any particular domain.
For this reason, in-sourcing mathematics service courses is best for everyone. The very best math-adjacent departments in every field tend to do this either directly or indirectly. E.g., in the direct model, many CS departments internalize the Discrete Mathematics course and some combinatorics. And an example of the indirect model is Mathematics departments that hire Math Finance professors to cover the service load for econ/fin/bus depts.
I think this in-sourcing (either directly or indirectly) is best for everyone -- mathematics depts don't do a good job at teaching those service courses and often don't do a great job of it in any case. Unfortunately, most departments don't have the headcount (in students or faculty) for a specialized mathematics curriculum, so they have to share the math faculty with N other majors to predictable effect.
Sexuality has always been an open topic at work. People talk about their kids. Display pictures of their family. Bring their spouse to the Christmas party.
It's only recently that people can talk about their non-heterosexual relationships at work. In 1995, mentioning your lesbian partner would've been overtly political and, in certain workplaces, is STILL called "political" and can get you fired [1].
I think a lot of posts here completely missed the point of the article, which is NOT about the role of architects in pure software products such as websites.
The author is talking about large defense systems like satellite arrays and airplanes. The status quo that the author is responding to is that engineers of the physical systems (missiles, satellites, etc.) make all the decisions with software bolted on after the fact. This is definitely true at places like Boeing.
You could replace architect with "senior software engineer" or whatever.
Point is, software should have some seat at the table during the design process.
The fundamental thesis of the piece is: "If, instead, system acquirers ensure that systems engineers address software concerns at the same time as the physical solution is conceptualized, acquirers can opt for a slightly different physical system, whose software architecture is tuned to optimize the provided capabilities."
Which, to me, sounds entirely reasonable. If some system needs an MLOC or so and the software will be doing a complex thing like piloting the aircraft, you better be thinking about the software from the beginning of the project...
As an aerospace and defence systems engineer & software engineering manager I came here to note exactly the same thing, however it’s not hugely surprising on a SW-centric site like HN.
I think this applies to all disciplines “under” systems engineering too, the thing is with software there are often a lot more chances for things to go sideways compared to EE or mech in development.
The sooner you get the smart people in each discipline (Software or otherwise) to the table the better off everyone will be. This is why in systems engineering processes like ARP4754 you’ll see the word “preliminary” a lot. Preliminary architecture can be developed along with the system requirements as a basis for discussion with those performing the safety analysis and those implementing the software and hardware items. Having a software architect at the table, someone who can reason about the software architecture and its impact on the systems as a whole and the safety case can only help.
Yeah, between this and the MITRE post the other day I wondered if it was suddely Systems Engineering Week at HN. This is not the kind of content you usually find here.
Professional conferences and the like. For better and worse, it more resembles fields like medicine, law, traditional engineering where most shop talk happens in professional settings and at a specific allotted time, as opposed to online throughout the year during after work hours.
Thanks, that's much more clear. I'm still confused about how you make that guarantee on the first 20%. You keep it in reserve?
Edit: generally, I wonder if you have a huge perception problem even if you've designed a responsible insurance product due to the fact that people are (reasonably) suspicious of taking on enormous amounts of counter-party risk from a pre-seed start-up.
Yep! That's exactly right. We keep that in reserve in a 3rd party account :)
Also, you have a great point on the perception problem, which is what we are trying to tackle right now. We have genuinely designed a product that is meant to be the most customer-friendly buyer model out there, but because we are a seed-stage company, many people are just concerned, because we lack a long standing reputation in the industry.
Automating this sort of thing doesn't make any sense unless you're switching laptops on a much more regular basis than every other year. You're going to spend more time vetting the ideas in these comments than you'd spend configuring your new laptops for the next 4 years.
"Rebellious teenagers always want to establish independence from their parents"
The rebelliousness of college students seems so obvious to me. Everyone here using youthful behavior (almost all in their teens and early twenties) to bash their favorite bogeyman group (usually composed of much older people) is missing the completely obvious.
>The rebelliousness of college students seems so obvious to me. Everyone here using youthful behavior (almost all in their teens and early twenties) to bash their favorite bogeyman group (usually composed of much older people) is missing the completely obvious.
I mean that 18 year olds at Yale are... 18 year olds.
Protests have been a regular fixture on college campuses (including non-elite campuses) for at least 50 years. Including times when the elite/the country had "purpose". Kent, Ohio isn't exactly New Haven or Cambridge...
Youthful rebellion is as old as time, and arguably isn't even unique to humans. Therefore, grounding a sweeping societal critique in any particular mode of youthful rebellion (be it political protest or inane partying) seems a bit... silly.
2. Tech workers help pay a lot of that tab by working in productive sectors that generate the profits needed to keep the war industry going.
3. A very tiny percentage of the service members are ever deployed. Of those, only a tiny percentage ever see combat. Those that don't see combat are paid very well for their time. Why does this matter? Because $686 BILLION pays for a lot of software engineers.
IMO: if the military needs more technical expertise, then:
1. Get good management! Open up leadership positions to non-officers or, god forbid, civilians. No more officers who majored in Theology at bible colleges or History at an academy running "Cyber" teams. The business world stopped hiring blank slate MBAs to manage software projects a LONG time ago. Time for the military to catch up.
2. Especially in the Army, stop running pointless rural jobs programs and reallocate that headcount to salaries for skilled professionals in more productive locales.
We're spending 680 BILLION employing enormous numbers of people to run around in circles (sometimes literally). There's more than enough money to pay people for their work and more than enough patriotic talent willing to take the jobs. What's needed is competent management and headcount.