Having known many people that worked in/around the military and defense industry, this seems like our reality.
> “An interesting question is, ‘Where did the name, dynamic programming, come from?’ The 1950s were not good years for mathematical research. We had a very interesting gentleman in Washington named Wilson. He was Secretary of Defense, and he actually had a pathological fear and hatred of the word, research. I’m not using the term lightly; I’m using it precisely. His face would suffuse, he would turn red, and he would get violent if people used the term, research, in his presence. You can imagine how he felt, then, about the term, mathematical. The RAND Corporation was employed by the Air Force, and the Air Force had Wilson as its boss, essentially. Hence, I felt I had to do something to shield Wilson and the Air Force from the fact that I was really doing mathematics inside the RAND Corporation. What title, what name, could I choose? In the first place I was interested in planning, in decision making, in thinking. But planning, is not a good word for various reasons. I decided therefore to use the word, ‘programming.’ Iwanted to get across the idea that this was dynamic, this was multistage, this was time-varying—I thought, let’s kill two birds with one stone. Let’s take a word that has an absolutely precise meaning, namely dynamic, in the classical physical sense. It also has a very interesting property as an adjective, and that is it’s impossible to use the word, dynamic, in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It’s impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities"
--Richard Bellman on the naming of dynamic programming [1]
The amount we pay for security, it is appalling some of the data in OP's report just to hit some arbitrary number over security and understanding of a defense product.
> The modern DoD is based around the Asst Sec Defs and business processes put in place by Robert McNamara
Robert McNamara, a Harvard Business School MBA, 'epitomizes the hyper-rational executive led astray by numbers' [1]
[1] https://www.technologyreview.com/s/514591/the-dictatorship-o...
MBAs are a zombie fungus disease upon companies
Since then, however, there has been the constant desire to deskill workers. That is, they want explicit operating/work instructions that mean even a trained monkey could do the job. This is useful for some things (got a broken down Jeep? Pull out the manual and even your Lt can fix it!), but for development, acquisitions, and sustainment this is actually a horrible idea.
The infection of deskilling spread to the office. They've removed the office managers (among others) and left the work (critical, but time consuming and secondary to the mission) with the highly educated and trained staff. This diminishes their ability to focus on real work (see [0] from yesterday). From there, they continued to try to document precisely how engineering work is done. Believing that the process of the work is the same as the work. So if only my engineers knew how to properly fill out SF-1234 it wouldn't matter how educated they are, magically the work would be done.
Of course, we all know this is bullshit. Knowledge work is called that for a reason. The capacity for work is based on the knowledge of the workers. You cannot deskill computer science or aerospace engineering. You can deskill aspects of it, or really the workflow, but not the science and engineering work itself. I can eliminate or largely reduce the need for a classical configuration manager by establishing a (automated) peer review and version control workflow. But the creative act producing content that enters the workflow will always require skilled, competent, knowledgeable engineers and scientists.
[0] https://news.ycombinator.com/item?id=18157885
EDIT: I will not change the above, but I will make a note. After re-reading the Wikipedia page on Scientific Management [1] I see that some people consider Lean and others to also be extensions of it. So read the above as describing Fordism and Taylorism, not scientific management in general. Any management largely based on, or influenced by, statistics, models, and experimentantion could be argued to be "scientific management", that doesn't mean it's bad. It's when it's taken to an extreme. Like, in Taylor's case, where workers are treated with contempt. The purpose of the management being to make them fully expendable. They had no unique knowledge or skills that could really contribute to the business beyond their physical presence and ability to follow directions. His goal was to disempower workers, whereas other examples (Lean particularly) work to empower workers.
Small teams with skilled people, the startup model, works best even in large companies. Closer to the customer and more cohesive unit makes for a better project, that is why innovation happens at smaller companies or small research groups in companies or universities.
n(n-1)/2 is the formula to calculate the number of communication channels on a project where n=the number of team members/stakeholders on a project.
On a team of 1, it is all you, you make sure it works.
On a team of 2-3, it is just that few, you make sure you and others are doing their part.
On a team of 10, 45 communication connections, you might not have the same level of care because that isn't my role or someone else has got it. Beyond 7-8 team members communication becomes humanely impossible.
On a team of 100, you have so little power/responsibility that you feel out of place calling attention to issues, you don't know of everyone on the team even.
Metrics are a good thing, to use as an input, so is customer feedback, product goals/focus, usability, employee satisfaction and many other things that aren't always measured like technical debt, product quality, security, simplicity of processes/production, research and development and more.
If you measure the wrong things, it can give you the wrong idea that you are moving in the right direction while possibly overlooking aspects not captured in metrics.
If you only looked at revenue and employee head count for instance, growth might be deceiving. Profit and revenue per employee better, but also employee satisfaction, customer satisfaction, the market, product quality, timing, security, long term direction etc etc get overlooked in the metrics department mainly because domain knowledge has less power than oversight in most mature organizations.
This reminds me of bystander effect [0]. The demarkation of responsibility in large enough teams could invoke delays just in finding who is responsible for what.
As an MBA holder and avid HN user, I take issue with that statement...
Why try to make this link if it isn’t there? What if I replace MBAs with ‘foreigners’, ‘women’, ‘people who read HN’, etc?
Why do we need this? Does blaming non-technical people for the failures of management make us feel better about ourselves?
The thesis that parties who have negligible expertise in a given area given charge of people with substantial expertise in that area contribute minimal or negative value seems at least arguable.
Maybe we as a society value the idea of teaching people to lead people irrespective of what those people actually do instead of elevating skilled individuals in that area because it allows us to reward all the rich peoples kids that aren't smart enough to do.
This needn't mean you automatically are unintelligent or bad at what you do. You could personally be awesome and contribute greatly to the efforts you work with/lead.
MBAs are used as straw man punching bags on HN. Anything that goes wrong with a company where there’s the perception that the “obvious technical solution” was ignored, is blamed on this nebulous cabal of MBAs, who are apparently hired in droves just to sabotage their employer. For some reason it’s totally ok to vaguely blame the business folks.
I think you're building a bit of a straw man. I think the criticism of MBAs rests on criticism of the idea that good decisions can be made by people that chiefly have "management skill" but lack "domain skill." A lot of people believe domain skill is extremely important, and if you stuff an organization full of empowered people who only have management skill, you'll get more bad decisions. You'll also get a lot of dysfunction as they spend too much time pursing the "management ideas" they're more comfortable with, and neglect "domain ideas."
This comment actually touches on some of these issues in detail: https://news.ycombinator.com/item?id=18179247
Obviously not. I think the critique is about MBAs who don't have domain experience and don't think they need it, because they have a generically-applicable "management skill." That ponderous specification is typically shortened to "MBAs" for brevity, since it apparently has some root in ideology that's common in business schools.
Here's a few concepts that came out of B-Schools/MBA land. at a grossly brief, thus over-simplified level:
* "Shareholder value" as the prime goal of management, justifying the exclusion of all other stakeholders (employees, customers, community supporting the business, country supporting the business, etc.). Few concepts have done more to damage this country and capitalism itself (note the main problem of shrinking middle class able to purchase the goods produced).
* "Manufacturing is fungible & expendable, just outsource it to the lowest-cost country". Massive damage to developed nations' economies, and national security, all to goose short-term profits. Actively destroys massive corporate value of know-how, simultaneously providing both the existing know-how and ability to generate new know-how to new competitors.
While all the MBAs thought we were exploiting the cheap Chinese labor, the Chinese were looking long terms and exploiting our myopic need for short-term profits to gain massive economic & military advantage (note the recent controversies about planted chips, among many other similar security nightmares). This will go down in history as one of the all-time great geostrategic blunders, brought to us by MBAs.
* "Invest in the stars, milk the cash cows, dump the dogs" -- breaking down your business units in this way, guarantees that the business will become a shell of its former self -- the dogs will be sold off with no regard for their potential if invested in (they may be developing key breakthrus, but not yet showing good financials), the cash cows will be starved of all potential and soon become dogs to be sold off, and maybe the stars work out or maybe they don't. Great way to kill a business. GE was financially managed -- where is it now?
* The general concept that I've seen multiple times of focusing on managing to the financials instead of managing to CREATE great value. The financials will ALWAYS look better when investment in building true value and a competitive moat is overlooked to cutting costs and goosing current sales. These numbers will look good and increase for a while, possibly years. Until they don't. At that point, the business has no hope, and is a walking zombie, unrecoverable.
So, yes if MBAs are kept in their suitable container of 1) installing good accounting practices for tracking and security of financial assets, 2) managing the profits that are made to ensure good returns, 3) optimizing operations & taxes (lease vs. buy capital assets?, etc.), then things will work out great.
But putting them in charge without also having serious domain knowledge, both on the customer/market side and on the engineering/manufacturing side -- very bad idea.
"Do you want to play a game?"
This is some scary bad WarGames like security, password 'joshua' level.
> Program offices were aware of some of the weapon system vulnerabilities that test teams exploited because they had been identified in previous cybersecurity assessments. For example, one test report indicated that only 1 of 20 cyber vulnerabilities identified in a previous assessment had been corrected. The test team exploited the same vulnerabilities to gain control of the system. When asked why vulnerabilities had not been addressed, program officials said they had identified a solution, but for some reason it had not been implemented. They attributed it to contractor error.
Ah, the old blame the 'contractor error' and 'not invented here' syndrome. Looks like engineers aren't in the power structure to change these things, scary if the military is driven like an MBA only led business with no influence from engineering/security.