Why should every developer care about monitoring

Why should every developer care about monitoring

"You can't control what you can't measure" -Tom DeMarco

 

Building a new digital service from scratch has never been easier. There are plenty of libraries, frameworks, platforms and service providers that make it possible to get our ideas into production in a matter of days if we push the envelope. We also have pretty good practices on how to develop software in general, accompanied with tooling and processes to deploy changes to production safely.

However, there is still a significant disconnect between development and operations regardless of all the DevOps buzz. Developers code, configure infrastructure and take care of the deployments. But then, there is the infamous someone who takes care of the operations and monitoring. I call this approach DevOpsBut, which might ring a bell for those familiar with ScrumBut.

 

Production should be every developer's primary concern

The harsh reality is that our code creates value only when it runs in production. Regardless of how well we implement and test our code, none of our development elegance can guarantee that our service runs smoothly in production. There are just too many moving pieces in the puzzle.

From a bookkeeping perspective, we can think of our codebase as a liability, and it can only be considered an asset when it is delivering business impact in production. Therefore having operable software should be every developer’s top concern.

Any non-trivial software system contains essential complexity which is inherent to the domain. There is no way around that. We also tend to be guilty of building some amounts of accidental complexity by our designs regardless of how hard we try to avoid it. With that said, the only way to be in control of such a complex system in production is to measure the key business metrics and have a close eye on them continuously.

 

What could possibly go wrong?

First, our customers can interact with our service in the most peculiar ways, which can lead to unexpected results and errors. Different end user devices, desktop and mobile browsers included, provide many browser quirks. There is no limit to the amount of manual exploratory testing to avoid this.

Second, it is possible that our user interface is too complicated, and our end users cannot get the desired actions done. In this case, everything is fine from a technical perspective - not a single trace of error anywhere, but neither are there any expected business transactions happening. Without business metric based monitoring we are happy while our customers are frustrated. How uncomfortable is that?

Third, software is turtles all the way down. For example, the downstream dependencies can become unavailable, or even worse, start responding slowly. Some parts of our core infrastructure might melt away for whatever reason. In a complex system, a small, innocent-looking anomaly can cause cascading failures, which might not seem interrelated. Due to concurrency, the sequence of events can be non-linear. These are scenarios that are close to impossible to foresee during development.

 

Optimize for Mean Time to Recovery

In general, there are two methods of quality assurance. One approach is to make sure there are no bugs introduced in the first place. We focus our efforts on carefully testing our systems before deploying to production. With this laborious approach, the frequency of bugs found is small. This is all about optimizing the mean time between failures, or MTBF. The goal is to minimize the number of bugs and maximize the time between outages, regardless of the cost.

Another approach is to make sure that whenever an anomaly happens in production, we know it in the very first second and have detailed diagnostic data. With a proper deployment pipeline in place, we can fix the problem quickly, and the impact of this failure is small in both scale and time. Such thinking optimizes the process for mean time to recovery, or MTTR. Bug count is not the primary concern. Instead, we make sure that we are aware of any exceptions within the first second and can fix them promptly.

My question now is that would you rather live with the illusion of having perfect codebase surrounded by an ideal environment, or having state of the art tools in place to inform you when the unexpected happens in production? To be the first one to know of any issues. Or in contrast to have customers report them. Which one of these approaches make you sleep better during nights? Since resources are limited and software is complex, I would try to minimize the mean time to recovery over maximizing mean time between failures.
 

 

It is time to start measuring outcomes

Monitoring merely technical data is better than nothing, but it will only get us halfway there. The next step is to start monitoring KPI’s in real time. For an online web store, this can be the amount of logged in users, signups, shopping cart checkouts or payments. When we have collected the baseline figures for these transactions, we can setup alerts which are triggered on unexpected drops or peaks in our service metrics. Now we know when our service is healthy from the business perspective as well.

By monitoring business transactions, we can start to measure the impact of our releases. It can be an incredible game changer in the way we develop software. Instead of focusing on output and features such as “customer can sign up using social login”, we can start to measure outcomes like “we get more customers signing up for our service.” Now we can optimize development efforts on business goals using data. It is a fundamentally different approach compared to prioritizing work based on the highest paid person’s opinion.

 

Towards Operations-Driven Development

Getting proper monitoring in place is a bit similar to a well-crafted test suite or application security. It is not easy to wire these on top of the application later. Things like elementary server monitoring and health checks are easier to achieve compared to going all the way with an MTTR-optimized development process.

Should developers focus on monitoring and stop writing automated tests? Of course not, that would be insane. There are numerous reasons for having a test suite in place. Tests are our safety net. They allow us to develop features faster, enforce modular design, and help in documenting system behavior.


Monitoring is our safety net in the most critical environment: production. Therefore, all developers should ensure that their applications are robust from an operations perspective as well. All we need is to add a bit of "operations-driven development" mentality to our daily development routines. But then how do we take care of all this in practice? Well, that is another story and another blog post.

Työmatkakoodaus - harrasteprojektien pelastus

Työmatkakoodaus - harrasteprojektien pelastus

"Jokela? Hetkinen, missäs se sijaitseekaan?" Tämä on tyypillinen kysymys, kun kerron työkavereilleni käyväni töissä hiukan kauempaa. Täytyy kestää iäisyys tulla moisesta perähikiästä Helsinkiin, ja vielä joka arkipäivä! Sepä se, mutta nyt kerronkin, miksi se on hieno asia.


Tiedämme kaikki, että pienemmällä prioriteetilla olevat projektit tuppaavat alkuinnostuksen jälkeen jäämään yhä harvenevien koodauskertojen vuoksi taka-alalle. Kun koodiin ei koske, se alkaa viiletä, ja uudelleen paneutuminen vaatiikin jo lyhkäisen mikrolämmityksen. Tämän vuoksi projekti alkaa yhä kylmetä, ja pian se siirtyykin jääkaappiin, pakastimeen, ja lopuksi ikiroutaan, josta ei lämminsydämisinkään koodari sitä enää sulata.


Ainoa oikea jäänestoaine on usein toistuva, säännöllinen naputtelu. Ja mikä olisikaan tähän prosessiin parempi implementaatio kuin joka arkipäivä kahdesti toistuva työmatkakoodaus!


Palataanpa reilu vuosi taaksepäin. Asuin tuolloin Helsingissä ja kävin töissä Helsingissä. Työmatka oli ajallisesti vain hiukan lyhempi kuin nykyään, mutta muuten toivoton: vaihtoja junasta metroon ja metrosta bussiin. Podcastit olivat ainoa pelastus, mutta ei Sarasvuon monologejakaan jaksa liian montaa kuunnella. Mikä tilanne on nyt susirajan takana asuessani? Kahden minuutin pyöräily asemalle, 37 minuuttia tiukkaa koodia tasaisessa junakyydissä, ja pari minuuttia kävelyä työpaikalle.


Matka menee kuin siivillä: hetkisen naputtelun jälkeen joudun jo harmittelemaan kun juna tulee perille ja kiinnostava koodinpyöritys jää kesken. Mutta ei huolta, seuraava työmatka koittaa pian! Jos juna myöhästelee, kuulen ympäriltäni tuskastuneita huokailuja, mutta itse myhäilen tyytyväisenä, saanhan ehkä featuren valmiiksi sittenkin jo tällä matkalla! Kun saavun varsinaiselle työpaikalleni, aivoni on jo lämmitelty ohjelmointivaihteelle, ja Gitin kolkuttelu voikin alkaa saman tien.


Voisi kuvitella, että junamatkasta tuhraantuu arvokkaita minuutteja kaikenlaiseen virittelyyn matkan alkaessa ja päättyessä. Mitä vielä! Kun tulen junaan, valitsen sen tutun optimaalisen ikkunapaikan, avaan koneen kannen, painan kännykästä hotspotin päälle ikkunalaudalle, ja IDE:ä ei edes tarvitse laittaa tulille - koodi odottaa heti kutsuvana nenäni edessä samassa kohtaa johon viimeksi jäin. Kun juna nytkähtää liikkeelle, on koodiviidakossa jo täysi kuhina päällä. Tasan 37 minuuttia myöhemmin kuuluu naps, kun sorvin kansi kolahtaa kiinni ja kävelen miltei odottamatta junan ovista ulos kohti rämää polkupyörääni.


Kun junassa välillä nostan katseeni kinkkisen bugin alhosta ja vilkaisen ulkomaailmaan, huomaan että kanssamatkustajanikaan tyhjän panttina ole. Lähes kaikilla on kätösissään kiiltävät älypuhelimet, joista luetaan, kuinka fasetuttu on päättänyt tiukan habatreenin ja on nyt suihkunraikkaana, tai kuinka "BB-Kimmon kääpiösnautserin ulkoilutus päättyi yllättävästi - lue lisää". No, toki näilläkin on paikkansa, ja muitakin vaihtoehtoja on. Enkä sano, että kytyiset harrastetunkkaukset olisivat arvokkaampia kuin edellä mainitut, mutta ylipäänsä jokin tavoitteellinen tekeminen saattaa olla kymmentä sekuntia pidemmällä tähtäimellä palkitsevampaa.


Jos työmatkani olisi vaikka vain viisi minuuttia, enkö voisi naputella samat koodit kotona? No, katsopa peiliin ja kysy käsi sydämellä, tulisiko tehtyä joka päivä. Vastaus: Ei. Vaihtoehtoisia askareita tulisi kummasti mieleen pitkä lista. Taitaisi olla aika epätoivoista myös yrittää kertoa puolisolle kotona, että "Koodasin juuri kahdeksan tuntia töissä, ja jatkan vielä tässä kotona puoli tuntia, hoidatko lasta".


Mielestäni eräs työmatkakoodauksen merkittävimmistä hyödyistä on se, kuinka alitajunnan saa valjastettua ongelmanratkaisuun. Kun kohtaat menomatkalla hankalan pähkinän, voit hetken miettimisen jälkeen siirtyä eri tehtävään, ja jättää ongelman ratkomisen alitajunnalle. Voi hyvinkin olla, että paluumatkalla ratkaisu on kirkkaana mielessä, tai viimeistään aamulla, aivojen raksutettua unessa töitä. Tällaisia etuja ei saisi, jos tekemisen ajoittaisi yhdeksi viikottaiseksi köntäksi. Kun lyhyet pätkät toistuvat usein, projektin tilanne ja koodi pysyy hyvin muistissa. Siihen on helppo palata.


Aivan kuin jokikin koostuu pienistä puroista, softakin koostuu koodinpätkistä. Kun päivät, viikot, kuukaudet kuluvat, huomaat yhtäkkiä katselevasi junakoodista kehrättyä, eksoottista softailmentymää. Commit-historia on pitkä kuin Tokmannin ämpärijono ja todistaa pitkäjänteisestä työstä, joka on kertynyt kuin huomaamatta.


Tänä syksynä olen paria poikkeusta lukuunottamatta koodannut joka ikisen työmatkan. Ainakin tähänastiseen työmatkakoodaukseeni olen kovin tyytyväinen; olen saanut edistettyä monia projekteja, pienoisena esimerkkinä eräs Wunderdogin koodauspähkinöistä. Jos koodausideat loppuvat, voin ottaa työn alle jotakin muuta pitkäjänteistä, vaikkapa Dostojevskin tuotannon. Vältynpähän ainakin päämäärättömältä kännykän näperrykseltä, jota jo muuten harrastan aivan riittävästi. Siispä: muuta sinäkin kauemmas!


P.S. Uusin Wunderpähkinä on julkaistu hiljattain! Olisiko sen ratkominen ensimmäinen #työmatkakoodaus sinulle? 

Uusia Rekkuja hakusessa

Uusia Rekkuja hakusessa

Hei, etsimme laumamme vahvistukseksi kehittäjää, joka on ylpeä työnsä jäljestä ja lopputuloksesta.

 

Lupaamme, että Wunderdogilla tulet kehittymään niin ohjelmoijana kuin ihmisenä. Olemme omalla porukalla rakentaneet yrityksellemme kulttuurilupauksen, johon kiteytyy arvomme. Annamme tilaa erilaisille persoonille ja työtavoille sekä kannustamme kokeilemaan asioita rohkeasti ja ennakkoluulottomasti.

Projektit tehdään usein asiakkaan tiloissa, mutta meille ehdottoman tärkeää on yhteenkuuluvuus. Siksi työskentelemme joka perjantai omalla toimistollamme. Jaamme yrityksen tiedot avoimesti koko porukalle ja vastuuta meillä jaetaan kaikille. Mietimme yrityksen kehityssuuntaa koko porukan voimin ja haluamme luoda firmastamme paikan, johon on aina siistiä tulla.

Käytämme Wunderdogilla moderneimpia teknologioita ja kokeilemme ratkaisuissa uusia työkaluja. Tänä vuonna meillä on startannut useampi React ja React Native –projekti ja myyntitykkimme haalivat näitä kokoajan lisää. Funktionaaliset kielet ovat suosiossamme. Yleisimpiä käytettyjä kieliä projekteissa ovat JavaScript, Java, Scala ja Clojure. Projekteja meiltä löytyy isoista kansainvälisistä pelureista kotimaisiin start-uppeihin. Haluamme olla mukana luomassa digitaalisten innovaatioiden avulla parempaa maailmaa. Meillä pääset myös itse vaikuttamaan siihen, missä projekteissa pääset itse parhaiten loistamaan.

Oletko sinä uusi Ihmekoira? Tule juttelemaan kanssamme lisää.

Lähetä CV ja hakemuksesi 31.1.2017 mennessä osoitteeseen [email protected].

Katso myös muut avoimet paikkamme tai lähetä avoin hakemus osoitteeseen [email protected]

 

 

Koodia ja kokista

Koodia ja kokista

Laumallinen Rekkuja otti ilolla vastaan yhdeksäsluokkalaisen Johanneksen tutustumaan softatalossa työskentelyyn. Kahden viikon aikana Johannes opetteli koodaamaan, syömään sushia ja taisi hän myös saada pienen palon devaajan duuniin. Tältä harjoittelu Johanneksesta tuntui: 

“Olen yhdeksäsluokkalainen, tulen Ylä-Malmin peruskoulusta ja olen TET:ssä Wunderdogilla.

Päädyin Wunderdog Oy:lle TET-harjotteluun siten, että menimme koulun kanssa tutustumaan Reaktor -nimiseen firmaan. IT-ala vaikutti kiinnostavalta ja aloin kyselemään TET-paikkoja, ja Wunderilta aukeni harjoittelupaikka.

Kun tulin Wunderin toimistoon TET-haastatteluun, laitoin merkille että toimisto on kotoisan näköinen.  Pistin merkille myös, että ilmapiiri on hyvä, työntekijät ovat ystävällisiä ja tietävät mitä tekevät. Sain kahvia, mikä on aina plussaa.

Ensimmäisenä päivänä minulle esiteltiin toimiston alueet ja tutustuin heidän tekemäänsä ohjelmaan. Sain myös työläppärin kahdeksi viikoksi. Etsin ohjelmasta bugeja ruoka-aikaan asti. Kävimme ruokailemassa alakerrassa olevassa Tamarin -nimisessä ravintolassa, jonka jälkeen opettelin vähän koodausta codecademy sivustolla.

TET-päivinäni olen saanut opetusta Python -ohjelmointikielestä. Olen myös seurannut vierestä työn tekemistä. Olen oppinut myös syömään sushia ja falafelia. Huomasin myös, ettei täällä olla kovin aamuvirkkuja, sillä tulin yhtenä aamuna ensimmäisenä töihin ja laukaisin vahingossa hälytysjärjestelmän.

Koodarin, eli ohjelmoijan työ on erilaisempaa kuin luulin. Tämä työ on rentoa ja lähes päivittäin pääsee oppimaan uutta.  Luulisin, että jos koodariksi haluaa, pitää oppia suorittamaan pulmia ja olla kiinnostusta työtä kohtaan. Tekisin mielelläni isona tämänlaista työtä.

Täällä Wunderilla on ollut erittäin mukavaa ja syötävääkin löytyy, paras limppari oli ehkä kokis. Mukavinta on se, että työntekijät ovat huumorintajuisia ja heittävät hyvää läppää.

Suosittelen IT-alaa Wunderilta saadun kokemuksen mukaan.”

Johannes