Control Theory. Feedback loops. PID Controllers. As someone who was formally trained as a mechanical and
aerospace engineer and cut his teeth on flight control systems and air combat AI those words are music to my
ears. Autonomous vehicles are feedback loops wrapped inside control systems surrounded by a two sided
marketplace. But what does that have to do with the theory and practice developing and deploying code? Check out
this talk (and transcript) PID Loops
and the Art of Keeping Systems Stable.
Or to put it a different way, does your design model the CPU or the data? A 60 second video on the difference and a slightly more detailed version in text.
Worse is Better, Perfect is the Enemy of Good, and The Cathedral and the Bazaar. Lots of different ways to think about the same thing. There's the "Right Thing"™️ and the New Jersey approach. Is there a correct answer? If so, which is correct? Is it situational? If it's situational, what are the situations? This one is so deep that the author of the original Worse is Better paper spent the next 10+ years developing a second persona and arguing with himself about it and still hasn't come to a conclusion.
My personal bête noire. I know we're going to create some. That's a good thing and we should do it.
That's not the question. The real questions are how much should we take on, and when/how should we pay it off? As we
transition from On-Prem (IRN) to Cloud (EKS/EC2) and HDFS/Posix to HDFS/S3 we need to balance today's business needs
and developer velocity against tomorrow's. To help frame the problem I offer
these linksand a reminder that
there are lots of resources available in the O'Reilly library, including this book.
There's been an interesting conversation in gophers and python dev mailing list over the last few days, so I
figured I'd send some links on ORMs for you all to peruse. Another thing to think about as services/processing moves
and dB choices are upon us yet again.
Today's gem is from Raymond Chen's The Old New Thing. Raymond is an old Microsoftie, and among other things he was an SRE back before there were such things. Of course then we called them Sustainability Engineers, and their job was to make sure everything stayed working and existing functionality didn't break with releases and updates. This was especially important back in the day because releases happened every few years and quarterly updates were considered quick. Many of Raymond's postings explain why Windows is the way it is and how things that look like poor decisions now were actually the best decision possible at the time and for a long time after. Others talk about Tech in general, the human condition, and how the two interrelate. This one is about tech and engineering and sustainability in the face of time constraints.
In honor of the completion of the Apollo 11 mission, I give you Margaret Hamilton, lead developer for the Apollo Guidance Computer software, and the AGC software itself. It's old (1969) and in assembly, but here it is.
Two things in computing are hard. Concurrency, Distributed Systems, and Off-By-One errors. You'd think reliably writing a file wouldn't be one of them, but you'd be wrong. Luckily much of the complexity is hidden from most of us by "the system", but you'd be surprised how much potentially leaks to user code.
