Writing intros are hard, so lets cut to the executive summary.
I work as a consultant. I usually work on projects that involve hardware (electronics and mechanical parts), but I usually help on the software side, from microcontroller code, up to desktop stuff, to server stuff sometimes.
Sometimes I get brought in to implement specific things, like drivers or proof of concepts. Sometimes I get brought in when people are looking to move to Rust. Sometimes I get brought in when people are looking to turn a "prototype" into a "product".
Usually, what I end up spending the most time helping people with are the fundamentals of systems engineering.
Maybe this is a case of "when the tool you have is a hammer, all problems look like nails". Maybe I've overdrank the Systems Engineering kool-aid.
That being said, it keeps working and being helpful, so I'm going to keep swinging that hammer.
I might want to write a book on this some day, but here's the start of some unsorted thoughts in the mean time.
I have nothing to sell you (yet), and I promise there are no magic bullets in these writings. Just some things to think about that might help you or your projects.
I am also not a process purist, or religiously tied to the concept of systems engineering. Sometimes doing a little of this work goes a long way. Sometimes (especially if you are doing something safety critical) you need to do everything to the full extent. Do what feels right. If it stops helping, find something else to do. Ideally, all of the concepts I'll describe should start paying dividends almost immediately.
What is Systems Engineering?
I dunno, NASA or someone probably has a better definition, but to me, it covers the domains of:
- Be explicit about what you are building
- Be explicit about how you are building it
That seems simple, right? Well, sometimes it is.
