354 karma · joined August 7, 2017
I'm keenly interested in product quality, and have broad experience in product definition, development and QA.
I'm a big proponent of DevOps, and have successfully applied it to less obvious fields such as embedded software.
My speciality is in embedded systems / IoT; I have a MEng in mechanical engineering.
I offer development process consulting, engineering support, and training on a variety of subjects.
find me at https://ingianni.eu
Kismet: 63a85e6b3b4c71066c36e8debc9a916fc2990dacbd6f3a590e3e94e86f6af8eb
Not true.
The automotive bus architectures I know first hand (admittedly far from all of them of course) have multiple CAN buses, plus other bus technologies as well (MOST/LIN/Ethernet).
I don't think it would even be possible from a bandwidth/latency standpoint to push everything across a single CAN bus.
The tool is just a detail. My point was rather that they are very much "code", and deserve to be treated as carefully as any other.
My notebooks also get refactored on occasion.
Yes and no.
An important idea is to principally check corner cases, where potential errors lurk.
What the corner cases are depends on the system under test, of course.
There are a few rules of thumb, such as if there are limits to the input, check around the limits (e.g. if your function under test expects a month as its input, do the obvious thing of checking month 1, 12, 0, 13, Null, "foo"). Or if your function takes a list, use the (0, 1, infinity) rule: try with the empty list, a list with one entry, and a list with "infinite" (in practice: very very many) entries. Etc.
But you also should try to get an understanding for the SUT, to find corner cases that are less obvious or cookie-cutter.
And have opinions on how efficient/throrough your test suite should be: does the function under test just provide decoration, or does it make life-and-death decisions? The effort invested in testing them would certainly differ based on this assessment.
Again, the ISTQB syllabus provides helpful guidance.
They are really practical for situations where you want to play around (er even outright work with) principally not with code, but that code's output.
You see, I give lots of trainings.
Notebooks offer me an excellent way to mix commands, their output, and explanations into a single document with little effort. I'm able to show my students exactly what happens (including the literal messages), going step-by-step.
They are wonderful to create exercises.
However, for my use case, the notebook is the output (perhaps rendered as PDF).
Rules I've adopted for my own training notebooks:
* the first lines are to print the versions of all things I'm using, e.g. "git --version" for git trainings
* I use "restart&run all" frequently
* obviously, notebooks are version-controlled, including their output
* before checking in, prove that "restart&run all" provides exactly the desired result
Go through it, and think about things like the seven testing principles.
If I were to interview you, I'd also throw a whiteboard-ish test at you: I'd pose a problem to you (say, I'd explain a function) and ask you to find test cases.
It's been my observation that this kind of exercise is pretty good at separating the wheat from the chaff: I could see who dares to ask questions, I could see who systematically walks the problem space, I could see who even thinks of testing not just the functional requirements, but also the non-functional ones. Most importantly, I could use this as a way into a discussion, and see how people carry themselves in such a (vaguely work-like) situation.
I suspect the interviews I conducted were on the more rigorous side, so you might be spared whiteboard tests, but in any case it can't hurt to to try and exercise actually creating and reasoning about test cases.
Also, it can't hurt to find out about the testing tools they use. Either you can find them outright, or you can at least make educated guesses about what they use based on the technologies they build their product on. Actually trying them out would be asking too much, but at least get a feel for what their purposes and limitations are.
Location: Munich, Germany
Remote: preferred
I'm an experienced (>10 years) software engineer with management experience. I have a master's in mechanical engineering.
I've found my calling in introducing modern methodologies to (not just, but particularly) embedded systems teams, including agile IoT development all the way to DevOps for embedded.
I've worked on all stages of embedded products, from product management, to specification, to coding, testing, and qualification. A lot of my career was spent working on safety-critical systems up to ASIL D / SIL4.
How I could help you:
* devise a strategy and implementation to improve your team's development processes
* train your team
* advise in improving the quality of your product
* create fast feedback loops all through the development cycle (DevOps)
* close gaps in your team's embedded development expertise
* training and advising several German Fortune 500 companies on DevOps philosophy, processes and implementation
* managing a small, experienced team in the development of an industrial robot
* advising a multinational company in the development of a highly safety-critical (ASIL D) automotive electronics component
* advising a startup in the IoT development tooling space
* coaching a startup team on improving their development workflow to increase speed and quality
At age 16 (or so), I dived into an undersea cave in Sardinia, pretty much completely unprepared.
I had scuba gear, but only a "waterproof" flashlight (read: not a proper diving lamp by any means), no line, no backups, no nothing. Just a teenager's sense of invincibility.
It was almost literally otherworldly, floating through bone-white passages full of strangely shaped rocks, and being so palpably close to my own fate.
It was also very scary for reasons both objective (I knew it was monumentally stupid going in) and imagined (the darkness beyond the cone of your lamp is full of sharks, giant kraken, and Cthulhu).
I turned around after five minutes. On the way back, noticed a fork in the cave. Had a horrible sinking feeling and cursed myself for not looking back on the way in. Picked a path at random, and apparently picked right.
It was the best experience I never want to repeat again.
Location: Munich, Germany
Remote: preferred
I'm an experienced (>10 years) software engineer with management experience. I have a master's in mechanical engineering.
I've found my calling in introducing modern methodologies to (not just, but particularly) embedded systems teams, including agile IoT development all the way to DevOps for embedded.
I've worked on all stages of embedded products, from product management, to specification, to coding, testing, and qualification. A lot of my career was spent working on safety-critical systems up to ASIL D / SIL4.
How I could help you:
* devise a strategy and implementation to improve your team's development processes
* train your team
* advise in improving the quality of your product
* create fast feedback loops all through the development cycle (DevOps)
* close gaps in your team's embedded development expertise
* training and advising several German Fortune 500 companies on DevOps philosophy, processes
and implementation
* managing a small, experienced team in the development of an industrial robot
* advising a multinational company in the development of a highly safety-critical (ASIL D)
automotive electronics component
* advising a startup in the IoT development tooling space
* coaching a startup team on improving their development workflow to increase speed and quality
While their offerings differ in the details, by and large they offer the same thigns as fastmail.
1. I'm a guitarist.
It's super annoying when a string breaks, even if I'm not using it. My fingers can feel even the adjacency of the string (vibrations, I'm guessing), and I lose all sense of orientation on the freatboard if one of the strings is gone, even if I'm not touching that string.
2. While I'm not a pilot, I spent years testing avionics.
Years later, I can still blindly, through muscle memory, replay sequences of commands in my mind, as actuated by mechanical buttons (LSKs) on either side of the display, and rotary encoders to "dial in" new values (e.g. frequencies).
I would usually run through the settings just with my hands, barely looking, and only double-check the settings as the last step, before actually committing to whatever action I was preparing.
I can't imagine doing something similar on a touchscreen without constantly havng to look.
I've been having connection trouble essentially all day.
As far as I can tell this has been going on for hours.
> Apparently there are plenty of companies interested in how Tesla's cars are made.
Disassembing a rental car is ..uh.. rude, but other than that this is completely ordinary, and not even done in secret.
When I worked at BMW, we once went down to a big room where an entire VW (Golf?) was disassembled and on display, all its components laid out on long rows of tables.
I can't remember any access restrictions on that room -- it was just a place you went to look at how other engineers had solved particular problems, learn new tricks, or get inspired.
It's essentially the code reading of the mechanical engineering world.
Really quietly ;-)
But in all seriousness, for a big family to sleep in the same room/place was the norm for much of humanity's existence.
I agree that I'd find it awkward to be intimate without some privacy, but it doesn't seem to have stopped our ancestors.
Wonderful.
Is there a way for me to be notified once it comes out?
Great news!
I read your book in (I think 2012), and found it very useful.
I suspect I'll be buying the second edition.
> I think you got down-voted because you misrepresented what Telsa is actually doing, which is a difficult arbitrage between: > > - known preventable deaths from, say, not staying in the lane aggressively enough; > > - possible surprises and subsequent deaths.
I don't think I was misrepresenting anything (at least, I was trying not to). I just pointed out that behaviour-changing updates that may be harmless in, say, smartphone apps, are much more problematic in environments such as driving-assisted cars. I think this is objectively true. And I think we need to come up with mechanisms to solve these problems.
> That learning pattern (resolving unintended surprises as they happen decreasingly often) is common in software.
My argument is that changes in behaviour are (almost automatically) surprising, and thus inherently dangerous. Unless my car is truly autonomous and doesn't need my intervention, it must be predictable. Updates run the risk oof breaking htat predictability.
> Others have preferred the surprise-free and PR-friendly option of not saving the dozens of thousand of lives dying on the road at the moment.
My worry is that (potentially) people will still die, just different ones.
> being in favour of Telsa (and Waymo) taking more risk than necessary
If I'm taking you literally, that's an obviously unwise position to take ("more than necessary"). But I think I know what you meant to say: err on the side of faster learning, accepting the potential consequences. Perhaps like NASA in the 1960s.
But my argument was simply that there is a problem with frequent, gradual updates. Not that we shouldn't update (even though that's actually one option). We ought to search for solutions to this problem. I can think of several that aren't "don't update".
But claiming that the problem doesn't exist, or that those that worry about it are unreasonable, is unhelpful.
This has been an open secret for years. Anyone who wanted to know, easily could.
Perhaps not the existence of "defeat devices", but open disdain for and cavalier circumvention of the rules by all manufacturers.
> Did no competitor try to legitimately meet emissions requirements
Probably. German manufacturers openly share products for comparison with their competitors (realising they can't avoid it anyway). I think it's a safe bet that everyone knows what everyone else is doing.
This gives you an efficiency advantage right off the bat.
It might even be a good thing to remove dead code -- what isn't there can't possibly cause trouble.
But it complicates product management: instead of a single binary and a bunch of feature flags, you now have a bunch of binary versions; and the number of permutations can get quite large quite quickly.
It might have safety implications (e.g. deactivating airbags so they don't fire because of implausible-on-the-road vehicle states), or even enable certain tests in the first place (perhaps by disabling traction control systems confused by vastly differing speeds per axle).
Using them in order to cheat, however, is clearly not nice at all.
Speaking as a German, and as someone who has worked in the automotive industry, I'd really like for manufacturers to be punished hard on this.
The amount of complacency and disdain for regulations on the part of the manufacturers is disappointing, and the collusion by the German government distasteful.
I wonder if we're talking past each other? Sure, incrementally improve during engineering. But don't incrementally change the safety-critical behaviour of a car once it's in the customer's hands.
> Build it perfectly the first time? That's not realistic.
Absolutely agreed.
But for subjects such as autopilots, predictability may very well trump improvement.
I'm assuming that the initial iteration is already reasonably safe and useful (if it isn't it shouldn't have been shipped, right?).
If the behaviour changes unpredictably (how will you predict autopilot changes caused by an update?), this may well be less safe than keeping the existing system, whoose quirks the dirver has noww learned.
> Pretty much everything humans do is incremental improvement. > I understand your point that we dont want to introduce weaknesses in 'upgrades'
The nasty thing is that even a change to objectively superior behaviour may be problematic, because the driver will expect the car to behave one way, when it now behaves a different way (regardless of merit).
Not even a changelog would help in such cases. I feel like the autopilot ought to inform the driver in each situation where it used to decide one way, and now decides another way. That might be a reasonably safe way of allowing incremental change, but is likely too annoying for most people.
> but this should be a discussion about how to create robust QA rather that stopping incremental improvement.
Robust QA is certainly a must.
(side note: I used to work in safety-critical automotive projects. I may have a more intimate understanding of the issues)
I recently got downvoted for that exact line of reasoning.
Looks like some people don't like to hear that :-)
Location: Munich, Germany
Remote: preferred
I'm an experienced (>10 years) software engineer with management experience. I have a master's in mechanical engineering.
I've found my calling in introducing modern methodologies to (not just, but particularly) embedded systems teams, including agile IoT development all the way to DevOps for embedded.
I've worked on all stages of embedded products, from product management, to specification, to coding, testing, and qualification. A lot of my career was spent working on safety-critical systems up to ASIL D / SIL4.
How I could help you:
* devise a strategy and implementation to improve your team's development processes
* train your team
* advise in improving the quality of your product
* create fast feedback loops all through the development cycle (DevOps)
* close gaps in your team's embedded development expertise
* training and advising several German Fortune 500 companies on DevOps philosophy, processes
and implementation
* managing a small, experienced team in the development of an industrial robot
* advising a multinational company in the development of a highly safety-critical (ASIL D)
automotive electronics component
* advising a startup in the IoT development tooling space
* coaching a startup team on improving their development workflow to increase speed and quality
How about... not?
I'm not being disingenious here.
If there's autonomus tech, then I find it scary that it might change its behaviour. You see, I've learned how (say) Autopilot responds in certain situations. I know when to trust it, and when not to.
If this behaviour changes (perhaps even if it changes for the better!), that's a very dangerous thing. Some of my experience is now invalidated, but I don't know which part. But it mostly works as before, which gives me a false sense of security.
Changing the driving behaviour of a vehicle, especially in totally un-obvious ways, is super dangerous, and such changes must have very strong justifications.
Just think of that poor guy whose Tesla drove into the divider. Oh look, it behaves just like before -- except for its lane following behaviour.
So far I've been making do with shellscripts I call ad-hoc, but dedaemon looks super convenient.
Thanks for creating it, I'll certainly give it a try!
I don't know how many those are.
Most blogs I see seem to be run as a labour of love or for content marketing. Anyway, nobody expects to make money directly off the blog.
My favourite episode, "That's All There Is" (#7) is told from Alan Bean's perspective.
It portrays him, and the entire crew, as an amazingly capable, funny, and tight-knit group. The entire episode has a humorous tone which, after my impression from watching several interviews with Al bean, probably fits his personality.
If you're an aerospace nerd like me, you'll love it. I probably watch the whole series several times a year.
As you're apparently aware, minister Dobrindt (who was in charge of both) took great pains to deflect trouble from the German automotive industry.
I think history will show that by making their present more pleasant, he'll have made their future less stable. Now they get to milk the status quo for a while longer, instead of being forced to adapt to changing times.
For this and other reasons, I despise the man.
c't is a German computer magazine that has been around since the early 80s. It has a very good reputation for journalistic quality, expertise and thoroughness of investigations.
heise is the publisher that owns c't, hence the url.