lambdaelite

A medical device startup, based on a technology platform I invented in grad school. The startup part is what started me hanging out on HN, but I've found that there is very little overlap between what I'm trying to do and what startups on HN do. Still, things are interesting enough here that I keep checking in.

edit: I missed the "how's it working out?" part.

Not great. Cash starved from day 1. Funding for medical devices is quite, quite different than software (i.e., bad but getting better recently). We don't fit the model for many VCs, so that limits potential sources, and being in medical devices means that we need to deal with sophisticated investors that can run proper DD on us, further limiting potential sources. Funding has been (and still is) a struggle! It's also a little bit "lonely": we run into a lot of problems unique to this industry, but often we can't talk about it in detail, and even when we can, there aren't many people around to talk to.

Project management has been interesting. There's quite a number of consulting and industrial design groups out there, which helps to bring in expertise when needed and keep things lean overall. A big challenge has been in setting up the supply chain: it's not something I've done (or thought of) before, but consulting has helped out here as well. Basically, we'd be dead in the water without outside consultants.

Regulatory affairs is a pain, but I appreciate why it's there and it's not onerous per se, just slows everything down (not necessarily a bad thing). It more or less distills down to documenting "say what you're doing, and do what you're saying".

The technology side is a bit boring, honestly. We need to design things conservatively, unless we have a really, really good reason not to. We also need guaranteed years of availability for parts, which additionally tends to lead to conservative designs.

Surprising lessons learned: cable management (i.e., in the device) is a nightmare, and packaging is anything but a simple problem to solve. Also, may have learned more in 6 mos. tilting at these windmills than my entire undergrad + graduate career.

Well said—completely agree.

I agree that option 4 would explain the attraction of these devices. I guess I remain unconvinced that, while these gadgets may claim to "unlock option 4", they will actually deliver (yet again, excepting the immersion circulator). There's a lot more to cooking than simply getting the temperature right. I'm skeptical that a magic cooking gadget is going to make someone a half-decent cook for the same reason that I don't believe a magic golf club will make me a golfer: the reason I can't hit a golf ball is because my technique is pitiful.

Like I said, I'm not the target for stuff like this, but I am always on the lookout for neat gifts, which is why I'm trying to figure this stuff out.

You've downplayed option 3, but you've clearly got some motivation towards cooking. If I might suggest, have you considered watching/participating in a free cooking demonstration at the supermarket? In the past I've found them to be well done, and they use stuff available at the supermarket, so that lowers one barrier. Also, cooking classes make for a great date night.

If you trust Cooks Illustrated, Breville's top end toaster oven ($250 on Amazon Prime) is at the top for toaster oven performance and works well. Have you tried that one?

Personally, I'm more interested in auditioning Cuisinart's mini combi oven ($300 on Amazon Prime) before going all in on a built-in, but I haven't read any reviews I trust yet.

With the exception of the immersion circulator, I don't understand these devices. Can you help me understand?

I'm an experienced cook, so (again, with the exception of the immersion circulator) I'm not in the target market for these devices. I'm having trouble understanding the target market though. I was thinking that it was for inexperienced people who want to cook at home. When I play that scenario through my head, it doesn't completely work.

Take your salmon example: getting the pan to a good temperature and cooking the fish to the ideal temperature is not easy, so I can see how an inexperienced person could easily benefit from real-time temperature feedback. What I'm having trouble figuring out though, is that after gaining experience from cooking fish a few times, what's the benefit of the real-time temperature feedback? I guess the thing I'm wrestling with is that as one becomes more experienced, the value of these smart devices seems to rapidly diminish.

I don't intend this to be negative or harsh, so I hope it doesn't come across that way. I'm genuinely interested in the thinking behind this smart device trend. Hope you can share.

> Also, having such a small volume means that most of the heat will escape when the door opens...

Supposedly, there's an air curtain to help with that problem.

> It seems like a perfectly acceptable (albeit pricy) alternative to a toaster over, however.

It may be an alternative to a toaster oven, but is that a good thing? Even the best toaster oven isn't very good, if you go by testing by Cooks Illustrated for example. I don't see how this one can perform any better given, as you point out, the physics limitations of a small oven.

I picked up an Anova a few months ago for $150. That might be the best bang for the buck kitchen purchase I've made. Certainly ranks up there with a stand mixer and microplane.

At first glance it looks really neat, but I was disappointed to see that this doesn't have combi oven functionality. For the price I would guess this would retail at, I wouldn't be willing to buy this over a combi oven.

edit: I missed that the MSRP is $3000. I was right, I'm not willing to consider this over a (for example) nice built-in Wolf combi oven in the same price bracket. I'll also argue most people would be better served with a combi oven over this device. There are some neat ideas here, but I don't get the appeal.

Perhaps it has to do with the runtime being GPL'd? Regardless, the Adacore FAQ specifically councels that the GPL version is suitable for free software only.[0] Admittedly, I find the licensing situation confusing and could be completely in the wrong here.

[0] http://libre.adacore.com/tools/gnat-gpl-edition/faq/

Nothing per se. I was confused in that both Adacore and FSF offer a compiler with the same name but different licensing.

As to my specific situation, I cannot release source code and so the Adacore GPL licensed product is a no-go.

The licensing for the Ada ecosystem is confusing to me. It seems that the major vendors are Adacore, Green Hills, and Atego. Am I correct that for commercial products, there are no free toolchains available?

The IEEE-CS/ACM jointly publish one: http://www.computer.org/web/education/code-of-ethics

It doesn't seem that different from other professional codes.

> You see this sentiment come up about every few months here. We're not rigorous enough. Or we can't estimate our build time well. Or we don't have any liability. Or we don't have a codified set of morals that govern us. BS.

I don't see the BS. Coming from a traditional engineering discipline, I'd agree with each of those. The scariest to me is on professional standards and ethics: it seems to be an almost point of pride among some HN commenters that they operate outside of any formal standard. That baffles me.

> To me, engineering is a way of thinking, it's all about problem solving.

Interesting. I would say it's all about the problem solving process.

> The big difference with software engineering is that the costs of failure are so relatively low that we prefer to go full steam ahead instead of trying to find ways to reduce uncertainty.

I think this is an excellent point. Software is treated with a different level of rigor and respect on safety-critical projects. Same for embedded systems where the cost of updating a system is prohibitive.

I do think that there is an engineering discipline in software, just that most people aren't practicing it.

It sounds like it's not viable at this moment, but later down the line you could use a PEO (professional employment organization) for your startup. This would give you health insurance in addition to a bunch of other benefits and services.

Professional organizations (like IEEE) offer insurance plans. Another possibility are shopping clubs like Costco. I haven't used either, but include them as possibilities in case you weren't aware.

As a heads up, CoPilot (camel case) has been used for a long time for a GPS navigation product by ALK.

I find that statement misleading: one doesn't need to serialize or "register" (whatever that's supposed to mean) an AR lower made for personal use that, later, one decides to sell. Again, YMMV, depending on the state.

As always, it depends on the state, but it's not true that you can never sell a gun that you've made. You can't make them with the intent of selling them without the proper paperwork, but you could make one for yourself, then later decide to sell it. Check the ATF FAQs for more info.

Respectfully, that doesn't apply to regulated industries.

Among other things, what I found interesting was that Barr was giving expert testimony on engineering and "engineering certainty", when as far as I can tell he doesn't have a PE license (if he does, he's the first engineer I've ever heard of that doesn't conspicuously advertise it). I was under the impression that wasn't permitted in any state.

edit: Toyota did plenty wrong. Chiefly, I'd say that ignoring their own documented processes should be at the top. Having a system utilization of >70% would be another, as is using recursion. All are things that, at the time, were no-nos. I don't however think that one can fairly argue that it's practical or sensible to implement emerging standards during the multi-year car development process, which many seem to be arguing. I also remain skeptical that the unintended acceleration events are software related. It seems that for one to buy the bit flip argument from the trial, one also has to assume that the drivers depleted the service break vacuum, and that combination doesn't seem probable to me.

Yeah, I mistyped (should read "...later DO-178..."). You're quite correct that DO-178B was around then, but the C revision was not.

According to testimony, Toyota's coding standard was in place in 1997, before the first MISRA-C publication.

> DO-178B was created in 1989, Ada was created in the 70's, standards for mission and safety critical systems have been around since the 70's, I was reading about Ada and safety critical programming as a kid in the 80's (I was a weird kid).

I'll hazard a guess that the HN readership consists of many formerly weird kids. :)

DO-178B was around then, but I'm not aware of any automotive groups using it then or now—I'm not in the automotive sector, so I could easily be mistaken. I would argue that IEC 61508 would have been the best model to follow in lieu of something more specific (especially since IEC 26262 is an adaptation of it), but I don't think even 61508 existed at the time outside of a draft. Ada was around, but it was a different beast than it is now and the tooling wasn't very good at the time (my opinion). I can't think of many that were using Ada outside of the government mandate.

For general consumer products (i.e., outside of aviation and military), I'm having trouble thinking of industry standards for mission- and safety-critical electronic systems that existed at the time that Toyota's electronic throttle system was developed. Maybe SAE had something at the time? A cursory Google search didn't pull up anything.

> Whether you accept that multiple independent experts in safety critical programming are right or not is up to you however the stuff that came out of the trial painted a very clear picture to me of just how bad this software is.

To clarify, I'm not saying that the software isn't poorly written by modern standards, but I am questioning that it was uniquely poor relative to the rest of the industry at the time it was developed. That said, Toyota was/is arrogant, and ignoring their own processes and requirements at the time is unquestionably the wrong thing to do. I remain skeptical that the software component was responsible for the unintended acceleration issues.

> A cynical person might consider that if Toyota is this poor how many other manufacturers are also as bad.

Isn't the null hypothesis that they were all equally bad?

> Un bon mot ne prouve rien. (A witty saying proves nothing.)

—Voltaire

The HN community at large isn't experienced with software engineering. It seems like there are a handful of commenters who are, but they are a very small minority.

Personally, I'm surprised that the majority of the HN community overlooks or ignores the reports from NASA and Exponent (Toyota's outside expert witness) in favor of the testimony from Barr, the witness for the plaintiffs in the Oklahoma case. (I'm honestly amazed that Barr was allowed as an expert witness) Barr did show that the code "smelled" and that it was possible to inject specific faults to induce an uncommanded acceleration, but he did not show that his proposed failure mode occurred nor that it was probable to occur. In fact, part of his failure mode was that it left no record of a DTC. It's the perfect kind of failure mode for a sympathetic plaintiff to wield against an arrogant defendant with deep pockets: possible that it occurred, possible to demonstrate, understandable for a jury (who hasn't had a BSOD?), and impossible to disprove.

You bring up the practice of software engineering, but I think you need to place it in context of how software engineering was practiced around the time that the electronic throttle system was developed. MISRA, which HN readers are becoming aware of, didn't exist. Proof assistants, which today remain challenging to use and integrate into an SLDC, were even more arcane. In fact, your example of TLA+ wouldn't fly even today since TLA+ doesn't do code generation, and that would be a necessary component of the verification process of a regulated SLDC. I don't think TLA+ existed at the time either. Things certainly have changed!

Toyota couldn't ignore these (voluntary) standards given that MISRA-C nor the earlier DO-178 didn't exist at the time the code was developed.

And as I recall, TLA+ doesn't tie into code generation which doesn't help with the verification process.

Testing is certainly very important, but I think it should be emphasized that testing is but one part of the software development life cycle that produces an acceptably safe product.

The person in charge of a mass spectrometer (Thermo Element 2) at a local college likes to toy with his students by running tests on their commercial bottled water during a lab demonstration. This particular instrument can pick up minute traces of uranium, lead, and the like (on the order of fg/L IIRC).

At the end of the demonstration, the trash can is full of discarded water bottles.

A familiar interlock would be the mechanism used to disable a microwave magnetron when the door is in the open position.