Tylsät teknologiavalinnat ovat kestävimpiä
Otathan huomioon, että tämä artikkeli on yli 6 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Helsingin kaupunki kokeilee kuinka hyvä ohjelmistofirma se on - ja lopputulos on kamalaa katsottavaa.
Valun Mikko Virenius kirjoitti viime vuoden puolella teknologiavalinnoista raflaavalla otsikolla ”Sori kehittäjä, kukaan ei ole kiinnostunut hipsteriteknologiastasi”.
Mikko viittaa jutussaan monen ohjelmistokehittäjän ihmettelyyn siitä miksi asiakkaat eivät aina osaa arvostaa uusimpia mikroarkkitehtuuriehdotuksia tai koko palvelun toteutusta yhden sivun web-sovelluksena Reactilla. Monen kehittäjän mielestä nämä olisivat paljon modernimpia malleja kuin jonkun kankean WordPressin taivuttelu palvelun alustaksi.
Kieltämättä tämä on varsin yleinen ilmiö, mutta en ole aivan samaa mieltä siitä etteivätkö kehittäjien ehdotukset pääsisi esiin toimistojen tarjonnassa. Väitän jopa, että tällä hetkellä nimenomaan monet toimittajat tarjoavat asiakkailleen uusimpia ja tuoreimpia teknologioita ja lähestymistapoja vaikka asiakkaiden kannalta kestävämpi vaihtoehto olisi rakentaa palvelu jonkun vakiintuneemman teknologia-alustan, kuten WordPressin, päälle.
Moni toimisto sekä yksittäinen kehittäjä todellakin luulee, että ”meillä on modernein stäkki” on hyvä myyntilause.
Käytännössähän tällainen väite puree lähinnä startup-maailmassa, tai jos pöydän toisella puolella on päättävässä asemassa kehittäjiä. Sellainen on kuitenkin aika harvinaista. Yleensä asiakkaiden puolella olevat kehittäjät tuppaavat myös olemaan aika kokeneita kehittäjiä, jotka ovat jo yleensä nähneet mitä voi seurata siitä kun tekee asioita aivan uusimmilla teknologioilla.
Erittäin kokemattomiin ostajiin uutuuden korostaminen voi tietysti myös toimia joskus, koska kieltämättä joskus asiakkaiden puolella on harhakäsityksiä siitä että uusimpaan teknologiaan investoiminen jotenkin automaattisesti takaisi pisimmän elinkaaren.
Käytännössähän IT-alalla teknologioita syntyy ja kuolee koko ajan valtavasti, ja vain hyvin pieni osa teknologioista pääsee laajaan käyttöön ja onnistuu kehittymään useiden vuosien ajan eteenpäin. Esimerkiksi viime vuosina kuumista Javascript-frameworkeista merkittävä osa on jo lähes kuollut, tai vähintään hylätty hitaaseen saattohoitoon, kun suurin osa kehittäjistä on hypännyt trendikkäämpiin vaihtoehtoihin.
Asiakkaiden kannalta tällainen tilanne on aivan katastrofaalinen suorastaan, koska tilanne voi pakottaa koodaamaan sovelluksia täysin uusiksi muutaman vuoden välein. Toimistoille muutaman vuoden välein tapahtuva täydellinen uudelleenkoodaus on tietysti vain mehukasta liiketoimintaa.
Viitatuilla Javascript-frameworkeillakin on tehty tässä maassa todella paljon verkkopalveluita ja erilaisia web-sovelluksia, ja moni näiden omistajista on nyt vaikeuksissa, kun valtava Angularilla tehty sovellus ei olekaan enää niin helposti jatkokehitettävä, ja kaikki ohjelmistokehittäjät haluaisivat tehdä töitä jollain uudemmalla frameworkilla.
Vakiintuneet ekosysteemit takaavat jatkuvuutta
Virenius korostaa jutussaan avoimen lähdekoodin etuja jatkuvuuden näkökulmasta, jotka ovatkin ihan todellisia. Isot ekosysteemit eivät synny nopeasti, eivätkä murru nopeasti, joten asiakkaiden kannalta isojen ekosysteemien teknologiat ovat ennustettavia, etenkin jos ne pohjautuvat avoimeen lähdekoodiin.
Tosin kaupallisellakin puolella on valtavasti esimerkkejä teknologioista, joiden ympärille on muodostunut laaja ekosysteemi, joka jo olemassaolollaan varmistaa teknologian jatkuvuutta. Yleensä kyse onkin enemmän juuri ekosysteemin laajuudesta ja kypsyydestä, ei niinkään siitä että onko kyse avoimesta lähdekoodista vai suljetusta koodista.
Olisi esimerkiksi hyvin vaikea väittää, että jonkun Salesforcen ekosysteemi olisi jotenkin olennaisesti heikompi tai riskialttiimpi tulevaisuuden suhteen kuin WordPressin. Etenkin kun isoilla teknologiataloilla on ihan samantyyppisiä lisäosamarkkinoita ja kumppaniverkostoja ympärillään kuin mitä suosituimmilla avoimen koodin järjestelmillä.
Uusien teknologioiden käyttöön pitää olla selkeät syyt
Toki on paljon tilanteita, joissa uudet teknologiat tarjoavat jotain selkeästi uutta ja parempaa. Yleensähän uudet teknologiat syntyvät juuri tilanteissa, joissa jokin kehittäjäjoukko on havainnut aiemman teknologian riittämättömyyden ja lähtenyt miettimään parempaa ratkaisumallia. Täten kaikki uudet teknologiat ovat aina varmaan jossain määrin parempia kuin ne teknologiat joita kyseiset kehittäjät käyttivät aiemmin.
Esimerkiksi mikroarkkitehtuurit ovat syntyneet vastauksena isojen, monoliittisten räätälijärjestelmien jatkokehityksen ongelmiin, mutta ei mikroarkkitehtuurienkaan ajatus ole vailla omia haasteitaan, eikä sellainen ajattelu sovi kaikkiin tilanteisiin. Joku React on taas syntynyt Facebookin tuotekehityksen toimesta vastauksena Facebook-sovelluksen hyvin reaaliaikaisten päivitysten tarpeeseen. Kummassakin tapauksessa on kysymys mallista, joka ratkaisee lopulta melko spesifin ongelman, ja sellaisesta on vielä pitkä matka teknologia-alustaan joka ratkaisi tehokkaasti monia erilaisia ongelmia.
Eivätkä uudet teknologiat aina edes onnistu ratkaisemaan spesifejäkään ongelmia tehokkaasti. Kukaan kehittäjä ei tunne koko maailman teknologiakenttää, harvoin edes oman ekosysteeminsä kaikkia eri vaihtoehtoja. Täten monet uudet teknologiat ratkaisevat ongelmia, jotka on jo ratkaistu aiemmin jossain toisaalla.
Ja vaikka uusi teknologia ratkaisisikin jonkun tunnetun haasteen selkeästi paremmin kuin aiemmat teknologiat, niin yleensä siitä puuttuu vielä paljon kyvykkyyksiä, jotka on aiempiin ratkaisuihin vuosien varrella kehitetty.
Asiakkaiden kannalta tämä tarkoittaa sitä, että vaikka uusi teknologia olisikin ratkaisu siihen yhteen polttavaan ongelmaan (esim. suorituskyky, muokattavuus, paremmat kehitysprosessit, tjms), niin usein vaihdon myötä saadaan joukko uusia ongelmia jotka oli jo ratkaistu aiemmassa ympäristössä.
Asiakkaiden kannattaisikin haastaa vahvemmin toimistojen ehdottamien teknologioiden perustelut, koska läheskään aina toimistojen teknologiavalintaprosessit eivät ole perustuneet kovin laajoihin, tai edes loogisiin, arviointiprosesseihin. Usein toimistot vaihtavat teknologioita, koska riittävän moni kehittäjä (tai se yksi äänekäs) haluaisi kokeilla uusia juttuja.
Tylsä ja toimiva teknologia voi olla myyjälle huonoa bisnestä
Toimittajien etuna voi myös joskus olla myydä uusia teknologioita, koska niiden avulla palveluiden pystyttäminen tuottaa heille enemmän työtä. Laajat ja pitkälle tuotteistetut alustat voivat olla toimittajien kannalta jopa ongelmallisia, kun kehittäjät eivät ”tykkää” niiden kanssa toimimisesta, ja projektitkaan eivät välttämättä ole erityisen rahakkaita, kun alusta tarjoaa niin paljon valmiina.
IT-alan haastava rekrytointitilanne myös korostaa tätä ilmiötä, kun toimistojen täytyy mainostaa itseään kehittäjille paikkoina, joissa pääsee tekemään töitä kuumimmilla teknologioilla.
Täysin uusiin asioihin voi yleensä soveltaa myös uusimpia tekniikoita
Startup-maailmassa tätä temppua on käytetty jo pitkään. Kun tyypillinen startup tekee kuitenkin jotain aivan uutta ja ihmeellistä, ja todennäköisesti vaihtaa suuntaa vuoden päästä, niin valitun teknologiastäkin jatkuvuudella ei ole kovin paljon arvoa. Siksi tätä tilannetta kannattaa käyttää rekrytoinnissa, ja mainostaa itseään paikkana, jossa kehittäjät pääsevät koko ajan tutkimaan uusia teknologioita ja valitsemaan itsenäisesti käyttämänsä frameworkit ja muut systeemit.
Pitkäkestoista liiketoimintaa tekeville, jo vakiintuneille, firmoille tällainen teknologiaseikkailu ei kuitenkaan ole millään tavalla järkevää. Pystytettäviä palveluita ei aiota koodata uusiksi vuoden päästä, vaan palveluiden halutaan toimivan vuosien ajan ja järkevillä ylläpitokustannuksilla.
Mitä isompi investointi, sitä enemmän kannattaa pyrkiä kestäviin valintoihin
Asiakkaiden näkökulmasta tylsät ja kestävät teknologiat ovat yleensä sitä tärkeämpiä mitä isommasta ja pitkäkestoisemmasta investoinnista on kysymys. Riippuen kohteesta, tämä ei aina tietysti ole mahdollista, joten automaationa tätä ei saisi pitää, mutta pyrkimyksenä se on järkevä.
Uusimpien ”hipsteriteknologioiden” tunteminen on toki järkevää, kuten Vireniuskin viitatussa jutussa toteaa, mutta niiden puskeminen asiakkaille myös pitkäkestoisten palveluiden alustoiksi on edesvastuutonta toimintaa.
Alan toimistoilla ja kehittäjillä on omat lehmänsä ojassa tässä toiminnassa, ja siksi asiakkaiden kannattaisikin ottaa enemmän vastuuta teknologiavalinnoista, silloin kun palveluiden toivotaan kestävän enemmän kuin seuraavat pari vuotta.
Lue lisää: Löydä kokenut digitoimisto – Helsinki, Tampere, Turku, Oulu, Jyväskylä
—
PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä monet muut teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
6 kommenttia on “Tylsät teknologiavalinnat ovat kestävimpiä”
Kommentointi on suljettu.
Jani Tarvainen
Mitä ihmettä? Nyt heti kvanttikoneet alle ja SpedeScriptillä* kotisivut!
* https://janit.iki.fi/spedescript/
Joonas Nissi
Hyvää pohdintaa, olen itse miettinyt www-ammattilaisena parin vuoden freenä työskentelyn jälkeen säännölliseen päiväduuniin takaisin pyrkivän näkökulmasta samoja juttuja. Törmäsin just pari päivää sitten tällaiseen artikkeliin frankchimero.com/writing/everything-easy-is-hard-again/, jossa brooklynilainen suunnittelija Frank Chimero miettii esim seuraavaa: ”I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times. If you’ve been working in the technology industry a while, please tell me this sounds familiar to you.”
H. Veikkonen
Yksi selkeä syy, joka unohtuu helposti, että innostunut devaaja saa aikaan enemmän. Motivaation puute heikentää lopputulosta dramaattisesti. Ainainen margariinin pakkaaminen ei ole haastavaa eikä kehittävää, joten se on harvoin motivoivaa. Markkinoilta ei välttämättä löydy ihmisiä, joita vanhan teknologian tekeminen kiinnostaa laisinkaan.
Tuottavuus on parantunut viime aikoina aivan huikeasti uusien teknologioiden myötä. Pitää käyttää päätä valitessaan niistä oikeat – aivan kuten jokaisessa asiassa.
Perttu Tolvanen
Kiitos kommentista, ja tuo on varmasti ihan keskeinen syy mitä monet firmat ajattelevat, kun antavat koodareille paljon valtaa vaikuttaa teknologiavalintoihin.
Minusta tuota ”tuottavuus on parantunut” -argumenttia kuitenkin viskotaan hyvin kevyin perustein tällä alalla. Voiko joku oikeasti väittää, että Javascript-frameworkit vaikka ovat merkittävästi lisänneet tuottavuutta jonkun verkkokaupan fronttikerroksen toteutukseen verrattuna jonkun tuotepohjaisen ratkaisun käyttöön? Enemmänkin löytyy esimerkkejä siitä, että frontti on maksanut moninkertaisesti, vanhentuu nopeasti ja on sidoksissa sen koodaritiimin tekemiin ratkaisuihin. Ja hyödyt käyttäjän kannalta? Latautuu hitaammin? :)
Noh, kärjistyksiä, mutta kyllähän se nyt on merkki markkinan ylikuumentumisesta jos tekijät pystyvät nyrpistämään nokkaansa muutaman vuoden takaisille teknologioille vain sen takia kun ”ei motivoi”.
Paremman motivaation tavoittelu on hyvä asia, mutta ei sen ehdoilla saisi uhrata asiakkaan näkökulmaa.
Timo Laak
Tämä blogipostaus on selkeästi tavallaan jatkumoa sille parin vuoden takaiselle kritiikille räätälikoodareita kohtaan ja ketterien softatalojen tavalle olla tunnustamatta väriä, eli toisin sanoen pyrkimykselle välttää leimautumista Drupal tai WordPress-taloksi.
Olen 10+ vuoden urallani tehnyt melkein kaikkea laidasta laitaan. Ihan simppeleitä HTML-pohjaisia sivuja, CMS-vetoisia melko tavanomaisia saitteja, CMS-vetoisia haastavampia kokonaisuuksia, PHP-tunkkeja ja jQuery-spagettia, NodeJS-pohjaisia himmeleitä, staattisia sivustoja pilvi-CMS:n päälle, React-sovelluksia, Angular 1 ja Angular 2+ sovelluksia, Vue.js -sovelluksia ja siinä sivussa myös ihan designia, niin koen tietäväni aiheesta tarpeeksi, että voin avautua aiheesta.
Hyvin yksinkertaistettuna kyse on siitä, että pyöreään reikään sopii pyöreä palikka ja neliskanttiseen reikään sopii neliskanttinen palikka. Yksi haluaa hakata palikat sisään kumivasaralla, kun toinen taas ottaa mielellään jonkun järeämmän työkalun. Saattaa joukossa olla jopa joku joka vuolee puukolla palikat sopivan kokoisiksi.
Eli siis valitaan oikeaan hommaan oikea työkalu. Joskus se oikea työkalu on WordPress, joskus se on React, joskus se voi olla vaikkapa Haskell.
Mielestäni WordPress on oikein hyvä valinta tavanomaisen sivuston toteuttamiseksi. Se ei vaadi kamalasti kustomointia, teemojen tekeminen ei ole liian monimutkaista ja se on jo oikea CMS eikä pelkkä blogialusta. Osaajia löytyy joka nurkalta ja hostauskin hoituu missä tahansa viiden markan webbihotellissa.
WordPress voi olla hyvä valinta myös ihan pelkkänä tietovarastona, jolloin se toimii ikään kuin pilvi-CMS:nä ja varsinainen UI-kerros on sitten toteutettu jollain muulla teknologialla.
WordPress ei kuitenkaan ole soveltuva alusta vaikkapa rahalaitoksen maksuliikenteen ja valuutanvaihdon sovelluksen toteuttamiseksi. Siinä tarvitaan reaktiivisuutta, tilanhallintaa ja muita edistyksellisempiä UI-kerroksen toiminallisuuksia, joita ei pysty tekemään mielekkäästi responsiivisena cross-platform toteutuksena kovin hyvin muilla kuin modernilla JS-frameworkilla. Kun UI-kerros tehdään näillä, niin WordPressit ja muut CMS:t ovat vain tiellä.
Offline first, progressive web apps ja muut modernien web-pohjaisten applikaatioiden vaatimukset vain ovat sen verran korkealla, ettei niitä nyt vain ole järkevää tehdä julkkareilla.
Ala kehittyy niin isoin harppauksin, että ne Pertun mainitsemat vanhat ja solidit työkalut ei vaan pysy mukana.
Voi olla myös asiakkaan näkökulmasta suosiollista jakaa sitä webbisovellusta tai saittia erillisiin kokonaisuuksiin. Tuhansien blogipostausten, rekryilmoitusten ja muun staattisen sisällön kokonaisuuden voi tehdä julkkarillakin, mutta joskus se homma vaan toimii paremmin, kun siellä on SaaS-ratkaisut taustalla ja frontti on ihan täysin kustomina tehty staattinen saitti. Ajastetut buildit, ei tietokantaa, vain staattisia tiedostoja. Ei tarvetta cachelle. Se saitti vaan toimii kuin junan vessa. Uuden layoutin tekeminen on paljon helpompaa, kun data tulee rajapinnoista, eikä UI-kerrosta ole pultattu kiinni minkään CMS:n presentaatiologiikkaan.
Joskus julkkarit vaatii jos jonkinlaista pluginia ja vimpainta sen saitin rakentamiseksi ja rajapinnat deprekoituu aikanaan jolloin päivitysmahdollisuudet kapenee. Siinä sitten ollaan vanhassa versiossa kiinni kun päivitys ei onnistu ja kukaan ei halua siihen spagettikoodiin enää koskea. Tehdäkö kokonaan uusi kallis vuosien mittainen projekti? Joskus siihen ei ole tarvetta, kun julkkarin voi jättää tietovarastoksi ja rakentaa React-himmelin siihen päälle UI-kerrokseksi.
Angular 1 muuten on jo melko iäkäs ja edelleen aktiivisesti käytössä. Päivityksiäkin siihen tulee edelleen. Vaikka upgrade-polkua tuoreempiin versioihin ei olekaan, on sillä silti tehty ja tehdään edelleen sovelluksia maailmalla vaikka kuinka paljon.
React ei ole varsinaisesti JS-framework samalla tavalla kuin esim. Ember tai Angular 1 (Angular 2 on TypeScript framework), vaan se on pelkkä UI-kerros, jossa on lifecycle-metodit ja alkeellinen tilanhallinta. Muut tarvittavat osat siihen projektiin pitää pultata itse kiinni, jolloin valinnanvapautta on paljon.
React on ehkä syntynyt Facebookin notifikaatioiden tarpeisiin, mutta ei se tarkoita sitä etteikö se voisi olla soveltuva moneen muuhunkin asiaan. Ihan samoin WordPressikään ei ole enää vain pelkkä blogialusta.
JavaScript on Reactissa ensimmäisen luokan kansalainen, jolloin itse asiassa koodataan projektia JavaScriptillä, eikä niinkään Reactilla. Tällöin teoriassa se riippuvuus siitä Reactista itsestään on teoriassa pienempää ja frameworkin vaihto johonkin muuhun voi onnistua huomattavasti helpommin. Ei ammattilaiset tänä päivänä koodaa JavaScriptiä kuin jQueryä 10 vuotta sitten, vaan siellä tehdään ihan oikeasti modulaarista, reaktiivista ja funktionaalista koodia, jossa tilanhallinta, luettavuus, ylläpidettävyys ja skaalautuvuus on tärkeitä asioita.
Kun tehdään koodia kunnolla, pitkäjänteisesti ja myös sitä seuraavaa devaustiimiä ajatellen niin saadaan varmasti monivuotisen elämänkaaren takaavaa laatua. Ei se aina pelkästä teknologiasta ole kiinni. WordPressillä, Drupalilla, Reactilla, Episerverillä ja millä tahansa alustalla saa aikaseksi kamalaa paskaa jos softakehityksen kulmakivet ei ole kunnossa ja tiimillä ammattitaito hanskassa.
Mun mielestä niillä paljon parjatuilla hipsteridevaajillakin on ensisijaisesti tarve ratkaista asiakkaan ongelma parhaalla mahdollisella tavalla. Ei siellä Futuricen myyntimiehet ainakaan ole sanomassa että hei nyt tehdään tuolla Reactilla kun voidaan maksimoida laskutus, vaan se on devaustiimin ja asiakkaan yhdessä käymien keskusteluiden ja harkinnan tulos. Siinä devaustiimissä voi toisinaan olla tekijöitä monesta eri firmasta. Joskus asiakkaan edun mukaista on valita sinne vaikkapa se WordPress, mutta jotkut firmat tarvitsee etupäässä sovelluksia ja digitaalisen ajan työkaluja, ei saitteja, jolloin CMS-toteutuksille saattaa olla vähemmän käyttöä. Jos ne haluaa CMS-saitin tavallisena projektina, niin ehkä ne sitten haluaa kontaktoida niitä WordPress- ja Drupal-taloja ja pyytää North Patrolilta vanhanaikaisen vaatimusmäärittelyn.
Perttu Tolvanen
Kiitos kommentista, Timo. En mä ole sun kanssa eri mieltä noista asioista. Mä luultavasti näen vain paljon enemmän niitä tilanteita kun asiat ei mene kuten Strömsössä (ammattistani johtuen), ja nimenomaan räätälisoftan kehityksen saralla tällä hetkellä tehdään mun näkökulmasta katsottuna valitettavan usein asioita joilla ei välttämättä ole kovin hyvä elinkaari tai joita ei välttämättä muistella kovin lämpimästi tulevina vuosina.
Ja ilman muuta se johtuu siitä, että alue on uudempi kuin vaikkapa WordPress-markkina ja Drupal-markkina. Tehtiinhän niilläkin alkuvaiheessa paljon asioita joita ei olisi pitänyt tehdä (kuten kaikilla uusilla teknologioilla yleensä tehdään). Ja silloinhan minä avauduin siitä asiasta :)
Yhä enemmän nykyisin pitää katsoa kuitenkin pala kerrallaan ja miettiä millä teknologialla tai tavalla mikäkin osa-alue kannattaa tehdä. Ja usein räätälitekeminen ja julkkarit ja verkkokauppa-alustat ym. teknologiat elävätkin sulassa sovussa.
Jos minä puhun jonkun asian puolesta, niin sen asian puolesta, että uskallettaisiin käyttää vanhoja ja uusia teknologioita rinnakkain ja niihin tarkoituksiin mihin ne sopivat parhaiten. React ja erilaiset mikroarkkitehtuurit eivät korvaa julkkareita, eivätkä ole ”uusi vaihe”, vaan täydentävää teknologiaa jotka kaventavat julkkareiden roolia, mutta eivät korvaa sitä.
Ei julkkareita esimerkiksi voi mitenkään leimata ”vanhanaikaisiksi”, vaikka ne sinun mielestäsi ovatkin kovin kankeita ja epäkiinnostavia.
Kirjoituksen takana on yksinkertaisesti se näkemys, että räätälipuolella on isompia riskejä kuin ”tylsemmillä” alueilla, ja tämä kannattaa huomioida. Räätälitekemiselle on paikkansa ja web-sovelluksien määrät kasvavat koko ajan, ja JS-frameworkit ovat syntyneet tarpeeseen.
Asiakkaiden näkökulmasta uusimpien tekniikoiden tuomat hyödyt eivät vain aina ole kovin konkreettisia tai relevantteja vaikka ne toimistojen ja kehittäjien näkökulmasta olisivatkin huomattavia.
Enkä mä ajattele, että ”hipsteridevaajat” olisivat jotenkin pahoilla ajatuksilla liikenteessä. Oman ammatillisen kiinnostuksen ja urakehityksen näkökulmasta asioiden katsominen on vain aika erilainen näkökulma kuin asiakkaan näkökulma. Ja mun näkökulmasta nyt vain on niin, että turhan usein tuntuu se asiakkaan näkökulma jäävän vähän sivuun siinä teknologiavalinnassa. Saat toki olla eri mieltä.
Esimerkiksi me North Patrolissa yritetään just projekteissa saada nämä eri näkökulmat kohtaamaan, jotta tehtäisiin teknologiavalintoja joissa on ajateltu asiakkaan tilannetta, palvelun vaatimuksia, jatkokehityksen elinkaarta, kustannuksia, kehittäjien toivomuksia ja esimerkiksi toimistokenttää. Kaikki nuo näkökulmat ovat tärkeitä, ja riippuen tilanteesta, eri osa-alueet korostuvat.