Extreme programming is guided by 4 rules. They're very simple, easy to understand, and apply cleanly to how we should be working. However, like any generalization there are lots of edge cases. David Copeland presents a more nuanced approach to try and deal with some of those edge cases and the way we do work.
My daughter is a teacher at the local JCC and as part of their continuing education program I had the opportunity to see Won't you be my neighbor, the story of Fred Rogers and Mr Rogers' Neighborhood. I grew up with his show and jumped at the chance to see it. As an added bonus, there was a short presentation by Hedda Sharapan, who was part of the show from the beginning and is a Senior Fellow at the Fred Rogers Center. Many of you in Pittsburg are very familiar with his story, and he's not a stranger to most of us, so I won't go into details about his story. You're probably wondering what Mr Rogers' Neighborhood has to do with software and autonomous vehicles. I admit when I went in I didn't expect much of a connection, but a few of things Hedda and the documentary said struck a chord so I thought I'd bring it up here.
The first was his focus on making sure we expected and accepted mistakes. Of course, in the show the message was aimed at children, but it applies to people of all ages. Just like children, we're doing things that neither we (nor anyone else) have ever done before. There will be highs and lows. Celebrate the achievements and learn from the setbacks. Blameless incident reports are a great example
That leads to the second, reflection. Hedda said that one the Mr. Rogers said that she always remembered was that television was the only appliance that was at its most powerful when it was off. While he thought much of children's TV wasn't very good, what he really meant was that what was important wasn't the show, but the reflection and conversation afterward. Again, a message for everyone. We learn things and make decisions all the time. It's important to take the time to go back and think about what we've seen and done. Was it the right thing at the time? Is it still the right thing? What should we change and what should we do going forward?
Thirdly, diversity. Of course I don't think he ever used the word diversity, and it was never an explicit topic. It simply was part of the neighborhood and how Mr Rogers' world was. Everyone is unique and special. Accept people for who they are. We all have something to offer, whether you use Vim, Emacs, or Notepad++
Finally, just to bring this back to tech, here's Fred Rogers' approach to STEAM.
Speaking of feedback loops and developer velocity, is there a way to look at the way we've done things in the past, learn from it, and make changes so that we can move faster in the future? In the software architecture world we talk about patterns such as monoliths, microservices, event driven, and space-based, but what if there's a better way to think about it? Instead of letting the system components drive the architecture, what if we let the interfaces drive? Clean, clear, understandable interfaces reduce cognitive load. This lets people and teams focus on the value add they bring to the overall system and not worry about, or be surprised by, the implementation details of the components around them.
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 links and a reminder that there are lots of resources available in the O'Reilly library, including this book.
It's not just for PMs and UI designers. How can we be more engaged and bring joy to our teams and customers at the same time?
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.
