9 ms·

Systems Engineering, or "why james gets paid"

260 points by stephendause 4y ago

stephendause 4y ago
This is a blog post from a consultant I work with. I found it helpful to get a basic grasp of how to manage the systems engineering process in a way that is lightweight and flexible.
- MilStdJunkie 4y ago
  I'm glad this exists. I've been a gadfly among a dozen or so different "Top Down Systems Engineering Model Based" organizations - circulating maybe a hundred different management fads - and it's telling that the basic rules laid out in the article I've rarely seen followed or even realized. Except for one time, when the United States Army Aviation Safety Office took the reins and corralled all the panicked cats and dead-eyed MBA drones. The integrator that was in charge is still one of my favorite engineers of all time. "The hell this has forty parameters? It's fuel. Am I outta gas? Yes. No. That's the parameter." tosses paper down table, picks up next paper. Hammered out a doc system for that guy on the fly, something that everyone could see without paying 50k in license costs, and worked my ass off but felt better than I had in years. That kind of magic doesn't happen often, but you gotta save it in your mental cabinet of treasures when it does.
  - sitzkrieg 4y ago
    people like that put fulltime CAMEO mickey mouse modellers out of business
  - a_square_peg 4y ago
    I really would have liked to work with someone like that. Funny enough, this also (over-regimented documentation and too many requirements) also happens in small organizations when they don't have the expertise to know doing systems engineering isn't to produce a pile of documents. Unless it's driven by someone from higher up, it's an uphill battle to say that we can get rid of 90% of requirements that's just a repeat of some section from different standards.
  - Spooky23 4y ago
    I love the “mental cabinet of treasures”. What usually happens is that consultants are selling time, not outcomes. So it is in their interest to waste time and minimize risk to themselves. I’ve had experiences like yours a few times, most recently during the nadir of COVID. It felt great.
- gilbetron 4y ago
  Ah, a consultant. Not someone that actually builds systems, but makes money convincing people how they should build systems.
  - davidhyde 4y ago
    I think you’ll find that James is quite hands on when it comes to building embedded systems in Rust. Just look through his other blog posts and the kind of content he puts up on YouTube.
- Kinrany 4y ago
  > This gets a little weird in the time between "the requirements say what the system will do", and "the requirements say what the system does do". That's a longer topic for another day. Is there a follow-up? This is a crucial piece. You clearly need all of these: current state, plans for the future, past states, past plans.
  - jamesmunns 4y ago
    I'm continuing to write on my cohost page! I haven't answered this yet, but plan to in the future. Also happy to take any direct questions here, or by email (it's in my profile)
Rochus 4y ago
A look at a relevant systems engineering standard such as IEEE 1220 and related literature (see e.g. https://www.quora.com/Which-one-is-a-good-book-to-learn-Systems-Engineering/answer/Rochus-Keller https://www.quora.com/Which-one-is-a-good-book-to-learn-Syst...) is recommended. The field and its methods are well defined and even standardized.
- froh 4y ago
  I love the NASA systems engineering handbook. The pdf is in the public domain, I sent it to a printer, had it bound as hardcover, ribbon bookmarks, I love it.
  - Rochus 4y ago
    Yes, it's a great book indeed; unfortunately they removed a lot of very useful stuff in the second edition; some of it went into other books, but unfortunately not everything; this may be because fewer and fewer people are willing to read for themselves; this is also noticeable in practice, where I meet more and more people who have obviously never heard of the fundamental works of the discipline.
pkrumins 4y ago
I identify as a UNIX system.
0x445442 4y ago
What the author is describing is engineering and thus, orthogonal to 90% of software projects in "The Enterprise" which tend to be more of a Cargo Cult where information exists as Tribal Knowledge.
j_not_j 4y ago
I really like his two rules. They are much simpler than the usual collection of process and product definitions that usually come up. Of course, elaborating in further detail is essential. Of course, the contrarian position includes the fact that true system engineering organizations are actually publishing houses, producing hundreds or thousands of formalized documents. The actual systems created are byproducts. /s
prattatx 4y ago
3. Be explicit about who you are building the system for I have not yet run across a prototype or a product that does not have a producer and a consumer. Nor have I seen one yet that works for everyone on this planet. Chapanis 1996 might be a good read.
- m463 4y ago
  Sometimes walking around the apple store, do you really want to know? It might be for your annoying nephew, the one who changes technology like underwear. It's not for you, the one who keeps the same phone for 10 years. :) (worse, it is for advertisers, or stockholders)
  - prattatx 4y ago
    Right? Funny thing is my annoying nephew’s eyes can see the small text on that new iPhone without adjusting the default font. I of course have to. But at least I’m not color blind.
hnrodey 4y ago
This is a beautiful post and I agree with all of it 100%. Thank you.
Merrill 4y ago
System engineering is the art of specifying the general, overall characteristics and design of the thing to be produced without overlooking any detail which may later turn out to have been important.
LifeIsBio 4y ago
I've found that people have wildly different definitions of "systems engineering", but this one is lovely. And also, very close to my own. ;) https://jessimekirk.com/blog/whats_a_systems_engineer/ https://jessimekirk.com/blog/whats_a_systems_engineer/
iancmceachern 4y ago
My favorite definition for systems engineering is "the management of complexity"
- Rochus 4y ago
  hopefully not only "management"
  - m463 4y ago
    leadership of complexity?
    - arthurcolle 4y ago
      Development of complexity
      - jerkstate 4y ago
        Complexity Engineering?
      - froh 4y ago
        sounds as if we produce complexity (instead of navigating and reducing it)
        arthurcolle 4y ago
        Yeah that's the point
    - Rochus 4y ago
      Why not just use one of the established definitions? E.g. ISO/IEC/IEEE 24765:2017 defines systems engineering (SE) as "interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution, and to support that solution throughout its life". Or - if you prefer - the definition provided by INCOSE (https://www.incose.org/systems-engineering https://www.incose.org/systems-engineering): "Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods."
atribecalledqst 4y ago
I work as a systems engineer, so it always tickles me to see the rare SE-related link make the front page of HN. I think my org is pretty good at the informal SE process described in TFA. We used to be more strict about it, and I definitely remember hearing the term "model-based systems engineering" when I was interviewing, and after I started. Fancy UML generator tools, the works. But we've gradually become more informal and I don't particularly feel like we've lost anything in the process. One thing we are bad at, though, is onboarding. We have some very basic first-day-type documents, to get newbies started on domain knowledge. But the standards we hold employees to and how our work is done on a daily basis... is pretty much not written down at all! (actually some of it may be, but scattered throughout Wiki pages, probably out of date, and definitely no central document with all the necessary links...) Incidental to TFA, my org generally considers people (like James) who can do both the software work and the SE work unicorns. I personally started on the SE side with almost no software ability, but gradually clawed my way up to a decent level of technical competency, and it continues to be my competitive advantage. I don't code on a daily basis, but I do fix bugs & work on small features every once in a while. I dream about setting up a crash course to get my colleagues on the same path I took (currently I'll take a few hours here and there to help individuals pick up the skills) Kind of curious what other peoples' experience is on this point. Is it normal in other orgs for SEs to not also be good coders?
- sizzzzlerz 4y ago
  I started out writing software after graduating with a EE degree. For 5-10 years, I wrote software and led some small teams. I then transitioned to being a SW SE, working with project SEs to allocate system requirements to software, writing software development plan, and software test procedures. The final 20 years of my career, I became an SE and principal SE, doing the whole SE dance. During that entire time, I still wrote software for testing purposes, simulations, and algorithm development. Am I a good coder? I think so. Although the development teams use C++ and Python, I'm fine with C and Python. And even though my code could be considered to be "throw away", I try and use a common methodology for developing it. BTW, I like the term "unicorn". I'd never heard it in this context before.
- billfruit 4y ago
Jtsummers 4y ago
Systems engineering is an interdisciplinary field with an emphasis on synthesizing an understanding of a system by integrating all the ideas across the various disciplines involved. That is, construction a model of the system (for the engineer themselves and the people they work for and the people actually building the system and the people who will be using and maintaining the system). It's not just requirements and specs, but actually communicating and coordinating with real specialists because the SE will have a holistic view of the system, but won't be an expert in each of: astrodynamics, materials engineering, computer engineering (as in the digital logic part), mechanical engineering, chemical engineering, software, aerodynamics, RF engineering, power engineering, and so on. The role of the systems engineer is to manage all this complexity and construct a sound model of the system(s) in question that can be communicated to others and used in development. Both of the final system and of the many intermediary prototypes and "spikes" (to borrow the XP term) needed to fully understand the system. Naur's Programming as Theory Building is a useful software-centric take on this topic: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf (I tried to submit it, but apparently another submission a few months back made it a dupe).
adave 4y ago
Typical SE, says some mumbo jumbo without providing a way to do it or even show examples of good vs bad. - Dev who has to actually understand what SE's are saying.
- jamesmunns 4y ago
  What would you like to know? I'm sort of writing as I go here, from scratch. You have to start somewhere. The problem is "good vs bad" is a little domain specific. I can show something that works for embedded, but it won't be perfect for some other domain.
throwawaaarrgh 4y ago
Everything he said resonates with me. Here's the magic sauce that nobody talks about though: Having one magic document that explains everything isn't good enough. Everyone "should" this, "should" that, isn't good enough. For this stuff to work well, you need real leadership. Leadership should not build consensus, take polls, or let structure grow slowly and organically. You know what structures grow organically? Mold. Know what doesn't? Steel. Don't grow mold; build steel. Use the precise amount of material, at the right temperature and pressure, follow the right workflow, and inspect the result, then ship it with confidence. Don't hope it gets done; ensure it. Leadership needs to force everyone to use the one magic doc, to follow the one magic process, and take training to be able to immediately and effectively work with them, without wandering around wondering how to do what's expected of them. Otherwise your teams/org will forever be slow, inconsistent, and buggy. Systems are a result of humans doing work. The better organized the work, the better organized the system.
- taurath 4y ago
  Examples of this in practice? I've never seen a magic doc for a large org that changes strategy frequently that is up to date for more than a year.
  - froh 4y ago
    the doc should describe how you collaborate. and that shouldn't change direction frequently. systems engineering is much less about the deliverables than about how you collaborate to build them, how you ensure consistency, how you walk that talk.
    - throwawaaarrgh 4y ago
      And one great public example is The GitLab Handbook
- Kinrany 4y ago
  You can't force people to update the doc when it gets out of date, can you? There are limits to what can realistically be done through coercion.
netmonk 4y ago
The more I dig into cybernetic (wiener), information theory, self emergence, collective intelligence and consciousness. The more as individual I have the intuition that people are “prisoner” of individualism. Fundamental paradigm of capitalism is to have a huge class of individual mass consumer. Prisoner of “individualism” to turn people in perfect consummer. The side effect is that, the concept of complexity, complex system, complex system dynamics, are totally stranger to most peoples. Mainstream rationalism is based on direct causal relation between two elements. But this framework of though and analysis is very limited and has very low fertility in term of complex system. Mostly cause most interesting features or beneficial properties of collective dynamic aren’t possible not understandable with mainstream rationality. Let’s take an exemple: water. Water is matter, and matter in physics has three common state, either solid, either liquid, either gaz (we not gonna talk about plasma). Can a single molecule of water be solid, or liquid, or gaz ? None of them. A single molecule is in undefined state of matter. If so, can two isolated molecules of water can be in those states ? Nope again. For physics, phase properties turning a set of water molecule into matter in one of those three states appears when the minimal set of molecule of water is 21. So matter properties aren’t existing in a set of water molecules lower than having 21 ones of them. If you aren’t aware of the works of Micheal Levin in morphogenesis and cellular self organisation, collective intelligence in tissue formation, I really push you to listen to the few interview of him on youtube. How a set of cells are starting to communicate to collectively self organise and produce a complex living organism with demonstrating special intelligence, reproduction and adaptation is a real miracle. None of those individual cells are able to do that alone, only when they start to communicate and build a cohesive group. Why do I tell those things ? Cause from my perspective, there isn’t any difference between those cells and human, there isn’t any difference between those cells and company. And each time I look back to my 20years in IT working in complex platform (finance or payment industry) I can only state that system engineering, should be renamed complex system engineering. The final product (either a platform providing service, or a physical item) is the result of a collective intelligence trying to self organise and expand itself. So the product is fully part of this collective intelligence as a growth bénéfice. And is fully part of this collective intelligence. It’s like quantum mechanic: the witness of the experiment is part of the experiment. He is not indépendant and neutral. Therefor the system engineer designing a system is not neutral, as far as the set of all individuals in a company aren’t neutral and indépendant of synthesis of their own collective intelligence whose téléologie is to give birth into a product (either service or goods) So in conclusion, the human environment is part of the complex dynamical system, and the complexity (information level) in the outcome (product) is often deeply tied of the complexity of the collective intelligence producing it. So system engineering should not only focus on the outcome only. Like a system engineer designing a platform for a service, but consider that the company, the product, and customer, and the world outside all those element are a super organism far more complex than the product itself, and therefore should ensure that the superstructure has all the condition for the emergence of this super organism and make it viable.
bryanrasmussen 4y ago
wasn't I just reading yesterday that the systems engineer gets paid less than the web developer nowadays?` IF so, why is James not getting paid?
- DoingIsLearning 4y ago
  This has nothing to do with James' role but with economy of scale. If James works on an IOT widget the company will probably manufacturer a few hundred thousand devices and hopefully profit a few million. If Steve is working for Spotify, with 130 million MAU, whatever Steve produces is not linearly scaled with the physical manufacturing of a widget. Arguably operational costs go up with number of users but the cost is much more invariant in it's relation to total MAU. This means that whatever Steve decides to charge Spotify, will always be a literal drop in a bucket for their budget. It's the same reason VC's pour money into SaaS and social media apps but tread very carefully before investing in companies making physical things.
  - bryanrasmussen 4y ago
    Thank you, that was a pretty clarifying explanation.
- jamesmunns 4y ago
  Hi, I am James, and I do in fact get paid. That being said: I do this as a consultant, and my official job title has never been "system engineer" (usually some flavor of software engineer).
magic_hamster 4y ago
There is quite a lot of good advice here, however with one caveat. Documents require constant maintenance, and a "living" document that several people can edit is probably contradictory to the "always stay accurate" principle. Not everyone shares the same mental model of the project and sometimes things change but not everyone knows at once. You can choose an accurate document that doesn't change often, or an accurate-ish "dynamic" document that is managed by a single entity, or a document editable by more people. You can't have a perfectly accurate document that's also changing constantly and is managed by multiple parties. As a side note, thank you for not coming up with silly acronyms for everything.
- froh 4y ago
  you manage the consistency of the "artefacts", at a sufficiently fine granularity, using anchors and pointers and some semantic versioning of each, so you can contain rippling effects (fix a typo vs just add sth vs overhaul a part). and in that tracking you also capture the "known deviations", like 'this need isn't fulfilled yet, at all'. thus you document the "state of the union" of the whole thing, which for a living collaborative work is all you can wish for. This is the idea behind "requirements management" and "requirements tracing". Alas, there are few tools out there doing this with a low barrier to entry, cli like. here is one I'm aware of: https://github.com/itsallcode/openfasttrace https://github.com/itsallcode/openfasttrace
- yasuocidal 4y ago
  Having multiple "opinions" or "views" on a certain thing,can make you "see the average" and get a very accurate representation of the situation. Yes i agree that most of the times there are people messing around and can "hurt" that average, but on the other side it is another perspective on the situation. Having a constant flow of these data can make a pretty accurate "end-product" document.
a_c 4y ago
Guess who needs more system engineering training than software engineers? HR. Designing the organization is system engineering. You are building a complex machine with human, where flow of human, their rewards, and various "processes" are the knobs. And if I am to wager, HR is also the department people got issues with the most. Some of you may say HR aren't the only one involved in designing the orgainization and you are right. Many in the management also do. > Be explicit about what you are building This. When you are in position to form a team, be conscious about what problem you are to solve. Organization wise, take business unit for example (forget HR, finance, compliance and legal for a moment), are you forming a team to PoC a new product line, to handle part of the customer journey, to build a service or to build a feature. How are the team carving up the boundary with other existing teams. When "refactoring" is needed. Companies at different stages should form team accordingly. One way for me to judge one's acumen is whether they question the chesterton's fence - why a team exist and what problem they are solving. The same applies for engineers, why a component exist and what problem they are solving. There are a lot of similarities in designing a software component and an organization. One with code, one with people. More often than not, your code is also written by people.
- ChuckNorris89 4y ago
  Huh? Where I live HR isn't building anything. The staff architecture is decided by the management and department heads according to the hiring budget they received from the bean counters. HR just handles basic hiring and firing paperwork and organizing meetings and Interviews, that's it.
- jamesmunns 4y ago
  Systems of people are systems too :) You might like my follow up, where I touch on this: https://cohost.org/jamesmunns/post/178752-systems-engineering https://cohost.org/jamesmunns/post/178752-systems-engineerin... I have a lot more to say about how ignoring the people aspect of things is wrong for a lot of reasons.
jacksonkmarley 4y ago
This is really interesting to me because my previous job had a big project, and they started writing down the documentation up front with the goal of specifying everything and getting it all reviewed and signed off. Years later everyone panicked because the documentation was still in progress and nothing had been implemented. Perhaps the missing sauce was a good systems engineer advising the bosses? How do successful projects avoid this sort of problem? Is it common? It was really frustrating to be a contributor knowing that the whole thing was a disaster but not knowing if your ideas to make things better were useful or a waste of time, even if you could get anyone to listen.
pif 4y ago
> But, at all times, your requirements/specification must be accurate. > > If the requirements say "the system does X", the electrical engineers must be free to use this assumption, without talking to the software engineers. The sales people must be able to put this in the marketing docs, without having to guess. Fine, sounds nice! A team that can work without a communication overflow, that's wonderful! A few lines later: > Requirements should be a living document. He lost me here. On one side, he preaches for a "source of truth" that everybody can read and take autonomous decision accordingly; on the other side, he recognizes that the "truth" has the horrible tendency to drift with time. He just misses the elephant in the room: what do you do after you updated the document? How do you track all the assumptions that every team member has made based on that item that you have just changed? What useful is an accurate document if you can't trust it won't change? Requirement/specification change is the bane of every complex engineering challenge, and acknowledging it while proposing to ignore it cannot be a solution.
- jamesmunns 4y ago
  Hey, author here :) Requirements changing are a reality. In safety critical fields, these changes are noticed by using traceability tools. I haven't written this far yet: but you should have a process for changing things like system requirements. It should be discussed, reviewed, and approved by the relevant teams. The "downstream" documents, like software or hardware reqs, should be updated as well. Hard to fit all the details in a single summary, but happy to answer questions
hulitu 4y ago
> If the requirements say "the system does X", the electrical engineers must be free to use this assumption, without talking to the software engineers. This is the source of most problems: System defines something while HW and SW each come with their own implementation which contradicts each other. System engineering has evolved into a sort of abstractive art, when only those who went to art school can underestand the abstractive painting.
jfalcon 4y ago
I still call myself a "Systems Engineer" despite my role being usurped by HR and middle management into the 'new' hotness: "Site Reliability Engineer". Thanks to people doing DevOps burning out, it's like an ongoing joke/question as to what 'DevOps' is vs. 'SRE' when in fact it was all work that a 'Systems Engineer' performed prior to someone in middle management working with HR to justify their roles changed my title despite the work not changing a bit during their bi-annual "reorganization". As someone who is on the hunt for a new place to land, it drives me crazy how the title doesn't match the role description and often when you interview there are times when it doesn't even match the expectations. And the depressing part is that it's difficult to even find "Systems Engineering" jobs unless it's with another industry with different skill sets all together. But as managers are likely finding out now, most developers don't want to do Systems Engineering as it's a cross-team discipline to pull all the resources together and operate complex systems with greater proficiency (in many different metrics) and maintain service delivery (in multiple other metrics). What has been interesting is this resurgence in people trying to figure out what "Ops" and "SE" did for developers that they have been thrown into doing and learning how little they actually knew. Partly our own fault, of course, as nobody really wants to know how the sausage is made. But they also didn't envision where our sights were set in the future once we got people doing more self-service resource and code deployment. That just getting the apps launch were just the beginning, that to deliver robust code requires metric gathering, SLA, Chaos Engineering, how to get the right metrics tracked and to look at all the signals as a organism to teach machines how to heal themselves. But it always comes back to respecting the process while pushing forward education of the people taking part in it. Tearing down the silos while also demonstrating often the value of engineers who know everything but their app/service/code - yet is able to learn it and architect solutions.
jdlshore 4y ago
I’ve found hardware-oriented businesses to be woefully behind the times when it comes to software engineering processes. This article is no exception. Although I agree with his overall framing, once you get to the details, James is describing a document-oriented approach that was in vogue about 25 years ago, and has long since been superseded. What replaced it? Agile. Wait, don’t throw rotten vegetables—I’m not talking about the overwrought excuse for micromanagement people call “Agile” nowadays, but the truly innovative thinking that was happening in the late 90s and early 2000s. Stuff like the Poppendiecks’ Lean Software Development (based on their experience at 3M) and Cockburn’s Agile Software Development (based on research he originally conducted at IBM). And of course Beck’s Extreme Programming, based in part on his work with Ward Cunningham at Tektronix. These processes and thinking started with the reality that it’s impossible, given a large, complex system, to correctly specify everything in advance. They recognized that documents are a particularly poor communication medium—one that’s time-consuming to create and consume, and very difficult to do in a way that isn’t misunderstood. Instead, they focused on people as more important than process, and adaptation as more important than prediction. Traditional SDLCs fell by the wayside, and for good reason: they didn’t work well. Their document-heavy approach resulted in poor visibility for management and software that met the spec but not customer needs. I talk about this more in my book. The first chapter talks about how and why Agile supplanted traditional processes. It’s free online (along with a lot of other material) here: https://www.jamesshore.com/v2/books/aoad2/what_is_agile https://www.jamesshore.com/v2/books/aoad2/what_is_agile

260 points by stephendause 4y ago

This is a blog post from a consultant I work with. I found it helpful to get a basic grasp of how to manage the systems engineering process in a way that is lightweight and flexible.

MilStdJunkie 4y ago
I'm glad this exists. I've been a gadfly among a dozen or so different "Top Down Systems Engineering Model Based" organizations - circulating maybe a hundred different management fads - and it's telling that the basic rules laid out in the article I've rarely seen followed or even realized. Except for one time, when the United States Army Aviation Safety Office took the reins and corralled all the panicked cats and dead-eyed MBA drones. The integrator that was in charge is still one of my favorite engineers of all time. "The hell this has forty parameters? It's fuel. Am I outta gas? Yes. No. That's the parameter." tosses paper down table, picks up next paper. Hammered out a doc system for that guy on the fly, something that everyone could see without paying 50k in license costs, and worked my ass off but felt better than I had in years. That kind of magic doesn't happen often, but you gotta save it in your mental cabinet of treasures when it does.
- sitzkrieg 4y ago
  people like that put fulltime CAMEO mickey mouse modellers out of business
- a_square_peg 4y ago
  I really would have liked to work with someone like that. Funny enough, this also (over-regimented documentation and too many requirements) also happens in small organizations when they don't have the expertise to know doing systems engineering isn't to produce a pile of documents. Unless it's driven by someone from higher up, it's an uphill battle to say that we can get rid of 90% of requirements that's just a repeat of some section from different standards.
- Spooky23 4y ago
  I love the “mental cabinet of treasures”. What usually happens is that consultants are selling time, not outcomes. So it is in their interest to waste time and minimize risk to themselves. I’ve had experiences like yours a few times, most recently during the nadir of COVID. It felt great.
gilbetron 4y ago
Ah, a consultant. Not someone that actually builds systems, but makes money convincing people how they should build systems.
- davidhyde 4y ago
  I think you’ll find that James is quite hands on when it comes to building embedded systems in Rust. Just look through his other blog posts and the kind of content he puts up on YouTube.
Kinrany 4y ago
> This gets a little weird in the time between "the requirements say what the system will do", and "the requirements say what the system does do". That's a longer topic for another day. Is there a follow-up? This is a crucial piece. You clearly need all of these: current state, plans for the future, past states, past plans.
- jamesmunns 4y ago
  I'm continuing to write on my cohost page! I haven't answered this yet, but plan to in the future. Also happy to take any direct questions here, or by email (it's in my profile)

Rochus 4y ago

A look at a relevant systems engineering standard such as IEEE 1220 and related literature (see e.g. https://www.quora.com/Which-one-is-a-good-book-to-learn-Systems-Engineering/answer/Rochus-Keller https://www.quora.com/Which-one-is-a-good-book-to-learn-Syst...) is recommended. The field and its methods are well defined and even standardized.

froh 4y ago
I love the NASA systems engineering handbook. The pdf is in the public domain, I sent it to a printer, had it bound as hardcover, ribbon bookmarks, I love it.
- Rochus 4y ago
  Yes, it's a great book indeed; unfortunately they removed a lot of very useful stuff in the second edition; some of it went into other books, but unfortunately not everything; this may be because fewer and fewer people are willing to read for themselves; this is also noticeable in practice, where I meet more and more people who have obviously never heard of the fundamental works of the discipline.

pkrumins 4y ago

I identify as a UNIX system.

0x445442 4y ago

What the author is describing is engineering and thus, orthogonal to 90% of software projects in "The Enterprise" which tend to be more of a Cargo Cult where information exists as Tribal Knowledge.

j_not_j 4y ago

I really like his two rules. They are much simpler than the usual collection of process and product definitions that usually come up. Of course, elaborating in further detail is essential. Of course, the contrarian position includes the fact that true system engineering organizations are actually publishing houses, producing hundreds or thousands of formalized documents. The actual systems created are byproducts. /s

prattatx 4y ago

3. Be explicit about who you are building the system for I have not yet run across a prototype or a product that does not have a producer and a consumer. Nor have I seen one yet that works for everyone on this planet. Chapanis 1996 might be a good read.

m463 4y ago
Sometimes walking around the apple store, do you really want to know? It might be for your annoying nephew, the one who changes technology like underwear. It's not for you, the one who keeps the same phone for 10 years. :) (worse, it is for advertisers, or stockholders)
- prattatx 4y ago
  Right? Funny thing is my annoying nephew’s eyes can see the small text on that new iPhone without adjusting the default font. I of course have to. But at least I’m not color blind.

hnrodey 4y ago

This is a beautiful post and I agree with all of it 100%. Thank you.

Merrill 4y ago

System engineering is the art of specifying the general, overall characteristics and design of the thing to be produced without overlooking any detail which may later turn out to have been important.

LifeIsBio 4y ago

I've found that people have wildly different definitions of "systems engineering", but this one is lovely. And also, very close to my own. ;) https://jessimekirk.com/blog/whats_a_systems_engineer/ https://jessimekirk.com/blog/whats_a_systems_engineer/

iancmceachern 4y ago

My favorite definition for systems engineering is "the management of complexity"

Rochus 4y ago
hopefully not only "management"
- m463 4y ago
  leadership of complexity?
  - arthurcolle 4y ago
    Development of complexity
    - jerkstate 4y ago
      Complexity Engineering?
    - froh 4y ago
      sounds as if we produce complexity (instead of navigating and reducing it)
      - arthurcolle 4y ago
        Yeah that's the point
  - Rochus 4y ago
    Why not just use one of the established definitions? E.g. ISO/IEC/IEEE 24765:2017 defines systems engineering (SE) as "interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution, and to support that solution throughout its life". Or - if you prefer - the definition provided by INCOSE (https://www.incose.org/systems-engineering https://www.incose.org/systems-engineering): "Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods."

atribecalledqst 4y ago

I work as a systems engineer, so it always tickles me to see the rare SE-related link make the front page of HN. I think my org is pretty good at the informal SE process described in TFA. We used to be more strict about it, and I definitely remember hearing the term "model-based systems engineering" when I was interviewing, and after I started. Fancy UML generator tools, the works. But we've gradually become more informal and I don't particularly feel like we've lost anything in the process. One thing we are bad at, though, is onboarding. We have some very basic first-day-type documents, to get newbies started on domain knowledge. But the standards we hold employees to and how our work is done on a daily basis... is pretty much not written down at all! (actually some of it may be, but scattered throughout Wiki pages, probably out of date, and definitely no central document with all the necessary links...) Incidental to TFA, my org generally considers people (like James) who can do both the software work and the SE work unicorns. I personally started on the SE side with almost no software ability, but gradually clawed my way up to a decent level of technical competency, and it continues to be my competitive advantage. I don't code on a daily basis, but I do fix bugs & work on small features every once in a while. I dream about setting up a crash course to get my colleagues on the same path I took (currently I'll take a few hours here and there to help individuals pick up the skills) Kind of curious what other peoples' experience is on this point. Is it normal in other orgs for SEs to not also be good coders?

sizzzzlerz 4y ago
I started out writing software after graduating with a EE degree. For 5-10 years, I wrote software and led some small teams. I then transitioned to being a SW SE, working with project SEs to allocate system requirements to software, writing software development plan, and software test procedures. The final 20 years of my career, I became an SE and principal SE, doing the whole SE dance. During that entire time, I still wrote software for testing purposes, simulations, and algorithm development. Am I a good coder? I think so. Although the development teams use C++ and Python, I'm fine with C and Python. And even though my code could be considered to be "throw away", I try and use a common methodology for developing it. BTW, I like the term "unicorn". I'd never heard it in this context before.
billfruit 4y ago

Jtsummers 4y ago

Systems engineering is an interdisciplinary field with an emphasis on synthesizing an understanding of a system by integrating all the ideas across the various disciplines involved. That is, construction a model of the system (for the engineer themselves and the people they work for and the people actually building the system and the people who will be using and maintaining the system). It's not just requirements and specs, but actually communicating and coordinating with real specialists because the SE will have a holistic view of the system, but won't be an expert in each of: astrodynamics, materials engineering, computer engineering (as in the digital logic part), mechanical engineering, chemical engineering, software, aerodynamics, RF engineering, power engineering, and so on. The role of the systems engineer is to manage all this complexity and construct a sound model of the system(s) in question that can be communicated to others and used in development. Both of the final system and of the many intermediary prototypes and "spikes" (to borrow the XP term) needed to fully understand the system. Naur's Programming as Theory Building is a useful software-centric take on this topic: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf (I tried to submit it, but apparently another submission a few months back made it a dupe).

adave 4y ago

Typical SE, says some mumbo jumbo without providing a way to do it or even show examples of good vs bad. - Dev who has to actually understand what SE's are saying.

jamesmunns 4y ago
What would you like to know? I'm sort of writing as I go here, from scratch. You have to start somewhere. The problem is "good vs bad" is a little domain specific. I can show something that works for embedded, but it won't be perfect for some other domain.

throwawaaarrgh 4y ago

Everything he said resonates with me. Here's the magic sauce that nobody talks about though: Having one magic document that explains everything isn't good enough. Everyone "should" this, "should" that, isn't good enough. For this stuff to work well, you need real leadership. Leadership should not build consensus, take polls, or let structure grow slowly and organically. You know what structures grow organically? Mold. Know what doesn't? Steel. Don't grow mold; build steel. Use the precise amount of material, at the right temperature and pressure, follow the right workflow, and inspect the result, then ship it with confidence. Don't hope it gets done; ensure it. Leadership needs to force everyone to use the one magic doc, to follow the one magic process, and take training to be able to immediately and effectively work with them, without wandering around wondering how to do what's expected of them. Otherwise your teams/org will forever be slow, inconsistent, and buggy. Systems are a result of humans doing work. The better organized the work, the better organized the system.

taurath 4y ago
Examples of this in practice? I've never seen a magic doc for a large org that changes strategy frequently that is up to date for more than a year.
- froh 4y ago
  the doc should describe how you collaborate. and that shouldn't change direction frequently. systems engineering is much less about the deliverables than about how you collaborate to build them, how you ensure consistency, how you walk that talk.
  - throwawaaarrgh 4y ago
    And one great public example is The GitLab Handbook
Kinrany 4y ago
You can't force people to update the doc when it gets out of date, can you? There are limits to what can realistically be done through coercion.

netmonk 4y ago

The more I dig into cybernetic (wiener), information theory, self emergence, collective intelligence and consciousness. The more as individual I have the intuition that people are “prisoner” of individualism. Fundamental paradigm of capitalism is to have a huge class of individual mass consumer. Prisoner of “individualism” to turn people in perfect consummer. The side effect is that, the concept of complexity, complex system, complex system dynamics, are totally stranger to most peoples. Mainstream rationalism is based on direct causal relation between two elements. But this framework of though and analysis is very limited and has very low fertility in term of complex system. Mostly cause most interesting features or beneficial properties of collective dynamic aren’t possible not understandable with mainstream rationality. Let’s take an exemple: water. Water is matter, and matter in physics has three common state, either solid, either liquid, either gaz (we not gonna talk about plasma). Can a single molecule of water be solid, or liquid, or gaz ? None of them. A single molecule is in undefined state of matter. If so, can two isolated molecules of water can be in those states ? Nope again. For physics, phase properties turning a set of water molecule into matter in one of those three states appears when the minimal set of molecule of water is 21. So matter properties aren’t existing in a set of water molecules lower than having 21 ones of them. If you aren’t aware of the works of Micheal Levin in morphogenesis and cellular self organisation, collective intelligence in tissue formation, I really push you to listen to the few interview of him on youtube. How a set of cells are starting to communicate to collectively self organise and produce a complex living organism with demonstrating special intelligence, reproduction and adaptation is a real miracle. None of those individual cells are able to do that alone, only when they start to communicate and build a cohesive group. Why do I tell those things ? Cause from my perspective, there isn’t any difference between those cells and human, there isn’t any difference between those cells and company. And each time I look back to my 20years in IT working in complex platform (finance or payment industry) I can only state that system engineering, should be renamed complex system engineering. The final product (either a platform providing service, or a physical item) is the result of a collective intelligence trying to self organise and expand itself. So the product is fully part of this collective intelligence as a growth bénéfice. And is fully part of this collective intelligence. It’s like quantum mechanic: the witness of the experiment is part of the experiment. He is not indépendant and neutral. Therefor the system engineer designing a system is not neutral, as far as the set of all individuals in a company aren’t neutral and indépendant of synthesis of their own collective intelligence whose téléologie is to give birth into a product (either service or goods) So in conclusion, the human environment is part of the complex dynamical system, and the complexity (information level) in the outcome (product) is often deeply tied of the complexity of the collective intelligence producing it. So system engineering should not only focus on the outcome only. Like a system engineer designing a platform for a service, but consider that the company, the product, and customer, and the world outside all those element are a super organism far more complex than the product itself, and therefore should ensure that the superstructure has all the condition for the emergence of this super organism and make it viable.

bryanrasmussen 4y ago

wasn't I just reading yesterday that the systems engineer gets paid less than the web developer nowadays?` IF so, why is James not getting paid?

DoingIsLearning 4y ago
This has nothing to do with James' role but with economy of scale. If James works on an IOT widget the company will probably manufacturer a few hundred thousand devices and hopefully profit a few million. If Steve is working for Spotify, with 130 million MAU, whatever Steve produces is not linearly scaled with the physical manufacturing of a widget. Arguably operational costs go up with number of users but the cost is much more invariant in it's relation to total MAU. This means that whatever Steve decides to charge Spotify, will always be a literal drop in a bucket for their budget. It's the same reason VC's pour money into SaaS and social media apps but tread very carefully before investing in companies making physical things.
- bryanrasmussen 4y ago
  Thank you, that was a pretty clarifying explanation.
jamesmunns 4y ago
Hi, I am James, and I do in fact get paid. That being said: I do this as a consultant, and my official job title has never been "system engineer" (usually some flavor of software engineer).

magic_hamster 4y ago

There is quite a lot of good advice here, however with one caveat. Documents require constant maintenance, and a "living" document that several people can edit is probably contradictory to the "always stay accurate" principle. Not everyone shares the same mental model of the project and sometimes things change but not everyone knows at once. You can choose an accurate document that doesn't change often, or an accurate-ish "dynamic" document that is managed by a single entity, or a document editable by more people. You can't have a perfectly accurate document that's also changing constantly and is managed by multiple parties. As a side note, thank you for not coming up with silly acronyms for everything.

froh 4y ago
you manage the consistency of the "artefacts", at a sufficiently fine granularity, using anchors and pointers and some semantic versioning of each, so you can contain rippling effects (fix a typo vs just add sth vs overhaul a part). and in that tracking you also capture the "known deviations", like 'this need isn't fulfilled yet, at all'. thus you document the "state of the union" of the whole thing, which for a living collaborative work is all you can wish for. This is the idea behind "requirements management" and "requirements tracing". Alas, there are few tools out there doing this with a low barrier to entry, cli like. here is one I'm aware of: https://github.com/itsallcode/openfasttrace https://github.com/itsallcode/openfasttrace
yasuocidal 4y ago
Having multiple "opinions" or "views" on a certain thing,can make you "see the average" and get a very accurate representation of the situation. Yes i agree that most of the times there are people messing around and can "hurt" that average, but on the other side it is another perspective on the situation. Having a constant flow of these data can make a pretty accurate "end-product" document.

a_c 4y ago

Guess who needs more system engineering training than software engineers? HR. Designing the organization is system engineering. You are building a complex machine with human, where flow of human, their rewards, and various "processes" are the knobs. And if I am to wager, HR is also the department people got issues with the most. Some of you may say HR aren't the only one involved in designing the orgainization and you are right. Many in the management also do. > Be explicit about what you are building This. When you are in position to form a team, be conscious about what problem you are to solve. Organization wise, take business unit for example (forget HR, finance, compliance and legal for a moment), are you forming a team to PoC a new product line, to handle part of the customer journey, to build a service or to build a feature. How are the team carving up the boundary with other existing teams. When "refactoring" is needed. Companies at different stages should form team accordingly. One way for me to judge one's acumen is whether they question the chesterton's fence - why a team exist and what problem they are solving. The same applies for engineers, why a component exist and what problem they are solving. There are a lot of similarities in designing a software component and an organization. One with code, one with people. More often than not, your code is also written by people.

ChuckNorris89 4y ago
Huh? Where I live HR isn't building anything. The staff architecture is decided by the management and department heads according to the hiring budget they received from the bean counters. HR just handles basic hiring and firing paperwork and organizing meetings and Interviews, that's it.
jamesmunns 4y ago
Systems of people are systems too :) You might like my follow up, where I touch on this: https://cohost.org/jamesmunns/post/178752-systems-engineering https://cohost.org/jamesmunns/post/178752-systems-engineerin... I have a lot more to say about how ignoring the people aspect of things is wrong for a lot of reasons.

jacksonkmarley 4y ago

This is really interesting to me because my previous job had a big project, and they started writing down the documentation up front with the goal of specifying everything and getting it all reviewed and signed off. Years later everyone panicked because the documentation was still in progress and nothing had been implemented. Perhaps the missing sauce was a good systems engineer advising the bosses? How do successful projects avoid this sort of problem? Is it common? It was really frustrating to be a contributor knowing that the whole thing was a disaster but not knowing if your ideas to make things better were useful or a waste of time, even if you could get anyone to listen.

pif 4y ago

> But, at all times, your requirements/specification must be accurate. > > If the requirements say "the system does X", the electrical engineers must be free to use this assumption, without talking to the software engineers. The sales people must be able to put this in the marketing docs, without having to guess. Fine, sounds nice! A team that can work without a communication overflow, that's wonderful! A few lines later: > Requirements should be a living document. He lost me here. On one side, he preaches for a "source of truth" that everybody can read and take autonomous decision accordingly; on the other side, he recognizes that the "truth" has the horrible tendency to drift with time. He just misses the elephant in the room: what do you do after you updated the document? How do you track all the assumptions that every team member has made based on that item that you have just changed? What useful is an accurate document if you can't trust it won't change? Requirement/specification change is the bane of every complex engineering challenge, and acknowledging it while proposing to ignore it cannot be a solution.

jamesmunns 4y ago
Hey, author here :) Requirements changing are a reality. In safety critical fields, these changes are noticed by using traceability tools. I haven't written this far yet: but you should have a process for changing things like system requirements. It should be discussed, reviewed, and approved by the relevant teams. The "downstream" documents, like software or hardware reqs, should be updated as well. Hard to fit all the details in a single summary, but happy to answer questions

hulitu 4y ago

> If the requirements say "the system does X", the electrical engineers must be free to use this assumption, without talking to the software engineers. This is the source of most problems: System defines something while HW and SW each come with their own implementation which contradicts each other. System engineering has evolved into a sort of abstractive art, when only those who went to art school can underestand the abstractive painting.

jfalcon 4y ago

I still call myself a "Systems Engineer" despite my role being usurped by HR and middle management into the 'new' hotness: "Site Reliability Engineer". Thanks to people doing DevOps burning out, it's like an ongoing joke/question as to what 'DevOps' is vs. 'SRE' when in fact it was all work that a 'Systems Engineer' performed prior to someone in middle management working with HR to justify their roles changed my title despite the work not changing a bit during their bi-annual "reorganization". As someone who is on the hunt for a new place to land, it drives me crazy how the title doesn't match the role description and often when you interview there are times when it doesn't even match the expectations. And the depressing part is that it's difficult to even find "Systems Engineering" jobs unless it's with another industry with different skill sets all together. But as managers are likely finding out now, most developers don't want to do Systems Engineering as it's a cross-team discipline to pull all the resources together and operate complex systems with greater proficiency (in many different metrics) and maintain service delivery (in multiple other metrics). What has been interesting is this resurgence in people trying to figure out what "Ops" and "SE" did for developers that they have been thrown into doing and learning how little they actually knew. Partly our own fault, of course, as nobody really wants to know how the sausage is made. But they also didn't envision where our sights were set in the future once we got people doing more self-service resource and code deployment. That just getting the apps launch were just the beginning, that to deliver robust code requires metric gathering, SLA, Chaos Engineering, how to get the right metrics tracked and to look at all the signals as a organism to teach machines how to heal themselves. But it always comes back to respecting the process while pushing forward education of the people taking part in it. Tearing down the silos while also demonstrating often the value of engineers who know everything but their app/service/code - yet is able to learn it and architect solutions.

jdlshore 4y ago

I’ve found hardware-oriented businesses to be woefully behind the times when it comes to software engineering processes. This article is no exception. Although I agree with his overall framing, once you get to the details, James is describing a document-oriented approach that was in vogue about 25 years ago, and has long since been superseded. What replaced it? Agile. Wait, don’t throw rotten vegetables—I’m not talking about the overwrought excuse for micromanagement people call “Agile” nowadays, but the truly innovative thinking that was happening in the late 90s and early 2000s. Stuff like the Poppendiecks’ Lean Software Development (based on their experience at 3M) and Cockburn’s Agile Software Development (based on research he originally conducted at IBM). And of course Beck’s Extreme Programming, based in part on his work with Ward Cunningham at Tektronix. These processes and thinking started with the reality that it’s impossible, given a large, complex system, to correctly specify everything in advance. They recognized that documents are a particularly poor communication medium—one that’s time-consuming to create and consume, and very difficult to do in a way that isn’t misunderstood. Instead, they focused on people as more important than process, and adaptation as more important than prediction. Traditional SDLCs fell by the wayside, and for good reason: they didn’t work well. Their document-heavy approach resulted in poor visibility for management and software that met the spec but not customer needs. I talk about this more in my book. The first chapter talks about how and why Agile supplanted traditional processes. It’s free online (along with a lot of other material) here: https://www.jamesshore.com/v2/books/aoad2/what_is_agile https://www.jamesshore.com/v2/books/aoad2/what_is_agile