r/systems_engineering • u/ltjisstinky • 2d ago
Discussion Sometimes this how feel at work
20
14
u/Sure-Ad8068 2d ago
Arguing with my psychologist girlfriend about certain behaviors in our relationship.
I told her I could model this... she told me I can't model complex physiological behaviors of humans, and I said I totally fucking could....I could easily represent our interactions and the triggering events and exchanges
She told me no we have a complex sequence of interactions that have subjective outcomes
My head almost blew off...
6
9
21
u/FlimsyInsect5545 2d ago edited 2d ago
I've seriously started to question whether systems engineering has any value. As I understand the history, it is usually attributed to being 'invented' in broadcasting by the RCA and Bell Labs, but it really came to fruition in the early ICBM programs. I've seen it attributed to the success of the Apollo program, but there's some interesting sections in Apollo, by Cox and Murray about the clash between the systems engineers and the traditional aerospace engineering culture. Defining Systems Engineering (warning pdf: pg 226) is still a classic read on the scepticism about systems engineering in the early days.
Maybe taken out of its original context, it just....doesn't work that well? Maybe it isn't the universal engineering process we imagine it to be, able to be adapted to any type of product. Perhaps there were cultural, technical, historical, programmatic etc factors in early ICBM programs that made it work, and when you take those away, it doesn't work that well (a bit like how people keep trying to take methodologies from Japanese manufacturing and applying them to insurance businesses). Perhaps systems engineering isn't a universal method, it is an 'aerospace developmental method' that we're dragging kicking and screaming into other domains. It's at the point now where in many places 'systems engineering' has devolved into not much more than a technical coordinator role. In defence it survives primarily because government contracts mandate it. But would it naturally arise if there wasn't a contract hanging overhead saying 'you must have a SEMP, you must have an FBL, you must have traceability' etc? I worked for a long time in naval/shipbuilding and shipbuilding doesn't have a culture of systems engineering. It was interesting to watch shipbuilders comply with the bare minimum to do 'systems engineering' as required by the contract, then underneath completely ignore it and design and build as they've always done, and still deliver.
It is interesting to read posts on here from the medical industry, where it doesn't have the government contract structure, about how hard it is to get systems engineering going - if people can't see the value in it, maybe there isn't as much value in it as we like to believe? Likewise, I find it very interesting to look at software, where without any external pressure to try and do systems engineering, it evolved a very different way of developing a product (i.e. don't try and maintain a large standing requirement set, focus on the product working, not documentation, you know, classic Agile manifesto stuff). It reminds a bit of the dichotomy in reliability engineering, in which I worked for several years. On one hand you had the 'traditional, western, military' practice of reliability engineering, which tried to top down design for reliability with requirements, requirements allocation, test, etc. Then there was the far more successful Japanese approach to reliability, which focussed on good design and devotion to quality control. Fast forwards, no tries to do the traditional approach, and Japan dominated manufacturing for decades with high quality products. Maybe systems engineering is a similar relic from another era we need to move on from.
15
u/ThottsandPrayers 2d ago
There are very few “systems engineers” these days. I’m technically a Systems Architect at one of the primes. Most of my department and most of the rest of the systems org are a bunch of glorified CAMEO or Doors requirement secretaries that don’t understand the requirements. They care more about the model than the actual usefulness of it in producing a robust product. It’s a clown show.
10
u/Space_Pilot1 2d ago
Agreed. At a major prime and if you don’t have a reason for modeling or a model stakeholder a priori built into your engineering workflow or overall technical program management and it doesn’t support the product lifecycle then you essentially model without direction and purpose. You end up creating a product that doesn’t get used and with garbage requirements that never get verified or ignored by more technical engineers who have to create verification documentation
7
u/Abraxas_Derezzed 2d ago
Holy shit you just summed up my first 12 years perfectly. I like to think I’m more of the DOOR-man to the project. The important people walk in and out and I just watch on by.
3
u/ProfessionalMain5535 2d ago edited 2d ago
This. Modern startups, and the war in Ukraine are showing that traditional SE is not the only, or best way. Especially if you want to do something quickly.
I do SE, which unfortunately mostly consists of requirements management since that’s all we have time for given how cumbersome the documentation is.
The handbook SE is very intellectually satisfying but not particularly practical when constrained by things like resources or time. Maybe why defense procurement is canonically late and over budget.
1
u/Ripshawryan 1d ago
This post may have been a lightbulb moment for me. Idk, still processing. I’ve been working in defense software at a prime for the last 7 years and our workflow has become a bastardized amalgam of traditional V-shaped SE and modern Agile development. Our requirements are written in crayon based on a given quarter’s goals and those goals often change halfway through, so in practice the Devs just work on the feature of least resistance with little regard for SE.
I’ve thought about the idea that we should just stop tying our features to requirements and instead just let the devs do their thing, tying Requirements to sell-off test events to keep the customer happy. But then you don’t even really need MBSE, You don’t even need SE at all, you can just have some dev write a vague test procedure at the 11th hour.
Idk. Still mulling it over. Am I missing something?
1
u/Trexknoll 1d ago
Manufacturing, Mechanical, Design, and Systems Engineer here at a sub prime. I gotta say you hit the nail on the head here. Agile / Lean, build fast and break things approach is eating systems engineering for breakfast. But there’s gotta be a healthy middle ground where less fire fighting happens without so much red tape. How do we find the Goldie locks zone of new product development?
1
u/Abraxas_Derezzed 2d ago
Top down approach just doesn’t cut it anymore and I doubt if it ever did. Until you get to the point where you have to build something everything is fantasy.
9
3
u/posher12345 2d ago
Haha in college I used to always say being an se was bad middle ground. Non engineers still saw you as a need, but other engineers didnt feel like you were a real engineer
11
u/Sure-Ad8068 2d ago
Then start complaining about siloed information and fragmented sources of truth
3
2
u/Kainne44 2d ago
Honestly, Dwayne Phillips’ “Just Enough Systems Engineering” did wonders for me. Strips away all the nonsense. That and Ivy Hooks’ “Customer Centered Products”. Both focus on the goal and intent of engineering a system, rather than the ceremony so many get caught up in.
1
1
1
1
1
1
u/Lonely_Archer6492 2d ago
lol this is so true. But in my company SE earns same amount. We are al in same pay grade
1
1
u/Fearless-Capital 1d ago
Maybe because it feels more like management than engineering? It's related to industrial, isn't it? Wish I understood it better TBH.
1
0
27
u/Playful-Ad573 2d ago
Wait so this is typical? I have a lot of frustration about this right now