Welcome! Please see the About page for a little more info on how this works.

+5 votes
in Other by

Rich mentions that things like performance are a property of the artifact, not the construct. But that we focus so much on the experience of the construct with a reference to the amount of typing required.

So, what's one critical area where we have to distinguish these two
things and look at them from a perspective of them being easy and
being simple? It has to do with constructs and artifacts. Right? We
program with constructs. We have programming languages. We use
particular libraries, and those things, in and of themselves, when we
look at them, like when we look at the code we write, have certain
characteristics in and of themselves.

But we're in a business of artifacts. Right? We don't ship source
code, and the user doesn't look at our source code and say, "Ah,
that's so pleasant." Right? No? They run our software, and they run it
for a long period of time. And, over time, we keep glomming more stuff
on our software. All of that stuff, the running of it, the performance
of it, the ability to change it all is an attribute of the artifact,
not the original construct.

he then goes on to say

Does the software do what it's supposed to do? Is it of high quality?
Can we rely on it doing what it's supposed to do? Can we fix problems
when they arise? And if we're given a new requirement, can we change
it? These things have nothing to do with the construct, as we typed it
in, or very little to do with it, and have a lot to do with the
attributes of the artifact. We have to start assessing our constructs
based around the artifacts, not around the look and feel of the
experience of typing it in or the cultural aspects of that.

The "Can we change it?" gives me pause, I would have thought that was an attribute of the constructs used to build it.

He goes on to say

One of the problems I think we have is this conundrum that some things
that are easy actually are complex. So let's look. There are a bunch
of constructs that have complex artifacts that are very succinctly
described. Right? Some of the things that are really dangerous to use
are like so simple to describe.

Which gives me even more confusion about what an artifact is in this context! I originally thought it was a software project, but now it doesn't seem so.

This quote seems helpful for answering, as indicates that simplicity is about the artifact. Not the construct.

So the first part of making things simple is just to choose
constructs that have simple artifacts. But we have to write our own
constructs sometimes, so how do we abstract for simplicity?

2 Answers

+3 votes

I believe "construct" here is about what the programmer uses and creates (programming languages, libraries, programs, etc) and artifacts are about what users experience. And I mean that in a broad sense - not just the UI of a program, but also how your business stakeholders experience the project over time - in terms of quality, performance, ability to respond to changing needs, etc.

And the point being made is that we should judge the construct based not on the creator's experience but on the user's experience of the artifact.

At least that's my take on it.

+3 votes

I'm a bit surprised that talk doesn't include definitions of "construct" and "artifact" given how fond Rich is of defining words...

I looked up the definition of "artifact" and got this:

  • something observed in a scientific investigation or experiment that is not naturally present but occurs as a result of the preparative or investigative procedure.

So "construct" is the things we build software with and "artifact" is the things that everyone observes about what we actually built.

I think he's saying that the closer we can get to a 1:1 relationship between what we build and how it behaves/how it is observed -- simplicity of mapping -- the easier it becomes to control what artifacts will be observable (and thus the simpler those will be).