Stick along long enough in software development, and you may have come along the ride for Agile software development practices, methodologies, and/or frameworks. Stick along long enough in that community – ok, that might be a reach too far, given that community only exists about 30 years or so. All of the above said, I notice some developments lately around the term Agile, and need to get my thoughts down. Not that I think I have a particular relevant perspective to start with. But maybe I can offer some perspective to one or another reader.
If you know me, you probably know that I have a tendency to look back on where did we come from to better understand things happening in the present. If you are not that kind of understander, maybe this blog entry might not be for you. So, be warned before moving on.
Since minqlx seems to stand for “Mino’s Quake Live eXtension” and I go by the player name of ShiN0 in QL, I thought an obvious name for my Rust implementation of minqlx would be shinqlx for ShiN0’s Quake Live eXtension.
But before we dive into the first steps I took, maybe a few introductory words and maybe some references in case you want to go a similar route.
I recall discussions in the early software craft days on the mailing lists. One thread, in particular, comes to mind today, that was about whether a good crafter should learn a new programming language every year to learn new coding styles and paradigms, and maybe bring those back to their usual work environment.
Last year, Craig Larman recommended learning the programming language Rust to help, especially with embedded programming. Linus Torvalds also allowed Rust as a third language in the Linux kernel development around the same time. It took me a while to actually try it when I found the perfect for me pet project to dive into.
Over the next couple of blog entries, I want to dive into some of my learnings and approaches. Today, let me give you an introduction to the project I picked for my personal Rust learning curve, where I am, and maybe give you an update now and then about the things I still have open to learn.
The other day, someone on the Crafters’ slack posted a video where someone argued about software craft vs. engineering and asked for opinions from the community. Let’s elaborate on my reaction to watching that video.
Stick around long enough in the consulting business, and you might notice something I will coin the Arxta-Moment in this blog entry. I’m pretty sure, I’m not the first one to notice this, yet, I’m unaware of someone giving it a name. Let’s explore some history, and look for some advice from Jerry.
Over the years, I have seen many companies struggling with paying off technical debt and legacy code. Heck, I produced legacy code within a 45-minute session at a code retreat on my own, so consider me guilty as charged as well. Over the years, I have seen a pretty tiny fraction of companies actually managing their technical debt. So, here are a few stories that I oftentimes share from these companies and how they tackled technical debt and legacy code – with no claim for this to be a complete list of things that might work. Please add any additional advice you want to share in the comments.
A few years back, I ran a public course in Düsseldorf, Germany. While looking through my options for one of the evenings, I noticed a public Coding Dojo run by the Softwarkskammer group there and decided to have some coding fun in the evening. During the dojo, I had an experience with one of the attendees that I keep on sharing every now and then.
I think I wrote up on this a while ago. Since I keep on referring to that experience, I thought maybe a reflection on what I think happened a few years later, might be helpful.
Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.
There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.