Software Engineering

There are 45 posts filed in Software Engineering (this is page 1 of 5).

Thoughts about “working together”

Today, Dave Winer talks about “working together”, and how he wants to work with other people. The bug in this statement is that Dave Winer deletes things from sites he provides for others to try out his tools, talks about “spam” posts (which is his word for someone trying to make use of his “flow” to promote their “personal projects”) and how he will “moderate” them, and other abusive behaviors. That turns off users and developers. I have personal experience with this, and reports from other users/developers.

Next, he talks about he wants to work together, but what he gets instead are people (collaborators? partners? who?) who want to be him (what does that mean? does it mean they want to be in charge of the project/control the project?). He talks about how people wanted to take over RSS and OPML. I will give him the benefit of the doubt of his lived experience, but my lived experience of working together with people (mostly working in teams in corporate software development) is that a goal is established, roles and responsibilities are laid out, scope and schedule are defined, and the team gets to work until the goal is met. My observation of the way Dave Winer works is that he controls the project, he does all the development and only changes code in an outliner (although Claude is now a silent partner), will not accept PRs, and gets upset when he ends up being the “only person” answering questions in Github issue repos.

Finally, here is a quote from the “Working Together” post he references in the post above:

Working together means this: If someone else has a good-enough way to do something, rather than reinvent what they do, incorporate what they do into what you do.

So – all of the other chat programs in the world were not “good enough”, so they need to be reimplemented using “RSS 2.0 feeds and websockets” (quote from rss.chat repo README file)

From monitoring the rss.chat and demo.rss.chat sites, I see some of Dave’s former co-workers/collaborators are building some things to work with rss.chat. Hope that works out for them!

Podcast about using formal methods in software development

Hillel Wayne explains why formal methods like TLA+ matter, how they help build reliable software, and whether AI will finally bring formal verification into the mainstream.

I enjoyed listening to this, I am planning to watch the video since Hillel Wayne shows some tool demos. I have not used formal methods in my career, but I did investigate them, and did play with TLA+.

Regular podcast and transcript/summary also available at The Pragmatic Engineer.

Should the software engineering profession pursue collective bargaining?

Greg Wilson, who has built a significant career in the field of software engineering, recently wrote a set of essays called “Sex and Drugs and Guns and Code” with the sub-title “a few things programmers should know about society to understand big tech, social media, and AI”. The essays cover a wide set of subjects, with this intent from the introduction: “The essays that follow will explore a few things I wish I had known earlier: where power comes from, how it is used, how its use is hidden, and how people have held the powerful accountable and made the world a fairer place.”. Greg also provides multiple references to other sources supporting the topics in the essays, which I greatly appreciate.

For today, I am going to point to one of the topics – collective bargaining. My experience in software engineering within the aerospace industry is that almost none of the engineers I worked with were part of a union. The only example I have heard of is an engineers union at Boeing, which is an affiliate of International Federation of Professional and Technical Engineers (IFPTE), AFL-CIO. In one of my previous companies, a co-worker made a comment about “we ought to start a union”. I said; “You say the word and I will call the AFL-CIO!”. When I checked into it though, we would have to get people to sign cards to indicate interest, then fight with management, etc. I told this to my friend, and he said “Sounds like too much work”, and that was the end of that.

Recently, I had lunch with a former colleague who is still working at one of my previous employers. His tales of office politics and lack of promotion opportunities made me glad that I was retired. I related the story I listed above, saying that it was an alternative to “stay or leave”. I am not sure if anything will come to it, but I felt the need to share.

I also told my friend about this series of essays – again, he did not express immediate interest, but I think I will send him a link. I think this paragraph from the essay “When The Algorithm Comes for You” is appropriate, given that AI is transforming the software engineering industry (bold text is my addition):

In 2023, the Writers Guild of America struck for five months over issues that included AI. When the strike ended, the WGA had won explicit contract language: AI cannot write or rewrite scripts, and scripts cannot be used to train AI systems. The Screen Actors Guild reached a parallel agreement that included restrictions on the digital replication of performers’ likenesses without ongoing consent [Kelly2022]. These victories established enforceable contractual limits on what employers could do with AI—limits that individual workers negotiating alone could never have secured. The lesson is not specific to Hollywood: wherever workers have collective bargaining rights, they can negotiate from a position of strength. Professional associations, open-source communities, and standards bodies can create analogous leverage in sectors where formal unions are absent or weak.

Since my retirement, I have had time to reflect about my career, the difficulties and successes, and how I could have approached things differently. I think I will add that topic to my “Future Essays” list….

Co/Recursive: Beautiful Code – Inside Greg Wilson’s Vision for Software Design –

Greg Wilson has been on a decades-long quest to transform how we teach and talk about software design. From getting rejections for using the term “beautiful code,” to empowering scientists through workshops on Python and Unix, Greg has pushed to bridge the gap between theory and practice.

Join us as Greg shares his failures and epiphanies along the way. You’ll hear how he revolutionized research computing by showing physicists the power of profilers. How he taught grad students the elegance of shell scripts. And how he’s crusaded to create a shared language to discuss software architecture with the nuance of true craftsmanship.

Greg’s captivating journey reveals that with perseverance and the right examples, we can elevate software design discussion to an art form. But that we’ve got a long way to go. You’ll come away enlightened and eager to level up your own understanding of software design.

Greg Wilson: Eleven Tips for Organizational Change “This was a proposal for the US Research Software Engineer Association 2023 conference, but was rejected…. I recognize that they are incomplete—in particular, that they are strongly biased toward what works in affluent, democratic societies—but if you’re tired of rolling heavy rocks up steep hills over and over again, maybe they will help.”

Booklist Browser app update

This weekend, I moved my cut at Booklist Browser app requirements from the Github issue to its own page. Next, I took a cut at defining the possible domains for the Booklist Browser app, using concepts as described in “How to Engineer Software” by Steve Tockey (https://www.construx.com/books/how-to-engineer-software/). My next step will be to define use cases based on the domain definition and requirements.