Tuesday, July 02, 2024

Morphology and Software Development

New libraries and frameworks are not necessarily better, in the same way that success does not equal quality. Typically, the new platform technology simply won against others, perhaps through association with a performant platform, or though momentum from the community, a sponsor, or a monopoly. When Google Cloud Platform moved from webapp2 to Flask, it was not because of set of scientific or engineering or psychological reasons. There was no reasonsing, as such: Flask simply became more popular, and Google didn't properly fund webapp2. Eventually, we had to move from Python 2 to 3, and from datastore db to ndb. And from webapp2 to flask.

Let me demonstrate two ways in which webapp2 was better. These are morphological observations, that is, about the shapes that we perceive when we look at our code. This kind of observation is pretty common in the UX and design world, but for some reason barely discussed in the world of software development environments. The user experience, people pay attention to. The developer experience: not so much.

The first thing lost with webapp2 was the route table. These exist in plenty of other programming environments, but now it is lost in google's serverless python environment. What used to look like this:

# handler blocks
Class People(webapp2.RequestHandler):
def get(self, string):
# code
def post(self):
def people_get_function():
# code
def people_set_function():
# code
def other_people_functions_etc():
#lots of other handler blocks
# route table
app = webapp2.WSGIApplication([('/people/(.*)', People),
                               ('/neighborhoods/(.*)', Neighborhoods),
                               ('/cities/(.*)', Cities),
... )])

The shape of this code lends itself to clusters of functionality.
Do you need to look up how you handle people? Look at the route table.
It's like the table of contents in a book. It lets you find the chapter about people, neighborhoods, cities, etc.

Instead, the approximate equivalent in flask looks like this:

def people_response():
# code

def neighborhood_response():
# code

def city_response():
# code

On first blush, this puts everything, even the external API presentation or URL endpoints, in the same place as the functionality. But in a complex application, you'll now be looking through all of your code for the route, which is a conceptual pointer to an idea, whose name you might not even remember, and it could be in a large file or many small ones. That was something you didn't need to do before. You simply needed to look through your route table, which is small, to re-orient yourself in your appplication. The orienting qualities of such a global shape are not well-appreciated. In Flask, you've got to read everything to find what you want. It's an unecessary tax on memory. When you have many such applications to build and maintain, you have no easy way to "get back up to speed" about your own code, which you might not have looked at for months.

Here's a second disadvantage of flask over webapp2. There is no built-in class model for the primary purpose of the entire server-side application: to build a response to a request.

In webapp2, there was a self. In this self are all the values that came from the internet. This is also where, in the course of the application, you'll put all of the resources that you'll pass back in your response. This was a simple idea: one piece of your server app could focus on handling cookies and authentication, another could focus on stored values to make some sub-domain of the application to work, a third would provide the text or image content, etc.

In flask, to get this same functionality, you need to try to find the appropriate place to allocate a response object: but where? So you need an init that gets called everywhere, and flags to see what you've done already ... it's a mess.

This is also morphological ... flask scatters and brings forward a task that was a background assumption in webapp2.

There are many good, humane ideas that disappear in computing. Typically, they are rediscovered in some form in the future, since these good ideas, at least the morphological ones, are based on what is comfortable for human perception and cognition.

But it would be nice if software developers would develop their sense of comfort. This is the topic of a seminar I host at the Building Beauty school of architecture, which we call Beautiful Software. Computer people can study to improve their access to their innate, natural sensitivities. It would change everything if they did, not just code.

No comments: