Legacy systems revisited

This post is actually not inspired by this years GOTO Conference, but the one 2 years ago in Copenhagen. I can’t remember if it was in a talk or it was during my discussing with Dave Thomas in one of the breaks, that he started talking about “Legacy systems”. I was kind of star struck, so I didn’t question anything he said – well, not until I got home anyway. When I was looking through my old posts, I found this entry, where I asked how others would define the term “Legacy System”. Nobody really coined it and I’ve been meaning to follow up on this post for 2 years now, but never got around to it before now, so here goes. This is my definition.

Technology needs to be dead or dying
If the system is build on a brand new techology, it is hard to argue that is has any kind of legacy to it. It has to be something that has been, something that was state of the art, but not any longer. The technology was either adequate or simply the best available at the time the system was build, but the world/company moved on and the chosen techology had a hard time keeping up with new demands.

Systems has to have substantual/significant value to the company
If the systems does not have any value to the company, it can be turned off. The revenue stays the same and nobody will miss it, therefor the cost of having it running needs to be less than the loss of shutting it down.

The rate of new features added is going towards zero
If features are still add to the system at a high rate, I would argue that it is a system still under development. This to me indicates, that its technology can keep up with demands, thus it is not dying. The system needs to be in a state where it either sufficiently solves the business needs or the pain and cost of adding extra features are higher than the revenue from adding them.

The time spent on new features is less than time spent on bugfixing and maintenance
Though the rate of adding new features is going towards zero, I will still argue, that if more time is spent adding features that maintaining the system, it is still under development. Every time a feature is added, the value of the system increases and if it increases more than the cost of running it, the company is investing thus the system is still under development, therefor it is not a legacy system. It has to be in a state where the company invests less in adding new features than the cost of running the system.

* * *

So this basically sums up to be an old system that have a substantual/significant value to the company, a system that does not grow in value but needs to be maintained, so it does not devaluate.

What is “simple”

So I was all high on simplicity yesterday and of course Frank had to ask me the question that made me crach land again: “So, what do you mean by ‘simple’?” I almost didn’t hear this mornings talk from Brian Goetz about lambdas in Java, since me head was crunching that question. What is “simple”, what does it all mean?

It struck me that I need to be able to measure complexity to answer that question. I need some way of comparing to things and say, that one is more complex than the other. Looking at code, at a system, at a framework, we have en intuitive understanding of simple. But it is not only intuitive, it is subjective. If something is easy to do or easy to understand. Does that make i simple?

I’ve been doing karate for years and it is pretty easy for me to round house kick someone and kill them 3 times before they hit the ground. Does that make it easy to do, thus simple? Not really. Karate is hard and complex, I just practiced a lot. So easy to do, does not make simple.

What about easy to understand? I understood most of Brian Goetz talk about lambas in Java without a big effort. Of course I had to think really hard about some af the stuff, but in overall, it was pretty straight forward. But I’ve been programming for 25 years now in anything from assembler to prolog, and I’ve been a full time clojure programmer for almost 2 years now. I should know about lambdas and low level stuff by now. That gives me an edge. It is only easy because of all the other stuff I know about the subject.

That still leaves the question unanswered. Should complexity then be messaured by LOC? That’s at least a objective messaurement and maybe better. If I can express the same algorithm in half the lines of code, it is simpler right?

Here’s the Adler checksum algorithm in C:

const int MOD_ADLER = 65521;
uint32_t adler32(unsigned char *data, int32_t len) 
{
    uint32_t a = 1, b = 0;
    int32_t index;
    for (index = 0; index < len; ++index)
    {
        a = (a + data[index]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }
    return (b << 16) | a;
}

12 lines of code

and here it is in clojure:

(def base 65521)
(defn cumulate [[a b] x]
    (let [a-prim (rem (+ a (bit-and x 255)) base)]
         [a-prim (+ b a-prim)]))
(derive clojure.lang.LazySeq ::collection)
(defmulti checksum class)
(defmethod checksum String [data]
    (checksum  (lazy-seq (.getBytes data))))
(defmethod checksum ::collection [data]
    (let [[a b] (reduce cumulate [1 0] data)]
          (bit-or (bit-shift-left b 16) a)))

11 lines of code

The latter should the be less complex, right?

I’ll leave this one open and hope for a discussion in the comments.

Keep it simple

To sum up the first part of day 1 of GOTO Conference, I must say there’s a pattern in otherwise unrelated talks: simplicity.

“Programming is hard”, says Donald Knuth. It seems that the speakers all agree, we should stop making it even harder. We tend to, says Russell Miles. “We do it out of boredom”. He argues, that if the task at hand is boring, doesn’t inspire us or is simply just to simple, we tend to try and make it interesting, by making it more complicated. “Uh, I always wanted to look into python. Maybe and can solve the task using that”. And – oh – look and behold. Trouble down the road. But Russel also have a suggestion on how to avoid the complexty we tend to introduce our selfes. He call it O.R.E. – or Organize, Reduce and Encapsulate.

He argues that organizing is nothing more than identifying if a part of a module has to know about the outside world or not. If it does, it is integration, if it doesn’t it is core. Database access? Integration. Rest services? Integration. Business rule? Well, if all data is supplied by the integration parts, I guess it’s core.
He also argues, that integrations should be kept at a minimum af knowledge about the other parts to avoid entanglement. Just pass simple data documents and parse whatever you can understand. “Be liberal in what you accept”. By deciding that data should be immutable, he argues that this also helps in reducing complexity. He says, that to his experience, it will end up looking like functional programming and have a reduce complexity and entanglement. I’m already doing functional programming in clojure, so if it is true, that it ends up looking like functional programming, I would say that he is more or less correct in the rest of his arguments.

Simplicity also seems to be the keyword in the next talk with Mathias Meyer about Travis CI, a hosted,continous integration platform. In the talk, he tels the story about how they redesigned the system from a monolithic architecture to a scalable architecture, build from small, distributed parts. But more about that in a later post. Still have some digesting to do.

Glæder mig

Jeg skal til konference i næste uge og jeg glæder mig: 3 dage med de ypperste i min branche. Jeg er endda blevet inviteret, så jeg har VIP-billet med det, som ville svare til backstace-adgang. Det er jeg selvfølgelig ekstra glad for, men det er nu ikke den primære årsag.

De fleste forstår intuitivt, at for at holde sig i form, skal man træne regelmæssigt. Sidder man stille og inaktiv, forfalder kroppen, for den spilder ikke energi på at vedligeholde noget som ikke bliver brugt. Snart bliver hverdagens største udfordring også det maximale man kan præstere.

Sådan er det også med hjernen…

Hvis ikke man træner sin hjerne, giver den nogle udfordringer ud over det sædvanlige, forfalder evnen til at overskue komplekse problemstillinger. Hvis man ikke tager på konferencer eller efteruddanner sig, sidder man reelt og bliver dummere.

Ses vi på GOTO?

On Ticket goto GOTO;

Whoop, whoop. I’m in luck. It seems I have found a sponsor for a ticket for GOTO;!

Now that I dare hoping to attend, I have started to study the details of the program. One of the tracks has a day called “Distributed Systems Renaissance”, and that caught my interest, because distributed systems is a part of my day job.

One talk in particular caught my interest: “The Smallest Distributed System”. In distributed systems, one of the challenges is being robust to systems falling out and comming back online. This could be due to errors like network problems or due to planned downtime. No matter what, the rest of the system should continue to run and when the missing part is back online, it should be able to catch up whith what have happend while being down. Think of cash machines, that can run whithout connection to the bank. It happily hands out money and when it reconnects to the bank, all of the transations are transmitted. This also implies, that the account balance might not reflect how much money you actually have left the account, as some transactions might still be only in the cash machine. But eventually all transactions will be transmitted, so eventually the balance will be correct. This is more or less what eventual consistency is about, and this talk promis to address these issues.

Where I work, we have a produktion system holding about 1.2 million customers. Most of it is build from the ground up, and for the newest and most central parts, we have used things like Clojure and Datomic – and it’s distributed. Though I have been interested in and been building distributed systems for years now, there a still loads of stuff I should and could learn. I’m really hoping this talk can give me some more insight.

But man – when a glance through the program. It’s like a candy store and I’m starving.

Date for GOTO Conference is getting closer

The date for GOTO is getting closer and it’s still not clear if I’m participating or not. I’m still waiting to se if someone will sponser me a ticket or not. If I am going, there are some speakers I will be looking forward to hear.

Dan North:
Dan NorthI have heard him speak on other occasions and I really enjoy listening to his talks. I find them inspirering and I always take something new home with me. Last time it was a Rubriks Cube and a ball pen – you know what I mean.

Dean Wampler:
Last year I was at the Strange Loop conference in St. Louis. When I’m at a conference I try to mingle. So my friend and I ended up eating breakfast with a bunch of guys we didn’t know, exchanging ideas and discussing programming languages. It was only later that day I found out, that one of them had been Dean. He’s such a cool guy, and will definitely try to attend his session.

Jeff Hawkins:
I have a degree in psychology. Nothing to discuss. I will attend.

Kevlin Henney:Kevlin Henney
Kevlin is also one I have heard speak before and he was very inspirering. Though it’s been more than a year since I attended his talk, some of the things he spoke about still pops up from time to time. Can’t wait to hear what he has to say this time.

Dave Thomas:Dave Thomas
Him I met at GOTO Copenhagen a few years ago. Me and a friend had found a quiet corner and apparently he needed a break from all the fuss as well, so he came and sat down with us. We had some good discussion about software design, especially some challanges with a distributed system that my friend and I was involved in at that moment. He is such a nice and interesting guy, so I’m looking forward to hear him talk.

Then of course Ola Bini, Jeff Sutherland and all the other particpants.

I really need this