2015. Tak for lort

(Bibi er i dag blevet indlagt. Igen.)

Advertisements

Nye græsmarker

Jeg har fået nyt job. Det lyder uvirkeligt for mig, når jeg siger det, men det har jeg altså. I mange år har jeg lavet software i telebranchen, hvilket har været spændende, men min oprindelige specialisering fra universitetet lå et andet sted: Maskinindlæring. Ja, jeg bruger et dansk ord for Machine Learning; jeg kan godt lide danske ord. Nå, men jeg har altså været heldig og fik tilbudt et job i en virksomhed, hvor jeg skal arbejde med netop maskinindlæring.

I virksomheden modtager vi enorme mængder at data, som vi laver analyser på. Big Data, som det jo populært hedder. Når virksomheden siger Big Data, er det ikke blot et buzzword, for der er tale om virkelig store mængder af data. Det jeg hørte var, at de har i omegnen af 100 maskiner, som ikke laver andet, end at modtage og forbehandle data. En af kunderne er Google. Det de gerne vil nu, er at finde yderligere information i en data, end de de allerede kan grave ud af den, med almindelige statistiske metoder. Det er her maskinindlæring, og derved jeg, kommer ind i billedet. Det kommer der et blogindlæg ud af snart, men først lidt om årets goto.

I de sidste par år, har min fokus mest ligget på funktionelle sprog og jeg har blandt andet været på rene clojurekonferencer. I september tager jeg på årets goto i Aarhus, og jeg har tænkt mig at prioritere det spor, der omhandler “Enterprise Architectures”. Årsagen er, at sporet blandt andet berører Big Data og at Mr. Scala, Dean Wampler kommer og taler om Spark, som er en af de teknologier jeg arbejder med nu.

Desværre ser den nye form ikke ud til at passe helt til mine interesser, for det ser ud til, at de mest spændende ting kommer til at foregå samtidig, bare i forskellige spor. Det er ærgrer mig en del, men til gengæld glæder jeg mig til at mødes med mine kollegaer i branchen, hvoraf en del af dem betragtes som venner, efter vi har mødtes så mange gange på konferencer, opgaver og arrangementer i andre sammenhænge.

Bør man rette i allerede publicerede tekster?

Jeg er begyndt at blogge andet steds, nærmere bestemt på qed.dk. Her postede jeg forleden et indlæg, som jeg egentlig ikke var helt tilfreds med, men heller ikke ønskede, at pille i for længe.

Nu har jeg modtaget den første kritik af det, og det meste rammer lige i skabet. Kritikken var ca mine egne forbehold, men nu kom det nødvendige perspektiv der gør, at jeg ved hvad jeg skulle have skrevet i stedet. Nu kommer tvivlen:

Er det i orden at rette – som at omskrive et helt afsnit – når først indlægget er publiceret?

Umiddelbart tænker jeg, at det er ok. Det er jo et online medie, og en af de muligheder der ligger i dette, er jo netop at opdatere sine tekster, efterhånden som man bliver klogere.

Tanker modtages gerne

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.