FAFO on GitHub

Zoom report. Simplest thing that could possibly work.

Last night, Tuesday, the Friday Geek Night Out Zoom Ensemble has its weekly meeting. We were all pretty low-energy for some reason, perhaps Impending February Syndrome, but we did review my FAFO experiment.

Either it was the low energy, or everyone picked up on what I had done quickly. There were no significant comments, but of course the thing is so simple, I didn’t expect many. I did have the occasion to speak of the limits of the current fetching approach and was able to toss in the buzzwords: disjunctive normal form and conjunctive normal form. Those may appear again in subsequent articles, or then again perhaps not.

GeePaw had spent the intervening time thinking about his app and its desired data structure, which was the point of the weird idea. We’ll discuss that general point in a moment.

GeePaw has decided that the document structure is tree-like in that some documents will be made up of other documents. If he has addressed the question of interleaving text and references to sub-documents in a document, we haven’t discussed that, but it seems to me that a) he’ll want to do it and b) it doesn’t really change the fundamentals of the design once you decide that any document can have child documents. He proposes that the same document can be a child of more than one parent. Simple example: different documents might use the same explanation of Git.

A course or bit of a course will consist of a (mostly?) linear path through documents.

GeePaw has seen that the entire curriculum, all the documents, can readily be kept in a system folder, and if time-stamped, prior versions can be moved to an “old versions” folder when a new version is created. Users will see the new version the next time they click it. He thinks there’s no need to allow students to see old versions, and we all agree that if it were necessary, there’d be some way to do it: the information is there.

GeePaw plans to proceed with the app. Whether he’ll take on helpers from the FGNO, and whether any will apply, is yet to be seen.

So that’s my report on the evening.

Further Thoughts
On the one hand, I can see how the structure can be made to work, and yet I think there will be some interesting issues around drawing linear threads through a tree structure. If the tree remains static after the threads are drawn, it should be OK. Otherwise, I fear it could become very ad hoc and subject to errors. GeePaw is smart and will be able to make it work, but I much prefer structures where the treatment is quite regular and inherently capable of representation with simple, clearly correct code.

There may be such a thing for this linearized selection of tree-structured information, but I don’t know one offhand.

The Evening’s Larger Observation

The point of the weird advice to think in terms of the simplest thing that could possibly work (“everything is a file”, in our case) is to allow the developer to forget about the representation of information as relations or S3 instances or whatever, and to focus on the structures and logic that the application really wants.

The Kent Beck saying from which the advice stems was his frequent mantra: What is the simplest thing that could possibly work? And Chet made the observation that would win the coveted Observation of the Week award if we had one.

He said that sometimes people focus on the “simplest thing” part of Beck’s remark, but that the point is to focus on what will work.

And that’s exactly what GeePaw did. He stepped back from much concern over how storage would work, and drilled in on what it had to do, what structures of documents, authors, cohorts of students looked like. We all agreed that more of that needs to be done, and that probably we’d want pictures or other ways of expressing the various structures and the changes that can be made on them.

So there’s the payoff.

When faced with a needed chunk of complex functionality, don’t focus on the technology to support it, focus on how it will need to work. One way to do that is to think of the simplest technology that could possibly work, and then set that aside (or let me work on it) while thinking about how the application should work.

Of course, as we think, we’d be writing tests and code to clarify how it works and that it works, and that while we do that, we’d use that “simplest thing” to support those tests and code. Doing so would let us focus on the interface between the application and the information and behavior that supports it. Then, someday, if we really need to, we can figure out how to stuff it into Lambda or something.

And, quite often, we won’t even need to do that anyway. Chet might say it better, but all I have here is me:

Simplest thing. Make it work.

This is the way.