LegitGandalf

Non-clickbait title: Teslas running Autopilot have been in 0.0000273 crashes/km in less than a year!

I've been alive long enough to see a considerable sample set of human drivers and I've got to say the bar Autopilot needs to exceed in order to save limb and life is incredibly low. Couple that with the fact that just here in SoCal Tesla has become a common sight, 273 crashes sounds like a hell of a lot of human suffering was avoided.

As I've used slack over the last 5 years I've come to the conclusion that they have a quality problem of some sort. The software just behaves weird, especially in the voice and screen sharing areas.

It seems like their management runs the "quality via escalation" anti-pattern.

Reddit's new UI is a decent first step down that road.

I came here for a cat pic, left disappointed!

Way to much written content implied, needs more twitter embeds

My grandfather, who I respected very much, was an accomplished career bureaucrat and considered any sort of promotion beneath him, and for sure crafting clickbait would earn his scorn. Thus marketing, promotion and crafting clickbait goes against everything I come from.

But, making something that I think will actually help people, and then watching it go unseen because I wouldn't do the thing required to spread the message via the network effect is a far worse fate.

So, I do the thing.

I'm just over here thinking of the health benefits provided by broken McFlurry machines!

“Tell me how you will measure me, and then I will tell you how I will behave. If you measure me in an illogical way, don't complain about illogical behavior.” – Eli Goldratt

Working with a Mac for the first time this year, excel on Mac is actually worse than excel 2010 :(

Tables are probably the most overlooked feature of Excel.

Why use tables?

* Each column is uniquely named - no more wondering if you are referencing the right cell, no more thinking about "to $ or not to $"

* The table's rows and columns are reliably discovered by pivot tables - no more wondering if the entire dataset is referenced by the pivot

* New columns that are formulas are automatically applied to every row

* Tables have names, so it is easy to understand which table a pivot is referencing

The true, reliable and sane power of excel lies in Tables + Pivots + Charts. If you drive most of the problem solving into those paradigms you will keep hair!

A large part portion of the software industry skips this form of testing in favor of using a portion of production with health metrics to detect chaos. Which is alright, unless someone like Boeing does it with an airplane.

If unleashing chaos on users is bad enough for your business, then TLYF is a good pattern. Here are some scenarios that call for TLYF:

* Customer will die from chaos in software

* Customer will remove product if they experience any chaos

* Software is deployed somewhere that is hard to update - think non-internet connected devices, or regulatory required change control

* Chaos will cause significant loss of value

Both Boeing and Toyota failed to apply TLYF rigorously, resulting in uneccessary deaths.

The physical dependencies of a house vs the abstract nature of software interdependencies really makes the analogy fail for me. Houses just don't don't regularly fall down 8 times a day because one framer is putting a nail in a new wall and that caused the fireplace to explode.

How do you reconcile how bespoke and ever changing the requirements are for software products vs how stable the requirements are for garages?

I'm asking because I see the construction analogy pop up a lot and I just can't reconcile the two things.

To me the development of a new blueprint for a new kind of garage for a new kind of vehicle operated by a never before seen alien species is a bit closer to creating a software product.

I mean, who would ask a contractor to do what people regularly ask software engineering teams to do?

On mobile there is a pretty massive white space gutter on the right and left of the text. This makes the article challenging to read.

I always say, never start with a zero vacation balance!

You are so right and I'm so sorry. It is truly miserable at so many companies for exactly what you wrote here:

"Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is."

I started using slack about two years ago, and in my opinion they have a quality problem. There are just too many issues that crop up when they roll out change.

It reeks of the "just get it done" anti-pattern where done is change that hasn't had the chaos tracked down and killed.

I bet internally they are waiting for bugs to get reported instead of pro-actively running the changed software under representative load to hunt and kill chaos.

Or perhaps she trusts him and Ann.

>The thing that hasn't come about yet though is, sales, marketing, accounting can also be outsourced. Dare I say automated.

Yep, just consider how much sales, marketing and accounting work the App and Play store has automated. Not to mention software delivery and installation work.

I've yet to see a remove feature OKR.

As a matter of fact I've seen the super-opposite more than once.

That's where the organization figures out they are having the team work on something no customer wants, but they decide the team should go ahead "finish" it, as if there is value in the company maintaining filler.

The worst part of the anti-pattern is when a software leader is trying to do a good job, but finds this puzzling behavior where people in the org just want to hurry up and finish the filler project instead of resolving problems like poor performance, bad customer experience, etc.

For those paywalled, here is the money paragraph

    >NASA lets net users sign up to send their name to Mars on a future flight. Taiwan appears as an option on a “country” drop-down box. It’s unclear how long Taiwan has been called a country on the website, but more than 18 million people have registered.

Very cool, I've always wanted to watch the NSA watching me!

>The majority of these men believe that the fundamental interests of employees and employers are necessarily antagonistic

Taylor's ideas were quite good in the context of labor practices at the time. People were getting paid a buck a day to come work at the factory, and companies employed speed bosses to walk the floor and yell at employees to hurry up. Speed bosses and management got production bonuses, workers got a buck regardless of productivity.

Taylor and Gantt instead had companies give bonuses to both staff and management for extra output, which resulted in higher productivity.

For history buffs here is a picture of an original "Gantt chart" where he is comparing workers folding textiles after putting in the Scientific Management system. More black in the chart is an indication of workers earning the bonus more often.

https://iism.org/material-player/software-management-essenti...

Quarterly and annual goals setting is all about telling a story to wall street. Executives are obsessed with chasing quarters because there are significant bonuses associated with meeting quarterly and annual targets, and so it is natural that goal setting permeates the whole company, because the C-Suite is in charge after all.

Quarterly and annual goals are largely irrelevant for staff who are engaged in creating new software because of the constant need to pivot as the market and solution are discovered via iterative attempts. That said, Wall Street is in love with MBOs/OKRs and companies would be dumb to not execute investor desired ceremonies.

My advice to software engineer ICs is to do the bare minimum workflow for MBOs/OKRs and try not to be discouraged by the obvious waste of time. Dev managers can best spend their time trying to keep the goals high level and achievable in a variety of ways so that distraction presented to the ICs is minimized.

Fundamentally the last thing you want is software engineers doing is screwing around trying to figure out how to shoe-horn some stupid MBO/OKR around the work they end up discovering, or even worse, the inverse.

Not only that, but if tech matters to the company, and it increasingly does these days, the broader organization really needs to have some technical savvy in order to avoid a bunch of anti-patterns that are running wild in non-tech savvy organizations:

* Setting bad expectations with stakeholders and customers

* Taking on bad opportunities, committing the organization to unnecessary technical debt for no monetary gain

* Fracturing teams across competing opportunities

* Top down decrees issued from abstraction that causes organizational thrashing

* Decisions made in abstraction with no understanding of the stubborn technical constraints that block fruition

As a boy I had a Franklin (early apple clone) which I think had some variant of the 6502 processor.

Getting software written for the Apple II to run was difficult. On one of the early King's Quest games I figured out I could get it to run if I pulled the disk out partway through the load and then put it back in.

I mean, totally worth the research effort because it was King's Quest after all!

So whether your colors be blue

Or red or lightsalmon or yew

Remember that if life is rough

Just add in a little more peachpuff!

>In retrospective, I realize that I had to go through stupid ideas to develop a sense of what is viable and what isn't

Yep, as it turns out, when trying to create a new, valuable thing that people need, you actually need to make a bunch of attempts and try them out.

If you are ever in the position to have a team of people undertaking creating new things, the optimal path is to expose each person to a charter and scope of the area your team is trying to innovate in and then let them come up with their own ideas. Diversity of thought is the key to speeding up discovery of new, valuable embodiments of solutions that fulfill currently unfulfilled human needs.

Some notes on interesting pages:

Page 31: References Toyota witness who indicated that they didn't think the firmware had bugs

Page 53: Critical variables were not mirrored!

Page 56: Throttle could be thrown wide open by memory corruption bug

*Page 62: Task X (real task name redacted) in the code called out as a "Kitchen Sink" task that does a bunch of different things, including cruise control and throttle control, and, most importantly, reporting diagnostic errors*

Page 64: There was no brake override to cut throttle when brake applied. Not only that, but later Toyota model threw brake override code into the kitchen sink task anyway, so if that task failed.....

Page 82: Barr describes what happens when task X is killed after user hits resume on cruise control

Page 89: Additional failure condition, if use is lightly touching brake when cruise control resumes and task x is killed, the acceleration won't stop unless they fully release and press break pedal again

Page 91: Buffer overflow found in code

Page 92: Pointers dereferenced without checking to see if they are valid

Page 93: Nice description of a race condition

Page 99: Toyota employees referred to the code as "spaghetti"

*Page 100: Code used over 10,000 global variables*

*Page 107: Stack size is 4kb, Toyota thought it was at worst case 41 percent used. Barr found it to be 94 percent worst case.....not counting recursion that was in the code as well!*

*Page 108: In case of stack overflow, critical OS data, such as what tasks are running, is the first thing to get overwritten*

Page 112: Toyota engineers didn't understand that the stack also gets data pushed onto it by ISR and OS task switching

Page 113: Toyota code had recursion, a huge no-no in critical safety systems

Page 123: Toyota engineer indicated they never looked for a firmware bug that would cause the throttle to be wide open

Page 128: Mirroring was used on many variables, however the target throttle angle variable was NOT mirrored

Page 138: RPM failsafe was part of Task X (Kitchen Sink task)

Page 142: Watchdog only monitored for excessive CPU usage. It didn't check for tasks being killed.

Page 143: Toyota dedicated a hardware timer to kicking the watchdog!

In my opinion Toyota firmware engineers were not empowered check the quality of their own firmware, and were likely under time pressure to just Get-It-Done™

I've managed embedded C & C++ products in my career, and I always insisted that the developers be given the time to set up the firmware to run under representative load in a lab. Without fail the developers found significant problems that did not crop up during QA or dev unit testing. Tasks performed by the devs included creating and evolving simulation hardware, firmware and software to make the most representative load scenario possible to find and kill chaos. The funniest part? Nothing I ever did was in safety critical systems, and we clearly did more than Toyota.