Understanding Patterns of Project Behavior

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior is a useful catalog of project specimens and anti-specimen. As a catalog it does capture much of what I have experienced (and participated) during projects. Like Brook's The Mythical Man-Month, the information contained is, unfortunately for our industry, evergreen. I would not categorize this as a pattern or anti-pattern catalog, however, as, unlike good patterns, it does not regularly offer solutions. Nevertheless, its is worth having around if only to remind yourself that you are not crazy, the project is.

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

SQL Antipatterns: Avoiding the Pitfalls of Database Programming is a useful compendium of common relation database design flaws. There are a number of anti-patterns where a single table is used to implement a data model that actually has more than one entity. Or, a metadata data model is implemented using a single table or multiple tables where, respectively, the reverse is better. The content is split into 5 parts: logical design, physical design, query, development, and appendixes. The first 3 are the most relevant to the book's title. The development chapter does have useful information on good application development practices, but could have been left out. Overall, worth reading and keeping on your shelf to share with others (and a reminder to yourself!) as the need arrises.

Sol Rashidi on delivering an AI product

This interview Your AI Survival Guide • Sol Rashidi & Joe Reis • GOTO 2024 is a useful discussion on delivering an AI product.

I read Sol Rashidi's book Your AI Survival Guide. While it is focused on delivering AI projects, it is also her distinctive take on project teams and delivery in general. Chapter 4, "How to Start", is very good and worth reading alone. I especially liked the quantitative readiness assessment as a means of selecting whether the business should be attempting an efficiency, productivity, effectiveness, expert, or growth AI strategy.

Kent Beck & Tidy First?

Kent Beck, of various software implementations and processes fame, has a new book out Tidy First?. It is the first in a series on software design he is planning. This very slim book is in 3 parts. The first two have practical advice as to if, when, and how to tidy code. The recommendations are good and can be taken one at a time as needed. The third part is a giant leap away from the keyboard and into the economic and opportunity costs of tidying and software development in general. I know when I first started coding for pay no one talked about these issues and so it is great to see them succinctly presented here.

Two civic tech books

I am currently working with a US state's education department to move its infrastructure and applications to the cloud. This is my first time working directly on a government project and it has been informative. To gain a broader understanding of the field of civic tech I read the books

A civic technologist's practice guide
by Cyd Harrell
cydharrell.com

The service organization
by Kate Tarling
theserviceorg.com

Harrell is writing in the context of the US and Tarling the UK. In many ways their persuasive styles seems to reflect the two broader cultures too.

Harrell's book contains a broad introduction to US government (all levels) and how work is accomplished there. It provides a good guide to these and provides effective strategies for success, whether working from inside or outside government. The book begins with the important topic of reckoning with privilege and ends with the need for self-care in, what can be, an intellectually frustrating and emotionally exhausting environment. I am pleased these were included. The resources at the back of the book look to be well considered (as are the few footnotes within). There is no index. I recommend this book if you are considering participating in civic tech.

Tarling's book is less about the current context of the work and more the means to change that context. To move from stovepiped departments to cross-disciplinary teams focusing on providing the whole service. Ie, product oriented rather than platform oriented. The national context is the UK and not the US, nevertheless it is helpful to see the kinds of tactics and artifacts needed to facilitate the transition. The book has a generous collection of resources at the back. There is no index. I would recommend this book if you have decided to participate in civic tech.

Pro Git

When learning a new topic it has been my experience that you read several explanations and tutorials and finally, the last one you read makes the topic crystal clear. I don't think it did. It just was there when you finally annealed all that information into those crystals. Anyway, if you are learning git, as I am, even though I have been using it for years, the book Pro Git by Scott Chacon is working for me. I have not finished it yet, but so much is clearer now.

Macroservices, a middle ground between the monolith and microservices.

There is a middle ground between the monolith and microservices and that is "macroservices." Macroservices are distinguished by having one executable and many compositions. Each composition exercises a portion of the executable's internal components. Some of the components are exercised by all compositions (eg, identity management) and other components by singular composition (eg, a specialized data store). Composition deployments communicate with each other with REST or gRPC. Orchestration for resilience and scaling is accomplished using the same tools as for microservices.

A composition is nothing more than a declaration of a set of components to activate, their interdependencies, and their configurations. Configurations are generally properties, ie name and value pairs, accessed from the environment. Much as when you build the executable and draw all the benefits of type checking, unit testing, static analysis, etc you can build the composition and draw similar correctness assurances.

A macroservice allows your small team of developers to focus on what matters to your business, ie what your customers value. The development infrastructure is simple. The deployment infrastructure is flexible. Troubleshooting is comprehensible.

Written in response to Microservices are for companies with 500+ engineers.

Update: Perhaps a better name is "polyservices".

Update: I am reading abandoned Sam Newman's new book Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. My macroservice is more akin to his distributed monolith except that the services contained within do have stronger data independence than is typical of a monolith.

Update: Introducing Service Weaver: A Framework for Writing Distributed Applications | Google Open Source Blog

Ousterhout's "A Philosophy of Software Design"

Greatly enjoyed John Ousterhout's Google talk "A Philosophy of Software Design." It is for the Tcl language and the Tk user interface toolkit that I know him. I was a fan of Tcl back in the day when you didn't add a REST API to your application, instead a you added a scripting language. For that purpose Tcl was a perfect match: easy integration of the interpreter into the application and easy extension of the interpreter with application functionality. Tcl did not make the transition to the Web and so has mostly faded into software development history. If you think DSLs are awesome you wish your language had uplevel and upvar. If you think Docker container images are awesome you will be interested in Tcl's Startkit.

In this talk Ousterhout is chronicling his attempt to teach software design at Stanford University's CS 190: Software Design Studio class. I want to find out if the local universities are trying this and offer to be a teaching assistant.

Update: I have two copies of his book A Philosophy of Software Design, but, sadly, neither has yet been read.

Slack for One

I have a deep background thread running in my head that started when I read in The Year Without Pants: WordPress.com and the Future of Work about how Automattic, Inc. created a new Wordpress site for every bug. I tend to think of blogs as having weight. They are heavy. However, this is psychological response to how blogs have been used. Technically, they are not much more than a column value in a database table. One of the lightest datum there is. Slack is no different in this regard than is Wordpress; Slack's Workspace is no more than a column value in a table.

Recently, I had the idea that you could use a private Slack site for personal projects and journals. Each channel is a new project or a journal. Slack's chronologically organized messages allow for text, images, (simple) formatting, and the inline inclusion of external content such as from Google Apps. There are many bots for managing each project's actions and reminders, for example. And if you do need to share the project you can. As I thought about this more there seemed no end to how to use Slack as purely a personal information tool rather than a group communications tool. I wonder if anyone has actually used Slack this way?