I turned down a job in Oregon this year because they wanted me to sign an IP assignment clause to that effect and refused to budge when I asked them to remove it.
Definitely "The Machine That Changed the World" by Womack, Jones, and Roos [0]. This is "the first book to reveal Toyota's lean production system." Before reading it, I had never imagined just-in-time production or value chain mapping, or vehicle assembly lines that can profitably produce quantity one of a product before being reconfigured to produce a different model (SMED: single minute exchange of die).
Now I see muda everywhere and cringe when I overhear people talking about applying kaizen and how they think they're practicing "continuous improvement" while repeating the same rote, industrial, mindless processes that they have been for the last 40 years. We can do so much better. Toyota tried very hard to teach GM how at their NUMMI[1] plant, but it wasn't the right location relative to their suppliers for JIT to fully work and "It is difficult to get a man to understand something, when his salary depends on his not understanding it." -Upton Sinclair
In software people use agile as an excuse to not think through the core architecture.
I believe agile was invented to incrementally improve an already well thought production process. Once the assembly line was setup, agile was used to eliminate the unproductive activities. I am not sure agile will be helpful to build the assembly line itself?
In most scenarios that's what people try to do with agile.
Setting up a mechanical assembly line is very different from setting up a software pipeline, although, as you can tell already, they use some of the same words and metaphors.
It isn't possible to build a mechanical factory in weeks with readily available tools [0]. We just don't have that kind of concentration of knowledge, we don't have the skills, the know-how etc. to accomplish that. Whereas with software: you have OSS, you have the Cloud, and all kinds of numerous tooling that helps you get started immediately, and iterate on that until you get to the final product. That kind of iteration, debugging etc. is just not possible with manufacturing. Which is why in manufacturing you need great designs and processes: bad decisions are very costly. They are costly in software too, but... your MVP will still churn out value, even if its not efficient. Once you prove that your product satisfies a need, you then make it better, you make it more efficient, scale it out, yadda yadda. But getting started is absurdly easy. And thats why lean works.
The designers of lean realized that all that worry about scaling, about automation, planning, QA... while its important, it doesn't provide the most value for everyone. For a smaller company, its more important to get out a product that solves a problem even if its janky. Once you prove its usefulness, you attract more money, more people etc.
So lean solves two problems:
* gets you started quickly and fails bad ideas fast
* lets you justify bad design if it provides more value
One could argue that the technical debt built up by this kind of process has to be paid down someday. If your product survives for long enough, you will have enough resources to do that. And then you have a core product that brings in revenue, and you repeat the same lean method for other products. Rinse and repeat, ad infinitum.
[0]: where this assumption fails, you see a lot more manufacturing. e.g. in China, the fruits of this kind of aggregation in manufacturing skill is visible, and that's why Chinese manufacturers are so adept at responding to changing market conditions.
I agree with your points above.Having said that knowledge and experience is a critical factor and I am fine with using agile for MVPs and startup scenarios.
My issue is with the way agile is evangelized and implemented in the Enterprise. These Enterprise people simply rationalize that if Toyota can do it then why we can't without realizing where it fit and where it does not.
Personally I think it does not fit with the culture of thousand approvals and beating the dead horse i.e. endlessly cross examining any design or implementation failures.
This happens because Enterprise people love the buzzwords. Agile and cloud are the latest buzz in Enterprise so they watch a ppt or two somewhere starts pushing agile into a culture where it does not fit at all. This results in sufferings and frustration.
Kaizen seems to be manufacturing's equivalent of agile. Everyone says they do it, but almost no one actually does it because that would mean totally re-configuring their business.
I hadn't recognized the equivalency of [lean] and agile before. That's interesting and helps give me a better appreciation for why we only end up paying lip service to the idea. Thanks for the thought.
A good approach to this is to start small. Apply kaizen on small things, get the "kaizen culture" ingrained in your team/company culture, and slowly move on to bigger things.
For me it was a sequence of books that did it. The Phoenix Project first, then David Anderson's Kanban book. Some tine after that was The Goal and Deming's Out Of The Crisis, and a book of Taichi Ohno musings.
You're right, what has been seen cannot be unseen.
It's interesting for a number of reasons, not least because it explains that a lot of the ideas driving how Toyota worked post-war came from the fact that they knew they wouldn't be able to let people go in an economic downturn.
Why did GM's people's salaries depend on not understanding NUMMI/TPS? I would have thought it would have been clear to them they either adapt or die, and thus their salary depended on understanding it.
Simply accepting you're in the wrong location means moving, and you can't move a factory and all it's workers cheaply. Similarly, no one wants to automate their own job away, as that would result in them not having a job.
Granted, long-term that thinking kills companies, but short term it keeps the bills paid, the kids fed, and the beer cold.
From what I was able to gather it was less about being in the wrong location and that the internal politics of GM set NUMMI up for failure.
America was able to be a powerhouse of manufacturing during WW2, I remember reading that a lot of the DNA for JIT/Kaizen/Lean came from the Marshall Plan[1].
The Chicken Tax. Because of it, US auto manufactures promoted and sold the one market segment where they had 0 to no competition. Even today, the big American automakers suck balls at making Sedans and focus exclusively on Trucks and SUVs.
The tools don't really mean anything, it's mostly adopting the principles enforced. And everyone has to adopt it for it to work. The ones that do it best, have a strong company culture. You define the why before the how and what.
This year I read "Clean Coder" by Robert Martin and "The Software Craftsman: Professionalism, Pragmatism, Pride" by Sandro Mancuso.
They were both excellent and I recommend them to any programmer who wants to improve his or her Engineering professionalism and craft. Don't be a "coder," be a professional Software Engineer. Take pride in your work, do your best work possible, and stand up to insane, unrealistic management.
Location: Seattle, WA
Remote: Open to it
Willing to relocate: Only within Washington and Oregon
Technologies: bare-metal and RTOS-based embedded C & C++ in avionics. Delphi, Python, and Lua for Windows tools.
Résumé/CV: Available on my portfolio website https://coderjames.bitbucket.io/
Email: james@jdooley.org
I'm a Senior Embedded Software Engineer that prefers to work at the hardware / software boundary. I enjoy new-board bring-up and device drivers. 100% of my experience is in FAA-certified avionics under a DO-178 process, so I understand and appreciate the need for a Culture of Quality in a development team.
Raptor codes are powerful, but one has to be careful with them, as they are heavily patent encumbered by Qualcomm according to Wikipedia[1]:
"Raptor codes are heavily covered with patents in various jurisdictions. For the specific instances specified in RFCs, statements by patent owners may or may not provide some leeway, depending among other things on whether the device carrying the implementation also implements a "wide-area wireless" specification."
So I encourage people who otherwise work with Error-Correcting codes to tread lightly when considering implementing Raptor and RaptorQ codes.
Do you know of any other fountain codes more powerful than the LT code described in the article, that are not particularly patent encumbered? This seems like a really interesting area, but from reading around a bit, it seems like part of the issue is that because all of the research is so recent, you end up stepping on someone or other's IP.
Online Codes (https://en.wikipedia.org/wiki/Online_codes) are very similar to Raptor codes for rateless erasure coding. The construction consists of an inner an outer code. However unlike RaptorQ, they are not optimized for an entire range of block lengths.
> the quality of the product. "Good enough" is never actually good enough for me
I hear you loud and clear. One way to get a higher standard of quality may be to switch industries. In aviation, where bugs can cost lives, there tends to be a higher standard. You may still find the bar of your co-workers isn't as high as yours, but it will definitely be higher than at a consumer-products or web-facing company. I know, I've interviewed at a few of those and turned down follow-up interviews and offers because they don't care enough about quality to do QA.
"Devs push to prod; rollback and page someone if it breaks" isn't acceptable when the customer isn't able to take 300 aircraft out of service every week to load your latest release.
> I recently became a multi-millionaire (not from crypto) and this is so true. I'm less happy than I was
> Even though I'm young, I feel as though I'm entrenched in this game now with no viable way out.
I'd be happy to take those unwanted millions off your hands so that you could return to the life you miss. I'm the breadwinner of a single-income family in the Seattle area and I don't make a FANG-level salary. If we could afford to buy a home instead of renting, I think we'd be much happier.
Now if only there was somebody besides Microchip making low-cost dev kits for these things, maybe we could have some fun and get a MIPS revival.
I can get ARM microcontroller boards for $10 - $20 from ST, Microchip (nee Atmel), SiLabs, etc. More powerful ARMs in any flavor of Pi that I want.
Where do I buy a low-end interAptive or microAptive board? The Creator CI20 is super interesting, but no on-board debugger included. The LinkIt MT7688 modules don't even bring out the JTAG pins.
Agreed. The PIC32MZ is a neat MIPS microcontroller (if you're able to tolerate the MPLab Xpress IDE). Unfortunately the cheapest PIC32 board they offer is the DM320001 at $50. I picked up a SAMD10 "Xplained mini" for $9 from Digikey, and one can get sub-$2 STM32F103 boards from AliExpress.
Arguably the Cortex-M0+-based D10 isn't really comparable to the PIC32, but that's sort of the point. No Arduino-sized community is going to develop around an architecture with a $50 minimum entry point... Maybe I should stop complaining about it and try to fix it :-)
An aircraft's Flight Management Computer uses a Kalman filter to combine the data from all available sensors (GPS, IMU, altimeter, ADC, VOR, DME, etc.) to compute the position of the aircraft.
