In today's Lego related ideas, and in honor of tomorrow's team build of theImperial Star Destroyer,Systems Thinking at Work and Play. Systems are all around us, and there are lots of educational shows that show them. From "Dirty Jobs" to "The Magic School Bus", understanding how things are built out of parts and work together is the system mindset. One of my favorite systems, and it has been lo these many years, is the Lego System. Yes, when you dump 4784 bricks on a conference room table it's not a system, it's just a pile of plastic parts, but when you put it together it's more than the sum of its parts, it's a system of reusable components. Add in some Technic parts and/or a Mindstorm kit and now you're really talking. But what is it about systems that is so interesting and important? To me, it's the fact that you can take things that individually have no, or very simple, responses and then combine them, and through their relationships create complex responses. Systems are also a way to manage complexity. Boundaries and relationships help us understand our world (or our SDV) and let us focus on individual components as needed.
Back in the old days the competition for users came down to Operating Systems. OS's were proprietary walled gardens and everything was done in service of selling the OS. Sun and Solaris owned the Internet (the network is the computer), Microsoft and Windows were going after the desktop (a computer on every desk), and Apple had the creative niche (think differently), and BeOS and NextStep were out there selling themselves as better than everything else, but no-one was buying. Except for that oddball OS in the corner, Linux. It's available online, you need to know what you're doing (or have access to someone who does), doesn't support all of your hardware, and it's free, but outside of those constraints, it just works. Oh, and it lives by the command line.
20 years ago Wednesday, Neal Stephenson released his take on the battle. It has car analogies, fan-bois, cultural relativism, and oral histories. A lot of it is either dated or no longer relevant, but the themes certainly still apply, and Linux is still Linux. And the command line is still there, and we spend oh so much time using it.
Understanding the past is key to the future, whether it's user interface, architecture, cultural directions, market forces, or AV platforms.
Big data is all about statistics, and lots of what we do comes down to statistics. Precision, Recall, MPBE, Code Coverage, SLAs, expected battery life, Texas Hold-em, and more. We look at a large enough sample, do some math (or let a computer do so math that we may or may not be able to follow), pick a threshold, and declare that meeting it is enough. No-one has found a better way. Of course none of the statistics guarantee how an individual instance will go. We can know that 99.9999999% of calls to a web service will take less than 150ms, yet it's still possible for 3 calls in a row to take 200ms. So what's a poor developer/engineer/data scientist/PM to do? It's the old boy scout motto, "Be Prepared". It's defense in depth. It's adding watchdogs and timeouts. It's fallback positions. And it's being honest with ourselves that statistics and probabilities are not certainties, but that's the way to bet. Here's aviewof how it can impact results and decisions in the medical field.
And of course, that didn't work. Turns out that there's a parsing bug somewhere and removing the
type="method" from the <script> tag makes it work. My first reaction to figuring this out was Wat? According to
XKCD there are 10000 people who will learn about Wat?
today. If you're one of the lucky 10000, enjoy
We’re all multilingual. We speak C, C++ (yes, they are different languages, not dialects), Python, Go, Java,
Javascript, Matlab, Assembler, and many others with varying fluency. And that’s good and proper. Using the right
tool at the right time is one of the marks of a craftsperson, just as much as the ability to do quality work with
the available tools is. Master craftspeople not only know which tool to pull out of their toolbox, they also stay
aware of new tools and methods being developed. InfoQ recently published their
Programing Languages Trend for 2019. The list and commentary are interesting for themselves, and even more interesting is some
of the back story about why people are starting to use those languages.
Understanding the problems the different languages are trying to solve can give you a whole new perspective on
whatever problem is currently top of mind for all of us.
And, on an unrelated note, I was looking through some of the repos we have and noticed that many of them have
.envrc file in the root and was wondering what that was for. I took a look inside one and there was this comment
#!/bin/bash
# Users of direnv can run `direnv allow .` here to automatically update the
# PATH.
# enter this directory or any descendent. <https://direnv.net/>
and suddenly a light went off. I’ve been struggling to deal with multiple repos across ATG and Prime with different
(and often incompatible) versions of their toolchains and wondering what to do about it, and there’s the answer. direnv. I
think I can even get it to handle switching versions of arc for me as I switch repos, but I haven’t dug that deeply yet.
Check out direnv.net. As the kids say these days, 10 out of 10, would recommend.
For most of my career I've been working on platforms, From Flight Simulation to 2/D3D geospatial visualization
to infrastructure. One of the keys to building platforms (or for anything really) is customer value. A long time
ago a marketing instructor told me that developers build features, but customers buy benefits. Those two are
very closely related, but they're not the same thing. When you're building a platform they intersect at your
API. It doesn't matter if it's possible to do everything your customer wants
with the API, it has to be easier for them to use the API now, not in 6 months or after a climbing a steep
learning curve. If your API doesn't provide value then your customer will figure out a way around it, build
their own internal API, and leave you stuck supporting it. This is true at every layer, from the OS to the
UI.
So how do you build APIs
that not only provide value now, but are extensible so you can keep adding features without pissing off your
customers. There are many language specific things you can do. From optional parameters with default values to
versioned input/output structures that your API later decodes (as an aside, did you know that most Win32 APIs
take, as an input structure, some base type then check the size of the structure to determine the version?) you
can isolate your customers from your internal implementations/choices.
But those technical details, as important as they are, aren't really the answer. The key is to understand that
users of your APIs are customers, and treat them that way. That means that (within reason) the customer is
right. As William Gibson said, "the street finds its own
uses for things". If they find a new use for your API figure out the problem they're
solving and help them solve it.
Treat your API as a contract
and honor it. Make it simple to understand and do what your users expect. Make it hard to misuse. Don't surprise
them with side effects. Don't leave things in a half-baked state. Think of the "Verbs" your API
supports. REST makes it obvious. CRUD is just a set of verbs.
Bottom line, make your customers want to use your API, not roll their own.
I've seen people wearing t-shirts have the Kanji for Kaizen on them. If you're going to wear
the shirt you should know what you're saying. According to the Googles, Kaizen translates to "Improvement". That's simple enough, and a
worthy goal, but when you connect the term to Toyota it brings in an additional level of meaning, the Toyota Production System, or The Toyota Way. It's about culture and culture change.
It's about expectations. It's about empowerment and obligations. At Toyota it was embodied by the Andon cord and this story:
When asked if they intended to give workers on the assembly line the power to stop production the answer was
"No, we intend to give them the obligation to stop it whenever they find a
problem."
MIcroservices are all the rage. Prime is all-in on microservices, moving from RT-API to thousands of
microservices (there are more services in the Prime call graph then there are engineers). They're
an answer, but are they the answer? Before you
can answer that you have to decide what your goals are, and what the payoff threshold is. At a high level things
like separation of concerns, reduced fragility minimizing unintended side effects and reducing developers learning
curves are good things. Microservices are an approach to that. Of course, like any other choice there are
consequences and trade-offs. Shopify had a monolith that grew organically over time, and at some
point they realized it was slowing them down. Instead of being trendy they took a different approach, the Modular
Monolith, As the
blog shows, microservice or modular monolith, it really comes down to graphs and interfaces. If you can
get that right and enforce it you'll have an enduring architecture you can grow with.
On a related note, one of the most important parts of architecture is being able to explain your architecture/design to others so that they can follow the vision when you're not looking. If you don't do that you have at best a bottleneck, at worst an architecture that doesn't match what gets built. There are lots of ways to communicate architecture, and one of the keys is tailoring the content to the intended reader. Here's a list of ways to communicate architecture.
