C++ vs Rust järjestelmien modernisoinnissa: kirjoita uudelleen, kääri vai jätä se yksin?

Johdanto

Tiimien on modernisoitava tärkeä järjestelmä ja he haluavat realistisen polun, joka kunnioittaa toimitusriskiä, ​​tiimitaitoja ja olemassa olevia alkuperäisiä resursseja. Siksi tällaiset artikkelit näkyvät ostajatutkimuksessa kauan ennen ostotilauksen ilmestymistä. Tiimit, jotka etsivät c++ vs rust, järjestelmien modernisointia, ffi-migraatiota ja alkuperäisen koodin uudelleenkirjoittamista, selailevat harvoin viihdettä varten. He yrittävät siirtää tuotteen, alustan tai tutkimusaloitteen todellisen toimitusrajoitteen ohi.

Alkuperäiset järjestelmät toimivat, kun ajoitus, muistin asettelu, laitteiston läheisyys tai alustahistoria vaikuttavat edelleen liiketoiminnan tulokseen. Siellä kielen valinnasta ja rajojen suunnittelusta tulee toimituskysymyksiä. Toisin sanoen ongelma on julkaisusuunnitelman, teknisen tuntemattoman ja liike-elämän odotuksen välissä, joka on jo kyllästynyt kohteliaaseen odottamiseen.

Yksi syy tämän luokan työlle tuntuu kiusalliselta on se, että se saapuu usein pienemmäksi naamioituna. Tiimi sanoo haluavansa tarkistuksen, virityspassin, prototyypin, käyttöönottosuojan, puhtaamman jäsentimen, turvallisemman avustajan, paremman päivityspolun, siirtolukeman tai vakaamman rajan. Pyynnön alla piilee yleensä yksinkertaisempi totuus: järjestelmä on tärkeä, paine on todellinen, eikä nykyinen arkkitehtuuri enää saa ilmaista arkeutta ympäristöltä.

Siellä tekninen kirjoittaminen on joko hyödyllistä tai koristeellista. Koristeellinen kirjoittaminen järjestää ammattikieltä uudelleen, kunnes kaikki tuntevat itsensä kalliiksi. Hyödyllinen kirjoitus antaa lukijalle terävämmän mielen mallin, rehellisemmän toimituspolun ja ainakin yhden käytännön liikkeen, joka kannattaa tehdä ensi viikolla. Pyrimme toiseen luokkaan. Elämä on lyhyt, ja tuotantojärjestelmät ovat yllättävän lahjakkaita muuttamaan koristeellisen itseluottamuksen palkattomaksi ylityöksi.

Miksi ostajat päätyvät tänne ensin

Tällainen työ tulee yleensä tärkeäksi ympäristöissä, kuten alustan modernisoinnissa, alkuperäisen koodin migraatiossa ja yhteensopivuusstrategiassa. Yhteinen lanka on seuraus. Järjestelmän on pysyttävä liikkeessä, kun panokset latenssista, oikeellisuudesta, altistumisesta, toimivuudesta, kustannuksista tai etenemissuunnitelman uskottavuudesta kasvavat samanaikaisesti. Heti kun työnkulku tulee asiakkaiden, tilintarkastajien, operaattoreiden tai tulojen näkyväksi, suunnittelustandardi muuttuu. Hiljaisesti, mutta päättäväisesti.

Ostaja aloittaa yleensä yhdestä kiireellisestä kysymyksestä: voidaanko tätä ongelmaa käsitellä kohdistetulla insinöörityöllä vai vaatiiko se laajempaa uudelleensuunnittelua? Vastaus riippuu arkkitehtuurista, liitännöistä, toimitusrajoituksista ja todisteiden laadusta, jonka tiimi voi kerätä nopeasti. Väärä vastaus on kallista tylsällä, hallinnollisella tavalla. Se lisää viivettä, moninkertaistaa kokoukset ja luo juuri sen verran hämmennystä, että kaikki voivat väittää toimineensa varovaisesti, kun järjestelmä toimii edelleen väärin.

On myös syytä sanoa jotain epäromanttista: älykkyyden puute estää harvoin näitä sitoumuksia. Ne estävät epäselvät rajat, heikko sekvenssi tai puuttuva tekninen luku. Joukkueessa on usein älykkäitä ihmisiä ja vakavia aikomuksia. Siitä puuttuu puhdas, todisteisiin perustuva tapa päättää, mistä leikata ensin. Tämä on se osa, jonka hyvän insinöörikonsultoinnin pitäisi korjata.

Missä työstä tulee totta

Työ muuttuu todelliseksi sillä hetkellä, kun tiimi lopettaa puhumisen kyvykkyydestä yleensä ja alkaa puhua yhdestä konkreettisesta polusta järjestelmän läpi. Mikä käyttäjä tai operaattori käynnistää sen? Mitä tietojoukkoa, käyttöliittymää, suoritusaikaa, laitetta tai alijärjestelmää se koskettaa? Minkä polun osan sallitaan epäonnistua sulavasti ja millä ei ole varaa viehätykseen tai monitulkintaisuuteen? Nämä käytännön kysymykset ovat, kuinka kalliit ongelmat menettävät naamiointinsa.

Siksi vahvimmat tekniset tiimit kohtelevat edustavia esineitä epätavallisen kunnioittavasti. Lokinäyte, sieppaus, pieni benchmark, uusintajälki, epäilyttävä päivityspaketti, käytäntömatriisi tai tosielämän työnkulun transkriptio voivat tehdä yhdessä päivässä hyödyllisempää työtä kuin viikon arkkitehtuuriteatteria. Artefaktit ovat yleensä vähemmän sentimentaalisia kuin liukukannet. He kertovat sinulle, mitä järjestelmä teki, eivät mitä järjestelmä toivoi tarkoittavan.

Siitä eteenpäin insinööriongelma konkretisoituu. Tiimin on tunnistettava, missä piilokustannukset tai piiloriski todella tulevat polulle, mikä laskettaisiin uskottavaksi parannukseksi ja mikä muutos voi osoittaa suunnan muuttamatta sitoutumista satunnaiseksi kuuden kuukauden muuttoeepoksi. Tämä on kohta, jossa vanhempi tekninen luku alkaa ansaita arvoaan.

Miksi joukkueet juuttuvat

Ryhmät pysähtyvät yleensä, kun arkkitehtuurikeskustelut muuttuvat abstrakteiksi. Hyödyllinen vastaus on lähempänä ABI vakautta, profilointia koskevia todisteita, omistusrajoja ja asteittaisen modernisoinnin taloudellisuutta.

Siksi vahva tekninen työ tällä alueella alkaa yleensä kartalla: asiaankuuluva luottamusraja, ajoaikapolku, vikatilat, käyttäytymistä muokkaavat rajapinnat ja pienin muutos, joka merkittävästi parantaisi lopputulosta. Kun ne ovat näkyvissä, työstä tulee paljon suoritettavampaa. Siihen asti joukkueilla on tapana vaihdella kahden huonon tuulen välillä: "tarvitsemme täydellisen uudelleenkirjoituksen" ja "varmasti yksi pieni korjaustiedosto pelastaa meidät". Kumpikaan mieliala ei ole menetelmä.

Toinen syy joukkueiden pysähtymiseen on se, että he sekoittavat toiminnan pitoon. Ne lisäävät säätimen, kojelaudan, uudelleenyrityksen, kääreen, portin tai kirjaston ja tuntevat olonsa tilapäisesti paremmaksi, koska jokin liikkui. Liikkuminen ei ole sama asia kuin edistyminen. Järjestelmä voi liikkua ympyrää hämmästyttävällä innostuksella. Hyödyllinen testi on, onko muutos vähentänyt epäselvyyttä, vähentänyt altistumista, parantunut ennustettavuutta vai lyhentänytkö päätös päätökseen, jota joku voi puolustaa.

Hyvä uutinen on, että useimmat näistä ongelmista ovat paljon vähemmän teatraalisia, kun laajuus on rehellinen. Kun tiimi näkee todellisen rajan ja polun, työ rauhoittuu. Se on edelleen vaikeaa, mutta siitä tulee sellaista vaikeaa, jonka kanssa insinöörit voivat käsitellä: erityistä, mitattavaa ja ärsyttävän kuolevaista.

Miltä Hyvä näyttää

Hyvä alkuperäinen suunnittelu pitää suorituskyvyn, ylläpidettävyyden ja siirtymisriskin samassa kuvassa, joten järjestelmä voi kehittyä ilman, että jokainen osajärjestelmä tarvitsee samaa kieltä tai samaa uudelleenkirjoituspolkua.

Käytännössä se tarkoittaa, että muutama asia tulee selväksi aikaisin: ongelman tarkka laajuus, hyödylliset mittarit, toimintarajat, todisteet, joita ostaja tai teknologiajohtaja pyytää, ja toimitusvaihe, joka ansaitsee tapahtua seuraavaksi. Hyvä työ täällä näyttää harvoin taianomaiselta. Se näyttää johdonmukaiselta. Järjestelmästä tulee helpompi selittää, helpompi testata, helpompi muuttaa turvallisesti ja helpompi perustella ihmisille, jotka eivät olleet alkuperäisen rakenteen sisällä.

Tällä johdonmukaisuudella on merkitystä, koska tekniset ostajat eivät osta proosaa. He ostavat paremman järjestelmän tilan: selkeämpiä rajoja, turvallisempaa käyttäytymistä, alhaisempaa latenssia, vahvempaa näyttöä tai uskottavampaa reittiä seuraavaan virstanpylvääseen. Tyylikäs kirjoitus on tervetullutta. Tyylikäs drift ei ole.

Käytännön tapaukset, jotka kannattaa ratkaista ensin

Hyödyllinen ensimmäinen työn aalto kohdistuu usein kolmeen tapaukseen. Ensin tiimi valitsee polun, jolla liiketoiminnan vaikutus on jo ilmeinen. Toiseksi se valitsee työnkulun, jossa tekniset muutokset voidaan mitata arvaamisen sijaan. Kolmanneksi se valitsee rajan, jossa tulos voidaan dokumentoida tarpeeksi hyvin todellisen päätöksen tukemiseksi. Tämä pitää kihlauksen maassa. Se vähentää myös kiusausta pitää löytöjä kuin ylellinen kylpylä ahdistuneelle arkkitehtuurille.

Tämän aiheen edustavia tapauksia ovat alustan modernisointi, alkuperäisen koodin siirto ja yhteensopivuusstrategia. Nämä kotelot ovat yleensä riittävän runsaita paljastamaan todellisen toimitusongelman ja riittävän kapeita pitämään ensimmäisen liikkeen käytännöllisenä. Heillä on myös tapana tuottaa todisteita siitä, että johtajuus voi ymmärtää ilman, että kaikkien tarvitsee ensin hankkia uusi tekninen uskonto.

Alustan modernisointi

Paineet tässä skenaariossa näkyvät yleensä aikaisemmin kuin tiekartta myöntää. Alustan modernisoinnissa järjestelmä istuu yleensä niin lähellä asiakkaita, operaattoreita tai säänneltyä työtä, että epämääräinen tekninen vastaus lakkaa olemasta viehättävä. Demo voi selviytyä optimismista. Live-työnkulku ei voi. Kun todellista liikennettä, todellisia käyttäjiä tai todellisia hyväksyntöjä tulee huoneeseen, suunnittelun sisällä oleva hiljainen heikkous alkaa käyttäytyä toistuvana kuluna.

Tiimit saapuvat usein tänne kokeiltuaan yhtä kapeaa korjausta liikaa. He vaihtavat kehotteen, lisäävät uuden kääreen, ostavat uuden kojelaudan tai lupaavat itselleen, että yksi lisäsprintti rauhoittaa tilanteen. Yleensä ei. Ryhmät pysähtyvät yleensä, kun arkkitehtuurikeskustelut muuttuvat abstrakteiksi. Hyödyllinen vastaus on lähempänä ABI vakautta, profilointia koskevia todisteita, omistusrajoja ja asteittaisen modernisoinnin taloudellisuutta. Syvempi ongelma on, että työnkululla ei vieläkään ole puhdasta rajaa, rehellistä mittauspolkua tai toimitusjaksoa, joka selittää, mikä muuttuu ensin ja miksi.

Ensimmäinen hyödyllinen askel on nimetä todellinen raja sen sijaan, että ihailet ominaisuutta turvalliselta etäisyydeltä. Käytännössä se tarkoittaa ongelman vähentämistä yhdelle järjestelmän läpi kulkevalle reitille, yhdelle riskialtis päätöspisteelle ja yhdelle tekniselle lopputulokselle, jonka insinöörit voivat tarkistaa ja johdon ymmärtää. Näin teos lakkaa olemasta tunnelmallista ja alkaa tulla suoritettavaksi.

Hyödyllinen vastaesimerkki on lähellä. Väärä tiimi vastaa alustan modernisointiin laajentamalla heti soveltamisalaa. Se ajoittaa alustan uudelleenkirjoituksen, ostaa kaksi uutta työkalua ja alkaa puhua lihavoiduilla abstrakteilla substantiiviilla, koska lihavoitut abstraktit substantiivit luovat väliaikaisen vauhdin tunteen. Parempi tiimi kysyy hieman vaatimattomampaa kysymystä: mikä raja vahingoittaa meitä ensin, mitkä todisteet osoittaisivat sen ja mikä kapea muutos ansaitsisi seuraavan askeleen? Tämä toinen lähestymistapa kuulostaa vähemmän elokuvamaiselta, mutta sillä on taipumus selviytyä kosketuksista kalentereihin, hankintoihin ja epämukavaan todellisuuteen, että muita tiekarttoja on edelleen olemassa.

Tässä olevat tekniset neuvot ovat riittävän yksinkertaisia ​​kuulostaakseen melkein töykeiltä. Rakenna yksi puhdas luku. Vahvista se edustavaa liikennettä tai esineitä vastaan. Muuta yksi tärkeä asia kerrallaan. Näytä sitten tulos kielellä, jota sekä insinöörit että budjetinhaltijat voivat käyttää. Vakavista järjestelmistä tulee helpommin hallittavia, kun niiden vaikein polku konkretisoidaan. Ne uuvuttavat, kun kaikki keskustelevat niistä ikään kuin ne olisivat säätä.

Natiivikoodin siirto

Tämä on yksi niistä tapauksista, joissa arkkitehtuuri alkaa lähettää laskuja ennen kuin rahoitus. Natiivikoodin migraatiossa järjestelmä istuu yleensä niin lähellä asiakkaita, operaattoreita tai säänneltyä työtä, että epämääräinen tekninen vastaus lakkaa olemasta viehättävä hyvin nopeasti. Demo voi selviytyä optimismista. Live-työnkulku ei voi. Kun todellista liikennettä, todellisia käyttäjiä tai todellisia hyväksyntöjä tulee huoneeseen, suunnittelun sisällä oleva hiljainen heikkous alkaa käyttäytyä toistuvana kuluna.

Tiimit saapuvat usein tänne kokeiltuaan yhtä kapeaa korjausta liikaa. He vaihtavat kehotteen, lisäävät uuden kääreen, ostavat uuden kojelaudan tai lupaavat itselleen, että yksi lisäsprintti rauhoittaa tilanteen. Yleensä ei. Ryhmät pysähtyvät yleensä, kun arkkitehtuurikeskustelut muuttuvat abstrakteiksi. Hyödyllinen vastaus on lähempänä ABI vakautta, profilointia koskevia todisteita, omistusrajoja ja asteittaisen modernisoinnin taloudellisuutta. Syvempi ongelma on, että työnkululla ei vieläkään ole puhdasta rajaa, rehellistä mittauspolkua tai toimitusjaksoa, joka selittää, mikä muuttuu ensin ja miksi.

Rehellinen lähestymistapa on instrumentoida polku, pakottaa vaaralliset siirtymät valoon ja tehdä seuraava päätös todisteiden eikä mielialan perusteella. Käytännössä se tarkoittaa ongelman vähentämistä yhdelle järjestelmän läpi kulkevalle reitille, yhdelle riskialtis päätöspisteelle ja yhdelle tekniselle lopputulokselle, jonka insinöörit voivat tarkistaa ja johdon ymmärtää. Näin teos lakkaa olemasta tunnelmallista ja alkaa tulla suoritettavaksi.

Hyödyllinen vastaesimerkki on lähellä. Väärä tiimi vastaa alkuperäisen koodin siirtoon laajentamalla soveltamisalaa välittömästi. Se ajoittaa alustan uudelleenkirjoituksen, ostaa kaksi uutta työkalua ja alkaa puhua lihavoiduilla abstrakteilla substantiiviilla, koska lihavoitut abstraktit substantiivit luovat väliaikaisen vauhdin tunteen. Parempi tiimi kysyy hieman vaatimattomampaa kysymystä: mikä raja vahingoittaa meitä ensin, mitkä todisteet osoittaisivat sen ja mikä kapea muutos ansaitsisi seuraavan askeleen? Tämä toinen lähestymistapa kuulostaa vähemmän elokuvamaiselta, mutta sillä on taipumus selviytyä kosketuksista kalentereihin, hankintoihin ja epämukavaan todellisuuteen, että muita tiekarttoja on edelleen olemassa.

Tässä olevat tekniset neuvot ovat riittävän yksinkertaisia ​​kuulostaakseen melkein töykeiltä. Rakenna yksi puhdas luku. Vahvista se edustavaa liikennettä tai esineitä vastaan. Muuta yksi tärkeä asia kerrallaan. Näytä sitten tulos kielellä, jota sekä insinöörit että budjetinhaltijat voivat käyttää. Vakavista järjestelmistä tulee helpommin hallittavia, kun niiden vaikein polku konkretisoidaan. Ne uuvuttavat, kun kaikki keskustelevat niistä ikään kuin ne olisivat säätä.

Yhteistyöstrategia

Ensi silmäyksellä työnkulku näyttää tavalliselta, ja juuri siksi tiimit arvioivat sen väärin. Yhteistyöstrategiassa järjestelmä istuu yleensä niin lähellä asiakkaita, operaattoreita tai säänneltyä työtä, että epämääräinen tekninen vastaus lakkaa olemasta viehättävä hyvin nopeasti. Demo voi selviytyä optimismista. Live-työnkulku ei voi. Kun todellista liikennettä, todellisia käyttäjiä tai todellisia hyväksyntöjä tulee huoneeseen, suunnittelun sisällä oleva hiljainen heikkous alkaa käyttäytyä toistuvana kuluna.

Tiimit saapuvat usein tänne kokeiltuaan yhtä kapeaa korjausta liikaa. He vaihtavat kehotteen, lisäävät uuden kääreen, ostavat uuden kojelaudan tai lupaavat itselleen, että yksi lisäsprintti rauhoittaa tilanteen. Yleensä ei. Ryhmät pysähtyvät yleensä, kun arkkitehtuurikeskustelut muuttuvat abstrakteiksi. Hyödyllinen vastaus on lähempänä ABI vakautta, profilointia koskevia todisteita, omistusrajoja ja asteittaisen modernisoinnin taloudellisuutta. Syvempi ongelma on, että työnkululla ei vieläkään ole puhdasta rajaa, rehellistä mittauspolkua tai toimitusjaksoa, joka selittää, mikä muuttuu ensin ja miksi.

Hyvät tiimit voittaa tässä olemalla tarkkoja: mikä käyttöliittymä on tärkeä, mikä signaali osoittaa parannusta ja mikä pikakuvake on edelleen liian kallis luottaa. Käytännössä se tarkoittaa ongelman vähentämistä yhdelle järjestelmän läpi kulkevalle reitille, yhdelle riskialtis päätöspisteelle ja yhdelle tekniselle lopputulokselle, jonka insinöörit voivat tarkistaa ja johdon ymmärtää. Näin teos lakkaa olemasta tunnelmallista ja alkaa tulla suoritettavaksi.

Hyödyllinen vastaesimerkki on lähellä. Väärä tiimi vastaa yhteistoimintastrategiaan laajentamalla sen soveltamisalaa välittömästi. Se ajoittaa alustan uudelleenkirjoituksen, ostaa kaksi uutta työkalua ja alkaa puhua lihavoiduilla abstrakteilla substantiiviilla, koska lihavoitut abstraktit substantiivit luovat väliaikaisen vauhdin tunteen. Parempi tiimi kysyy hieman vaatimattomampaa kysymystä: mikä raja vahingoittaa meitä ensin, mitkä todisteet osoittaisivat sen ja mikä kapea muutos ansaitsisi seuraavan askeleen? Tämä toinen lähestymistapa kuulostaa vähemmän elokuvamaiselta, mutta sillä on taipumus selviytyä kosketuksista kalentereihin, hankintoihin ja epämukavaan todellisuuteen, että muita tiekarttoja on edelleen olemassa.

Tässä olevat tekniset neuvot ovat riittävän yksinkertaisia ​​kuulostaakseen melkein töykeiltä. Rakenna yksi puhdas luku. Vahvista se edustavaa liikennettä tai esineitä vastaan. Muuta yksi tärkeä asia kerrallaan. Näytä sitten tulos kielellä, jota sekä insinöörit että budjetinhaltijat voivat käyttää. Vakavista järjestelmistä tulee helpommin hallittavia, kun niiden vaikein polku konkretisoidaan. Ne uuvuttavat, kun kaikki keskustelevat niistä ikään kuin ne olisivat säätä.

Suosittelemamme käytännöt

Aloita kapeimmasta rajasta, joka voi silti vastata liiketoimintakysymykseen

Useimmat joukkueet ylittävät ensimmäisen siirron. He yrittävät ratkaista koko kiinteistön yhden reitin sijasta järjestelmän läpi, joka todella sisältää riskin. Parempi siirto on aloittaa kapeimmasta osasta, joka edelleen heijastaa tiimien tarvetta uudistaa tärkeä järjestelmä ja realistinen polku, joka kunnioittaa toimitusriskiä, ​​tiimitaitoja ja olemassa olevia alkuperäisiä resursseja. Tavoitteena ei ole näyttää kokonaisvaltaiselta ensimmäisenä päivänä. Tavoitteena on tehdä ensimmäisestä tuloksesta kiistaton.

Laite ennen optimointia

Jos tiimi ei pysty selittämään, miltä "parempi" näyttää jäljissä, mittareissa, lokeissa tai testiesineissä, se väittelee edelleen intuitiosta. Intuitio on hyödyllinen siihen pisteeseen asti, että se tulee kalliiksi. Sen jälkeen se tarvitsee aikuisen valvonnan. Laita telemetria, todisteiden talteenotto ja pieni validointivaljaat paikoilleen ennen kuin kukaan väittää, että suunnittelu on korjattu.

Erilliset luku-, kirjoitus- ja hyväksymispolut tarkoituksella

Yllättävän paljon kipua syntyy siitä, että sallit yhden polun tehdä kaiken. Vain luku -virrat, tilaa muuttavat virrat ja runsaasti hyväksyntää vaativat virrat eivät saa jakaa samoja oletuksia. Kun he tekevät niin, järjestelmä käyttäytyy kuin ystävällinen harjoittelija, jolla on järjestelmänvalvojan oikeudet: innostunut, nopea ja syvästi kykenevä luomaan kokouksia, joita kukaan ei halunnut.

Pakettilöydöt kielellä, jonka mukaan ostaja voi toimia

Hyvä suunnittelutulos on ajoitettavissa. Teknisen johtajan, tietoturvajohtajan tai hankintavastaavan pitäisi pystyä näkemään, mikä on kiireellistä, mikä rakenteellista, mikä voi odottaa ja mitkä todisteet tukevat tätä järjestystä. Tämä muuttaa teknisen lukemisen toimitusliikkeeksi arvostettujen havaintojen pinon sijaan.

Suunnittele seuraava askel, kun todisteet ovat vielä tuoreita

Vahvimmat joukkueet eivät pysähdy diagnoosiin. Ne muuntavat diagnoosin seuraavaksi rajoitetuksi sprintiksi, uudelleentestiksi, prototyypiksi tai käyttöönottotarkistuspisteeksi. Hyvä alkuperäinen suunnittelu pitää suorituskyvyn, ylläpidettävyyden ja siirtymisriskin samassa kuvassa, joten järjestelmä voi kehittyä ilman, että jokainen osajärjestelmä tarvitsee samaa kieltä tai samaa uudelleenkirjoituspolkua. Juuri tämä estää kovaa työtä hajoamasta toiseen harkittuun asiakirjaan, jota kaikki ylistävät ja jota kukaan ei suunnittele.

Vastaesimerkkejä, jotka kannattaa pitää mielessä

Kiillotettu kehote ei ole ohjaustaso

Ryhmät käyttäytyvät usein ikään kuin ankara kehotus voisi korvata arkkitehtuurin. Se ei voi. Kehotus voi vaikuttaa käyttäytymiseen. Se ei voi kaventaa käyttöoikeuksia takautuvasti, korjata haun laajuutta tai puhdistaa huolimatonta käyttöliittymää. Tämä vastaa ohjelmistoa märän lattian sanomiseen "ole matto".

Vahva vertailuarvo ei ole sama asia kuin kestävä käyttöönotto

Paikallinen menestys saapuu usein aikaisin. Tuotannon uskottavuus saapuu myöhemmin ja vaatii kuitit. Vertailuarvo, proof-of-concept tai erillinen testi on hyödyllinen vain, kun tiimi voi yhdistää sen sotkuiseen työnkulkuun, jolla on kentällä todella merkitystä. Muuten tuloksesta tulee koristeellinen itseluottamusobjekti.

Lisää työkaluja ei pelasta sumeaa toimintamallia

Tiimi voi pinota skannereita, kojetauluja, malleja, simulaattoreita tai jäljitystasoja, kunnes arkkitehtuuri muistuttaa modernin taiteen installaatiota laskutuksella. Jos työnkulussa ei vieläkään ole selkeää rajaa, omistajaa ja korjausjärjestystä, useammat työkalut tekevät hämmennystä paremmin havaittavissa.

Kiireellisyys ei oikeuta löysää kielenkäyttöä

Kun insinöörit sanovat "meidän täytyy vain lähettää jotain", he tarkoittavat yleensä "olemme koodaamassa velkaa, joka meidän on selitettävä uudelleen stressin alla". Toimituksella on väliä. Samoin tarkkuus. Taiteen tarkoituksena on pitää liike ja tarkkuus yhdessä sen sijaan, että kohdelisi niitä vihollisina, jotka jakavat keittiön kiusallisesti.

Toimitussuunnitelma, jota todella suosittelemme

Vaihe 1: Rakenna tekninen luku, joka nimeää todellisen pullonkaulan

Ensimmäinen vaihe on diagnostinen ja aktiivinen. Kartoitamme live-polun, keräämme edustavia artefakteja ja käännämme tiimien tarpeet modernisoidakseen tärkeän järjestelmän ja haluamme realistisen polun, joka kunnioittaa toimitusriskiä, ​​tiimin taitoja ja olemassa olevia alkuperäisiä resursseja yhdeksi selkeäksi tekniseksi lausumaksi. Täällä tiimit lopettavat väittelyn oireista ja alkavat kuvailla todellista rajaa, käyttöliittymää tai toimintatilaa, joka ansaitsee huomion.

Vaihe 2: Kutista ongelma rajoitetuksi suunnitteluliikkeeksi

Kun kuva on rehellinen, seuraava kysymys ei ole "miten korjaamme kaiken?" Se on "mikä on pienin muutos, joka parantaa järjestelmää olennaisesti ja osoittaa suunnan?" Se voi olla suojakaide, jäsentäjä, rajojen uudelleenkirjoitus, toistovaljaat, käyttöönottoportti tai laajennettu prototyyppi. Pienemmät ja terävämmät lyönnit leveämmin ja teatraalisesti.

Vaihe 3: Vahvista todisteilla, jotka ovat riittävän vahvoja selviytyäksesi skeptisestä kokouksesta

Tällä vaiheella on merkitystä, koska tulos on vain yhtä hyödyllinen kuin sen ympärillä oleva todiste. Tiimin pitäisi pystyä näyttämään, mikä muuttui, miten se mitattiin, mikä on edelleen riskialtista ja mitä seuraava askel maksaisi. Ostajat luottavat suunnitteluun enemmän, kun suunnittelu käyttäytyy kuten tuotanto on ennen nähnyt. Se kuulostaa itsestään selvältä. Se on edelleen kilpailuetu.

Vaihe 4: Luovuta jotain, jota tuote- tai alustatiimi voi todella käyttää

Lopullisen tuloksen tulisi tukea toimintaa: käyttöönottohuomautuksia, korjausmääräystä, prototyypin päätöstä, arkkitehtuurin suuntaa, uudelleentestauksen todisteita ja päätösvalmiita konteksteja. SToFU auttaa tiimejä modernisoimaan alkuperäisiä järjestelmiä menettämättä vaivalla saavutettua käyttäytymistä, joka teki näistä järjestelmistä kaupallisesti hyödyllisiä. Tämä tarkoittaa usein profilointia, rajojen suunnittelua ja kapeita, varmoja liikkeitä. Teoksesta tulee kaupallisesti arvokasta, kun organisaatio voi käyttää sitä kääntämättä sitä kahdesti.

Punaiset liput, jotka kertovat, että työ on suurempi kuin se aluksi näyttää

Yllättävän paljon teknistä kipua tulee luettavaksi, kun tiimi oppii tunnistamaan muutamia toistuvia signaaleja. Nämä punaiset liput näkyvät riippumatta siitä, onko aiheena C++, alkuperäisten järjestelmien toimivuus vai rajaprototyyppi, joka on alkanut herättää aikuisten odotuksia.

Tiimi kuvailee ongelmaa adjektiiveilla rajojen sijaan

Kun jokainen keskustelu kuulostaa "hauraalta", "hitaalta", "riskialtiselta" tai "monimutkaiselta", mutta kukaan ei voi osoittaa tarkkaa liitäntää, osajärjestelmää tai ohjauspistettä, joka ansaitsee huomion, työ on edelleen liian sumuista. Sumu on kallista. Se hidastaa toimitusta ja antaa kaikille tarpeeksi epäselvyyttä tunteakseen olonsa viisaaksi ja sitoutumattomaksi samaan aikaan.

Ensimmäinen ehdotettu korjaus on suurempi kuin ensimmäinen hyödyllinen todiste

Terve suunnitteluohjelma ansaitsee yleensä luottamuksen rajatulla todisteella ennen kuin se pyytää laajaa uudelleenkirjoitusta. Kun aivan ensimmäinen ratkaisu jollakin tavalla vaatii kuukausia työtä, uutta alustaa ja useita lupauksia tulevaisuuden yksinkertaisuudesta, tiimi saattaa suojella itseään mittauksilta sen sijaan, että siirtyisi sitä kohti.

Kukaan ei voi sanoa, mitkä todisteet lopettaisivat väittelyn

Tämä on klassinen merkki siitä, että organisaatio keskustelee tunteista teknisessä puvussa. Hyvät tiimit voivat vastata tylsään mutta arvokkaaseen kysymykseen: mikä mittaus, jäljitys, lisääntymisvaihe, vertailukohta, hyödyntämispolku tai artefakti saa meidät muuttamaan mieltämme? Jos vastausta ei vielä ole, seuraavan sprintin pitäisi luultavasti tuottaa se.

Ostaja kuulee yksityiskohdat, mutta ei järjestystä

Teknisellä syvyydellä on väliä, mutta järjestyksellä on enemmän merkitystä, kun rahoitus, ajoitus tai riskinomistus ovat pöydällä. Jos teknologiajohtaja tai tuotteen omistaja ei vieläkään pysty kertomaan, mitä tapahtuu ensin, mitä tapahtuu seuraavaksi ja mikä voi turvallisesti odottaa, tekninen luku ei ole valmis. Se on vain mielenkiintoista.

Työkalut ja kuviot, joilla on yleensä merkitystä

Tarkka pino muuttuu asiakkaan mukaan, mutta taustalla oleva malli on vakaa: tiimi tarvitsee havainnoitavuutta, kapeaa ohjaustasoa, toistettavaa kokeilua tai validointipolkua ja tuloksia, joita muut päättäjät voivat todella käyttää. Pinosta tulee vaikuttava vasta, kun se on luettavissa. Sitä ennen se on vain kasa kalliita substantiivit, jotka koeelevät merkityksellisyyttä.

• perf / VTune todelliseen pullonkaulan mittaukseen
• desinfiointiaineet muistin oikeellisuuden varmistamiseksi
• CMake tai Bazel toistettavia rakennelmia varten
• FFI sopimustestit rajaturvallisuuden varmistamiseksi
• liekkikaaviot yhteydenpitoon hotspottien ympärillä

Pelkät työkalut eivät ratkaise ongelmaa. Ne yksinkertaisesti helpottavat työn pitämistä rehellisenä ja toistettavana, kun tiimi oppii, missä todellinen vipuvaikutus on. Kypsä tiimi valitsee työkaluja, jotka lyhentävät selitystä ja iteraatiota. Tämä tarkoittaa yleensä vähemmän mysteerilaatikoita, selkeämpiä käyttöliittymiä, parempia jälkiä ja esineitä, jotka selviävät skeptisestä arvioinnista.

Hyödyllinen koodiesimerkki

Kapea FFI-sopimus sekapohjaisille järjestelmille

Yhteensopivuus pysyy terveempänä, kun raja sisältää yksinkertaista dataa ja selkeät käyttöiän säännöt.

extern "C" { struct QuoteSlice { const double* values; unsigned int len; }; int compute_midprice(const QuoteSlice* bids, const QuoteSlice* asks, double* out_mid); }
int compute_midprice(const QuoteSlice* bids, const QuoteSlice* asks, double* out_mid) { if (!bids || !asks || !out_mid || bids->len == 0 || asks->len == 0) return -1; *out_mid = (bids->values[0] + asks->values[0]) / 2.0; return 0; }

Interopista tulee helpommin ylläpidettävä, kun sopimus on tarpeeksi tylsä, jotta molemmat osapuolet voivat testata sitä itsenäisesti.

Kuinka parempi suunnittelu muuttaa taloutta

Vahva toteutuspolku parantaa enemmän kuin oikeellisuus. Se yleensä parantaa koko ohjelman taloudellisuutta. Paremmat ohjaimet vähentävät uudelleentyöskentelyä. Parempi rakenne vähentää koordinaatiovastusta. Parempi havaittavuus lyhentää tapahtumareaktiota. Parempi ajonaikainen käyttäytyminen vähentää kalliita yllätyksiä, jotka pakottavat etenemissuunnitelmaan muutoksia jälkikäteen.

Tästä syystä tekniset ostajat etsivät yhä useammin ilmauksia, kuten c++ vs rust, järjestelmien modernisointi, ffi-migraatio ja alkuperäisen koodin uudelleenkirjoitus. He etsivät kumppania, joka voi muuntaa teknisen syvyyden toimitusten edistykseksi. Mitä parempi suunnittelupolku, sitä helpompi on puolustaa laajuutta, selittää kompromisseja ja välttää paniikkiin perustuvat muutokset, jotka näyttävät nopeilta kolme päivää ja kalliilta kolme neljäsosaa.

Hyvä tekninen työ parantaa myös organisaation aineenvaihduntaa. Tuote tietää, mitä on turvallista luvata. Suunnittelu tietää, mitä muuttaa ensin. Turvallisuus tai toiminta tietää, mitä todisteita on olemassa. Johto tietää, ansaitseeko seuraava askel budjetin. Nämä hyödyt eivät ole erillisiä koodista. Niissä on usein tarkoitus tehdä koodi oikein.

Kuinka arvioida, onko työstä todella apua

Ensimmäiset hyödylliset mittarit ovat ne, jotka muuttavat päätöstä. Aiheesta riippuen se voi tarkoittaa viivettä ja jonon syvyyttä, hyödynnettävyyttä ja korjaustoimien läpimenoaikaa, simulaattorin tarkkuutta, laitteen palautumiskäyttäytymistä, tarkastettavuutta, käyttöönottoturvallisuutta tai yksinkertaista mutta jaloa kysymystä siitä, voivatko insinöörit nyt selittää järjestelmän turvautumatta käsieleihin ja optimismiin. Mittarit ovat arvokkaita, kun ne vähentävät epäselvyyttä ja pitävät kojelaudat sidoksissa päätöksiin.

Ostajan kannalta keskeinen kysymys on, paransiko työ jotakin kolmesta asiasta: toimitusnopeutta, järjestelmän luottamusta tai kaupallista valmiutta. Organisaation tulisi pystyä osoittamaan ennen ja jälkeen -näkymää, joka selventää, mikä muuttui polulla, joka liittyy c++ vs rust, järjestelmien modernisointi, ffi-migraatio. Jos tulos on teknisesti syvällinen, mutta jättää johtajuuden silti epävarmaksi seuraavasta siirrosta, työ ei ole valmis. Se on vain koulutettua.

Tästä syystä suosittelemme mittaamaan sekä suunnittelusignaalin että päätössignaalin. Seuraa tärkeimpiä teknisiä mittareita, mutta myös, onko tiimi saanut selkeämmän kattavuuden, lyhyemmän korjausjonon, turvallisemman käyttöönottotarinan vai uskottavamman arkkitehtuuripäätöksen. Nämä toisen asteen tulokset ovat usein siellä, missä todellinen taloudellinen hyöty elää.

Miltä ensimmäisen kolmenkymmenen päivän pitäisi näyttää

Tekniset ostajat kysyvät usein, miltä uskottava ensimmäinen kuukausi näyttää, ja se on terve vaisto. Hyvä sitoutuminen synnyttää liikettä varhain, mutta liikkeen tulee olla tarpeeksi jäsenneltyä, jotta organisaatio voi edelleen luottaa näkemäänsä.

Viikko 1: Tallenna nykyisen polun totuus

Ensimmäisen viikon pitäisi tuottaa todisteita sisältäviä esineitä. Tämä tarkoittaa, että edustavien syötteiden, jäljitysten, lokien, binäärien, sieppausten, testausvirheiden, käytäntökarttojen, kuvakaappausten tai työkuormanäytteiden, jotka on sidottu suoraan tiimeihin, on modernisoitava tärkeä järjestelmä ja haluttava realistinen reitti, joka kunnioittaa toimitusriskiä, ​​tiimin taitoja ja olemassa olevia alkuperäisiä resursseja. Jos sitoutuminen päättyy ensimmäisellä viikolla vain hienostuneella kielellä ja ilman vahvempaa näyttöä, tiimi on maksanut mielialan parantamisesta teknisen kehityksen sijaan.

Viikko 2: Tuo yksi päätöslaatuinen luku

Toisen viikon pitäisi muuttaa nämä esineet johdonmukaiseksi diagnoosiksi. Diagnoosin tulee nimetä raja, todennäköinen pullonkaula tai altistumisreitti, uskottavat korjausmuodot ja mittaus, joka ratkaisee niiden välillä. Tässä vaiheessa työn pitäisi jo tuntua rauhallisemmalta, jäsennellymmältä ja vähemmän ahdistavalta.

Viikko 3: Lähetä yksi rajoitettu siirto

Kolmas viikko on silloin, kun joukkue ansaitsee uskottavuuden. Lähetä portti, jäsentäjä, benchmark, uusintavaljaat, käytäntöjen hallinta, refactor-slice tai ajonaikainen muutos, joka parhaiten osoittaa suunnan. Pieni, kurinalainen työ voittaa täällä suuret julistukset, koska se opettaa organisaatiolle, millainen ongelma sillä todella on.

Viikko 4: Testaa uudelleen, dokumentoi ja päätä seuraava kaista

Neljännen viikon pitäisi vastata kolmeen kysymykseen todistein: mikä parani, mikä on edelleen riskialtista ja mikä ansaitsee seuraavan budjetoidun muutoksen. SToFU auttaa tiimejä modernisoimaan alkuperäisiä järjestelmiä menettämättä vaivalla saavutettua käyttäytymistä, joka teki näistä järjestelmistä kaupallisesti hyödyllisiä. Tämä tarkoittaa usein profilointia, rajojen suunnittelua ja kapeita, varmoja liikkeitä. Tavoitteena on jättää organisaatiolle selkeämpi järjestelmä, validoitu suunta ja seuraava päätös, joka tuntuu ansaitulta eikä improvisoidulta.

Käytännön harjoitus aloittelijoille

Nopein tapa oppia tämä aihe on rakentaa jotain pientä ja rehellistä sen sijaan, että teeskentelet ymmärtävänsä sen pelkästään dioista.

1. Valitse yksi alustan modernisointiin liittyvä osajärjestelmä.
2. Mittaa nykyinen viive, muisti tai integrointikipu, ennen kuin keskustelet toteutustyylistä.
3. Suorita mallikoodi ja lisää yksi sopimus tai ajoitusvahvistus.
4. Kartoita, mikä raja todella tarvitsee muutosta ja mikä raja tarvitsee vain eristystä.
5. Kirjoita yhden sivun modernisointisuunnitelma riskeistä, laajuudesta ja palautuksesta.

Jos harjoitus tehdään huolellisesti, tulos on jo hyödyllinen. Se opettaa aloittelijalle, miltä todellinen raja näyttää, miksi vahvat insinööritottumukset ovat tärkeitä tässä, ja hiljaisempi oppitunti, josta monet urat hyötyisivät aikaisemmin: vahva suunnittelu selventää syvästi.

Kysymyksiä, joita ostajien tulee kysyä ennen tämän työn hyväksymistä

Osaava kumppani ei saa hermostua, kun kysymykset tarkentuvat. Kova työ reagoi hyvin päivänvaloon. Jos mikään, se yleensä paranee, kun joku lopulta lakkaa pyytämästä taikuutta ja alkaa pyytää suunnittelua.

• Mihin rajaan tai rajapintaan liittyy mielestäsi suurin kaupallinen riski, ja miten todistat sen nopeasti?
• Mitä todisteita keräisit ensimmäisen viikon aikana välttääksesi väärän korjauksen rakentamisen suurella luottamuksella?
• Minkä työnkulun osan tulisi toistaiseksi jäädä tarkoituksellisesti manuaaliseksi tai hyväksyntäpohjaiseksi ja miksi?
• Miten osoittaisit johtajuutta, että seuraava insinöörisiirto luo näkyvää riskin pienenemistä?
• Jos lopettaisimme työn puolivälissä, mistä artefakista tai teknisestä luennosta kannattaisi vielä maksaa?
• Mikä saisi sinut sanomaan rehellisesti, että järjestelmä tarvitsee laajempaa uudelleensuunnittelua kohdennetun korjauksen sijaan?

Nämä kysymykset ovat erityisen hyödyllisiä, kun keskustellaan C++ vs Rust järjestelmien modernisoinnista: kirjoita uudelleen, kääri vai jätä se rauhaan? alkaa kuulostaa vaikuttavalta, mutta oudon liukkaalta. Oikeat vastaukset ovat yleensä konkreettisia, laajoja ja hieman vähemmän lumoavia kuin myyntikansi toivoi.

Kuinka SToFU voi auttaa

SToFU auttaa tiimejä modernisoimaan alkuperäisiä järjestelmiä menettämättä vaivalla saavutettua käyttäytymistä, joka teki näistä järjestelmistä kaupallisesti hyödyllisiä. Tämä tarkoittaa usein profilointia, rajojen suunnittelua ja kapeita, varmoja liikkeitä.

Se voi näkyä auditoinnina, kohdennettuna PoC-työnä, arkkitehtuurityönä, käänteisenä suunnitteluna, järjestelmien virittämisenä tai tiukasti rajatulla toimitussprintillä. Tarkoituksena on luoda tekninen luku ja seuraava askel, jota vakava ostaja voi käyttää välittömästi. Suosimme työtä, joka jättää asiakkaalle terävämmät rajat, vahvemmat todisteet ja vähemmän lauseita, jotka alkavat sanalla "oletimme".

Joskus oikea lopputulos on rakentaminen. Joskus se on kieltäytymistä rakentamasta väärää asiaa. Joskus se on kapeampi suunnitelma, vahvempi prototyyppi, selkeämpi korjausmääräys tai parempi selitys sille, miksi ongelma on arkkitehtoninen eikä kosmeettinen. Nämä ovat kaikki hyviä tuloksia. Vakava suunnittelu on sarja päätöksiä, joiden pitäisi ajan myötä muuttua helpommaksi, turvallisemmaksi ja rehellisemmäksi.

Viimeisiä ajatuksia

C++ vs Rust järjestelmien modernisoinnissa: kirjoita uudelleen, kääri vai jätä se yksin? viime kädessä on kyse edistymisestä tekniikan alalla. Tällä alueella hyvin liikkuvat joukkueet eivät odota täydellistä varmuutta. He rakentavat terävän teknisen kuvan, vahvistavat ensin vaikeimmat oletukset ja antavat todisteiden ohjata seuraavaa askelta.

Jos jokin teema on eteenpäin viemisen arvoinen, se on se, että selkeys on tekninen voimavara. Selkeät rajat, selkeät mittarit, selkeä omistajuus, selkeät todisteet, selkeä palautuslogiikka, selkeät seuraavat vaiheet. Järjestelmistä tulee harvoin turvallisempia, nopeampia tai hyödyllisempiä, koska joku on antanut kauniimman selityksen hämmennykselle. Ne paranevat, koska joku teki hieman vähemmän lumoavan työn muuttaakseen hämmennystä rakenteeksi.

Siksi myös tämäntyyppisillä artikkeleilla on merkitystä ostajille. The point is not to flatter the problem until it sounds advanced. Tarkoituksena on osoittaa, että työtä voidaan lähestyä tarkasti, rehellisesti ja riittävän teknisesti, jotta järjestelmää voidaan viedä eteenpäin teeskentelemättä sen olevan yksinkertainen.

Kentän muistiinpanot todellisesta teknisestä katsauksesta

C++-järjestelmätoimituksessa työ muuttuu vakavaksi, kun demo kohtaa todellisen toimituksen, todelliset käyttäjät ja todelliset käyttökustannukset. Se on hetki, jolloin siisti idea alkaa käyttäytyä kuin järjestelmä, ja järjestelmillä on tunnetusti kuiva huumorintaju. He eivät välitä siitä, kuinka tyylikkäältä aloituspakka näytti. He välittävät rajoista, vikatiloista, käyttöönottopoluista ja siitä, voiko kukaan selittää seuraavan vaiheen keksimättä uutta mytologiaa pinon ympärille.

C++ vs Rust for Systems Modernization: Rewrite, Wrap, or Leave It Alone?:n kohdalla käytännön kysymys on, luoko se vahvemman toimituspolun ostajalle, jolla on jo paineita etenemissuunnitelman, alustan tai tietoturvatarkastuksen suhteen. Tuo ostaja ei tarvitse sumuksi kiillotettua luentoa. He tarvitsevat teknisen luennon, jota he voivat käyttää.

Mitä tarkastaisimme ensin

Aloitamme yhdellä edustavalla polulla: natiivi päättely, profilointi, HFT-polut, DEX-järjestelmät ja C++/Rust-modernisointivaihtoehdot. Tuon polun tulee olla tarpeeksi kapea mitatakseen ja riittävän leveä paljastaakseen totuuden. Ensimmäisen läpimenon pitäisi tallentaa allokointikäyttäytyminen, p99-viive, profiilin todisteet, ABI kitka ja vapauttaa luottamus. Jos nämä signaalit eivät ole saatavilla, projekti on edelleen enimmäkseen mielipidettä laboratoriotakissa, ja mielipiteellä on pitkä historia laskuttaa itsensä strategiana.

Ensimmäinen hyödyllinen artefakti on alkuperäisten järjestelmien luku, jossa on vertailuarvoja, profilointitodistusta ja laajennettu toteutussuunnitelma. Sen pitäisi näyttää järjestelmä sellaisena kuin se käyttäytyy, ei niin kuin kaikki toivoivat sen käyttäytyvän suunnittelukokouksessa. Jäljitys, toisto, pieni benchmark, politiikkamatriisi, jäsennyslaite tai toistettava testi kertovat usein tarinan nopeammin kuin toinen abstrakti arkkitehtuurikeskustelu. Hyvät esineet ovat hämmästyttävän töykeitä. Ne keskeyttävät toiveajattelua.

Vastaesimerkki, joka säästää aikaa

Kallis virhe on vastata ratkaisulla, joka on suurempi kuin ensimmäinen hyödyllinen todiste. Tiimi näkee riskin tai viiveen ja tavoittaa välittömästi uuden alustan, uudelleenkirjoituksen, laajan refaktorin tai hankintaystävällisen kojelaudan, jonka nimi kuulostaa siltä kuin se tekee joogaa. Joskus tämä mittakaava on perusteltu. Hyvin usein se on tapa lykätä mittausta.

Parempi liike on pienempi ja terävämpi. Nimeä raja. Ota todisteet talteen. Muuta yksi tärkeä asia. Testaa samaa polkua uudelleen. Päätä sitten, kannattaako seuraava investointi olla suurempi. Tämä rytmi on vähemmän dramaattinen kuin muutosohjelma, mutta sillä on taipumus selviytyä kosketuksista budjetteihin, julkaisukalentereihin ja tuotantotapahtumiin.

Suosittelemamme toimitustapa

Luotettavimmassa mallissa on neljä vaihetta. Kerää ensin edustavia esineitä. Toiseksi, muuta nämä esineet yhdeksi vaikeaksi tekniseksi diagnoosiksi. Kolmanneksi lähetä yksi rajoitettu muutos tai prototyyppi. Neljänneksi, testaa uudelleen samalla mittauskehyksellä ja dokumentoi seuraava päätös selkeällä kielellä. Tässä työluokassa CMake-kalusteet, profilointivaljaat, pienet alkuperäiset reprot ja kääntäjä/ajonaikaiset muistiinpanot ovat yleensä arvokkaampia kuin toinen tapaus yleisestä suunnasta.

Selkeällä kielellä on väliä. Ostajan tulee pystyä lukemaan tulos ja ymmärtämään, mikä muuttui, mikä on edelleen riskialtista, mikä voi odottaa ja mitä seuraava askel ostaisi. Jos suositusta ei voida ajoittaa, testata tai määrittää omistajalle, se on silti liian koristeellinen. Koristeellinen tekninen kirjoittaminen on miellyttävää, mutta tuotantojärjestelmiä ei tunneta miellyttävyyden palkitsemisesta.

Kuinka arvioida, auttoiko tulos

Kohdassa C++ vs Rust for Systems Modernization tuloksen pitäisi parantaa ainakin yhtä kolmesta asiasta: toimitusnopeus, järjestelmän luottamus tai kaupallinen valmius. Jos se ei paranna mitään näistä, tiimi on saattanut oppia jotain, mutta ostaja ei ole vielä saanut hyödyllistä tulosta. Sillä erolla on merkitystä. Oppiminen on jaloa. Myös palkallisen toimeksiannon pitäisi siirtää järjestelmää.

Vahvin tulos voi olla kapeampi tiekartta, kieltäytyminen vaarallisen polun automatisoinnista, parempi raja mallin ympärille, puhtaampi natiiviintegraatio, mitattu todiste siitä, että uudelleenkirjoitusta ei vielä tarvita, tai lyhyt korjauslista, jonka johto voi todella rahoittaa. Vakava suunnittelu on sarja parempia päätöksiä, ei pukukilpailua työkaluista.

Miten SToFU suhtautuisi asiaan

SToFU käsittelee tätä ensin toimitusongelmana ja sitten teknologiaongelmana. Tuomme asiaan liittyvän suunnittelusyvyyden, mutta pitäisimme sitoutumisen ankkuroituna todisteisiin: polkuun, rajaan, riskiin, mittaukseen ja seuraavaan tekemisen arvoiseen muutokseen. Tarkoitus ei ole saada kovaa työtä kuulostamaan helpolta. Tarkoitus on tehdä seuraavasta vakavasta liikkeestä riittävän selkeä suoritettavaksi.

Sitä osaa ostajat yleensä arvostavat eniten. He voivat palkata mielipiteitä missä tahansa. He tarvitsevat tiimin, joka voi tarkastaa järjestelmän, nimetä todellisen rajoitteen, rakentaa tai vahvistaa oikean osion ja jättää taakseen artefakteja, jotka vähentävät sekaannusta puhelun päätyttyä. Meluisillä markkinoilla selkeys ei ole pehmeä taito. Se on infrastruktuuri.