John Elam - Home | twitter:@elamje | my coding flow playlist: spotify | coding music: List | me now
software artifacts
Aug. 10, 2021

One of Webster's definitions of artifact says, "something or someone arising from or associated with an earlier time especially when regarded as no longer appropriate, relevant, or important." This seems particularly relevant when thinking about systems that generate states that may only be relevant for a particular period of time. What happens after the original state changes? Is the reference still relevant or appropriate? These questions plague software systems - lost database records, versioning, dead links, and bad states are each examples of where artifacts can go terribly wrong.

When we delete a record in a database, we like to think that our hands are clean. We delete it and the object no longer exists. The reality is much messier. More likely than not, our database row was just 1 representation of an artifact (residual state generated by the system). When we created the record, we might have shown the user a link that they copy and send to a friend, or send an email with some of that data in it. We don't control how they share the link or the email, so we must think about how these artifacts are handled in the new "deleted" state. Recently, I've discovered how important this is with our system.

We've been implementing and "archive" functionality. However, when our system generates some records it simultaneously generates an email with a link back to another UI on our platform. Both the email and the link are artifacts that our database is not capturing in a first class manner. Yes, we can technically write a query to see that these artifacts do in fact exist, but the messy reality is that we have little to no control of these artifacts after they flow out of our system. The link now exists forever (thanks to the user sending it to a friend) - and we don't want to break the link. The email now exists forever and we don't want the user to respond to a dead email. The reality is that implementing "archive" has gone from simply hiding the record in the user's UI to now thinking through what happens when the link is visited after archival. Should the link work at all? Should the link still have a user input form? Should the form take input? Should the comments section of the link still allow new comment creation? A 2 hour archive feature just turned into a 2 day exploration of all the different states that an artifact might take on.

Crucially, when users and business teammates are waiting on these types of features and no one thought through these artifacts as part of the feature request, timelines slip. As the implementer or technical manager of these systems you must be able to communicate these 2nd order effects to teammates. More importantly, you must train business teammates to think through these 2nd order effects in advance so expectations are aligned with reality.

Tags:

back. | home.