Recent Posts (page 67 / 70)

Code Reviews

A big part of a developer's life. They can be a great way to get a broader perspective on the code you've written and suss out hidden gotcha's others know about. They can also slow you down. Multiple iterations, arguments over style vs substance, or just waiting for someone to take a look. There's lots of anecdotal evidence (user dreams/nightmares) on the topic, and even some more academic publications. Starting from the idea that code reviews are worthwhile and we want to make the most of them, how do we avoid some of the perils? Here's a couple of articles on that provide some guidelines.

Building And Scaling A High Performing Culture

Today’s link isn’t directly technology, but it’s oh so related to everything we do. It’s a little longer than some, but very foundational.

How do we build a culture that supports high performing teams? I’ll bet many of you have heard of Bruce Tuckman’s Stages of Development

Tuckman’s Forming, Storming, Norming, and Performing model is a really good way to describe how teams come together and grow, but isn’t very prescriptive about how to help a team get from one stage to the next, particularly how to get to Performing. In fact, change is hard. Changing culture is even harder. As someone once put it to me,

In the battle between change and culture, culture almost always wins.

If you want change, first you need to change culture. So, how do we change culture?

Check out Randy Shoup’s article

Metaprogramming

Code that changes based on it's data. Heady stuff. Generics are a thing in many languages. Used properly they can be amazingly powerful and abstract complexity away from the developer. Used improperly they add unnecessary abstraction and make it harder to understand and debug code. There are also different "levels" of generics, from function overloading to Rust's implementation. Our challenge is to make the right choice so that we can make progress today and be prepared for the future. To do that we need to understand what generics are and the trade-offs around their use.

Beyond Accidental Architecture

Software always has some architecture. Often it just happens based on the conditions at the time of development. That's accidental architecture. On the other hand there are lots of benefits to moving beyond accidental architecture. Check out the slides.

Pipes

Today, a little bit of history. Think about the lowly pipe |. Where did it come from? Is it really that important? How is something that was developed overnight 45 years ago relevant today?. Then think about rNA and how there's a graph of data flow. AXL is more than a simple |, but conceptually it's | + tee. Something to think about. And for further reading, the Bell Systems Technical Journal from August 1978. Check out the bottom of page 8. So much of how we do things now comes from those 4 simple rules.

State Machines

If you wanted to teach a class in state machines, defect reports would be a great case study. They have a very limited set of states and clearly defined rules for when to transition between them. They don't always touch every state, and they can have cycles, going back and forth between states. One common question with defect reports is Who Closes Out the Defect Report. Some say the developer, some say the TPM, some say the tester, but I think it's really pretty straightforward. The person who opened the report is responsible for closing it. Mike Jennings says it better than I can.

This also applies to things that aren't obviously defect (bug) reports. Consider comments in a Google doc. While they might not be labeled as defect reports they indicate an issue with the doc. It might be a lack of clarity, it might be a missed case, it might be a factual error, or something else entirely. Regardless, the comment indicates a problem. It is typically on the doc author to respond to the comment, but others with the answer can also chime in. Either way the response and/or change to the doc is there to address the "defect" in the doc. So who closes the comment, if anyone? I've seen at least four different approaches.

My preferred method is for the author of the comment to mark it as resolved when they feel the issue has been addressed. When all comments are resolved then there are no open issues. Those that want to see the comments can enable the comment threads to be shown.

Second is for the author to somehow indicate that the issue is resolved by added to the comment thread and then leave the comment open. In this way there positive acknowledgement that issues have been resolved (albeit hard to tell), but the comments are easy for everyone to view.

Third is for the author to respond to/address the comment and if the commenter has something else to say they do. In this case you're never quite sure if issues have been addressed.

Last, and the one I'll push back on every time I see it, is for the author to respond and close the comment, relying on the commenter to re-open the issue if they want. To me this is exactly the wrong way to approach it. Comments indicate an issue a customer has with the product. The only person who knows if the customer's issue has been resolved is the customer. Anything else discourages people from reporting issues and disenfranchises them. Cutting the customer out of the loop is never something we should be doing.

This doesn't mean that we always do what the customer wants or that every issue will be addressed to every customer's satisfaction. It's perfectly valid to tell a customer, "Yeah, it's not great, but this is what we can do here/now. We'll worry about your issue later." or "I don't think that's an issue because ...". but we should always acknowledge the issue and not lose track of it.

XP

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.

Won't You Be My Neighbor

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.

Interface Driven

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

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.