Choose your technology for the long run

Have you noticed how some constructions age well, while others do not?

Let's take restaurants. In some cases, the owner makes a big thing out of the restaurant opening. Everything is shiny, and you might get to notice a little anxiousness in the waiter's movement. But, you go in the same place two years later, and you are likely to not recognize the place anymore. The shininess is long gone and it is replaced with little patches in several places. Perhaps you will start seeing various notices printed on A4 and sticked with a scotch against the glass. Perhaps the floor is scratched because the materials were not meant for heavy duty. Or perhaps the coffee machine makes too much noise. And people react slower than you would expect.

In other cases, the opening of a restaurant is perhaps less of a fancy thing. And even if it is, everything is not quite shiny. In fact, everything seems to be rather old already. But, you go there two years later, and you get a cosy feeling of déjà vu: it still looks similarly old as it did at the beginning. People present a relaxed as opposed to an anxious smile. And even if there is some extra notification shown somewhere, you will notice that it appears in a dedicated place that is somehow integrated with the rest of environment.

While in both cases we seemingly deal with restaurants, the design process is dramatically different. One optimizes for the first day. The other one focuses on the day from two years later.

This does not apply to restaurants only. For example, while still a student, a new and fancy bank building was erected right in the middle of the student campus. I say fancy because the glass and steel made it look like that. Even the stairs were carefully crafted and had a beautiful stainless steel balustrade that was shining in the sun. Yet, in spite of its stature, the feature that attracted students the most was the ATM machine from in front of the building. To go to this ATM, students would have to climb the stairs. Given that there was only one ATM, queues were formed easily, and once a couple of people aligned in the queue they would lean against the beautiful balustrade. It was pleasurable just to wait there, especially when the sun was shining. But, two weeks after the big inauguration, a couple of A4 papers appeared clumsily sticked to the glass and balustrade telling people that it is forbidden to lean against it. The problem was that the balustrade was not meant for heavy duty, and the only way the owners could fix it was with an ugly patch. Obviously, it did not work, and soon after the balustrade was gone and original holes were continued to the seen long after.

I am sure you can find examples from your own experience.

Designing for the inauguration is an obvious impulse. But, it is designing for two years after that makes the investment profitable. The two efforts might look the same, but they are significantly different in nature. Designing for the inauguration relies on comparing solutions by taking snapshots. For example, according to this point of view, you choose the tiles by the way they look in the shop while being hanged on the wall. Designing for two years later focuses on processes and requirements that emerge in time. For example, for deciding the tiles in your restaurant, you might observe how they look in various shops where they are used for a while. And to ensure success, you might want to ask about the tools to use to maintain the tiles, too. This is obviously less obvious. Because the long run is usually less obvious and it is more difficult to serve, often vendors try to emphasize what you can perceive at first. Thus, you end up judging the looks and the price.


Why is this relevant for software development?

Think about how you choose the technology for your system. What do you focus on? You likely look at how cheap it is to build your system with it. Or how you can build scalable solutions with it. Or how performant the solutions are promised to be. And you certainly look at the price. Based on this input, you choose the technology and build your system on it.

You know at first that you have to learn this technology, and you put up with the learning costs. You learn as much as you need and you will get your system flying. Everything appears fine.

But, two years down the development lane, you find yourself spending a large part of your time trying to fight with all sorts of technological implications. Often you spend your time figuring out what you have below your system so that you can fix the various problems you encounter along the way. At this time, it is assessment, not forward development, that consumes most of your energy.

I had the opportunity of observing several enterprise projects using various Java technologies. One thing I noticed in all of these projects is that beside exploring code for long periods of time, developers and system administrators also spend a significant amount of time going through configurations and logs. The configurations are scattered through multiple files and are typically edited with text manipulation tools. The logs are mostly not structured and the only way to inspect them is via simple text search and manual scrolling. The other thing I noticed is that nobody really feels like smiling when this happens.

You have to understand the nature of your work to be able to plan for it. Choosing a technology has a lasting effect on your system. Perhaps it would be a good idea to focus on what happens two years after you start. Perhaps you should not only ask questions like "how does the technology help me build my system", but start with "how does the technology help me find a bug in two years from now?". If the answer you get is "look into the console," or "just use a text editor," you might want to reconsider.

By the way, have you ever encountered a vendor that emphasizes how his technology addresses the long term hidden costs? I haven't. They would rather prefer you to focus on the now and on the price. That is why technology comparisons typically only talk about forward engineering support, and not about how you can assess an existing system. But if assessment does imply extensive costs, why should you not want to plan for it? For example, if debugging is an activity that induces large costs, why should you not deserve proper debuggers that reduce this cost? If configuration management is a recurrent activity, why should you not get a properly integrated environment to keep the costs down?

We need to adopt a long term focus in our technologies. This is both a vendor problem as it is a consumer problem. The consumer has to learn to ask for the long term. The vendor has to make it his responsibility to serve that long term. There is no reason why the vendor does not provide debugging tools that are specific to the technology. There is no reason why the vendor does not provide an integrated environment that is specific to his technology.

Oh, wait. Actually there might be a reason: cost. These industry standard technologies are based on other industry standard technologies. And none of them makes it cheap to build dedicated tools, and the more to the top you go, the more difficult it is to change the tide. As a consequence, a whole industry is willfully ignoring the future.

This leads me to Pharo. Being a board member, I am biased, but Pharo focuses primarily on building a live environment. This implies tools that keep up with the mental process of the developer, as opposed to tools that continuously require diving into tedious low-level details. This implies highly flexible infrastructures that can be easily bent towards specific technological requirements. Reflection is not nice to have, it is a mandatory feature. A debugger is not nice to have, it is mandatory to have it customizable. An integrated environment is not nice to have, it is a must to be able to edit everything at runtime. An inspector is not nice to have, it is a must to have it present multiple facets of the objects. An explicit compiler is not nice to have, it has to be adjustable. Analyses tools are not nice to have, they must be integral part of the environment.

These might appear to be cosmetics, but they have deep implications on software evolution. And you get a completely new kind of programming. We call it "live programming".

Evolution can only be experienced in time. It is not obvious, but you can get prepared by understanding what is important for you. Afterwards, you can start to steer.

Posted by Tudor Girba at 10 September 2013, 10:24 pm with tags pharo, moose, assessment link
|