A programozók idejük kétharmadát nem kódolással töltik

A Harness vezérigazgatója és társalapítója, Jyoti Bansal szerint "a fejlesztők idejük 60-70 százalékát nem a kódolással töltik". Mindazok a dolgok, "amelyek a kódolás után történnek, mint a tesztelés, a telepítés, a biztonság, az irányítás, a megfelelés", a fejlesztői munka rovására mennek. Bansal szerint a vállalatok "modernizálni akarják a szoftverfejlesztés módját: a felhőbe költöznek, fejlesztik az infrastruktúrát, átdolgozzák az alkalmazást, hogy az agilis és alakítható legyen, mikroszolgáltatásokat, Kubernetet és konténereket vezetnek be", de a rossz fejlesztői hagyomány így is alacsony termelékenységet eredményez.

A Harness által készített, fejlesztői tapasztalatokról szóló felmérés arra a következtetésre jutott, hogy a szervezetek 60 százaléka havonta vagy negyedévente ad ki kódot, ahelyett, hogy a hatékony DevOps rendszerhez kapcsolódó gyakori frissítésekkel foglalkozna. Ennek egyik oka az, hogy a kódellenőrzések időigényesek: a felmérés szerint a fejlesztők 67 százalékának több mint egy hétig tart, amíg elvégzik azokat. További problémák közé tartozik a manuális visszaállítás sikertelen telepítés esetén (szintén 67 százalék); a megkérdezett fejlesztők 32 százaléka szerint elégtelen az egységtesztelés, valamint a biztonsági követelmények, amelyeket 59 százalék említett a telepítés késedelmének okaként.

Jyoti Bansal 2017-ben alapította a Harnesst, egy szoftverfejlesztők számára készített platformot azzal a céllal, hogy a megfelelő eszközökkel javítsa a fejlesztők termelékenységét. Gyakran hallani azonban, hogy a termelékenység legnagyobb akadálya a szervezeti kultúra, nem pedig az eszközök, és a vezetők dolga azon feltételek megteremtése, hogy mindenki jól végezze a munkáját. Bansal ezzel nem ért egyet. "Az én álláspontom az, hogy az eszközök a kultúra megváltoztatásának hajtóerei. Megkérheted a csapatokat, hogy naponta egyszer publikáljanak, de addig lehetetlen a kulturális változást elérni, amíg nem mutatod meg nekik, hogy a segédeszközök mire képesek. Azok a szervezetek, amelyek a kultúraváltás motorjai, azt teszik, hogy új eszköztárat, új folyamatokat vezetnek be a szervezet valamelyik részébe. Ha 5000 fejlesztőd van, akkor nem tudod mindannyiukat azonnal megváltoztatni. Tehát néhány csapattal és néhány alkalmazással kezdesz, és ez a 100 vagy 300 fejlesztő, akik új eszközkészletet, új folyamatokat használnak, azokat a kultúraváltás motorjaként mutatják be a többi 4500 mérnök számára."


Jyoti Bansal 3,7 milliárd dollárért adta el a Cisco-nak AppDynamics nevű cégét
Bansal szerint hiba, hogy még mindig sok szervezet ragaszkodik a lassú szoftverkészítési folyamatokhoz, amikor a rövid ciklusú fejlesztés (continuous delivery, CD) értéke már évek óta ismert. "Az eszközök nem tartottak lépést" - mondta Bansal. "Az iparág 80 százaléka még mindig a Jenkins-t használja, pedig az már körülbelül 20 éve készült. Az emberek azt csinálták, hogy fogták a Jenkins-t, és egy csomó szkriptet mókoltak rá. Az iparág kinőtte a Jenkins-t és a házilag fejlesztett eszközöket és szkripteket, és szinte mindenki szenved emiatt". Bansal megjegyzései a Harness kontextusában hangzottak el, amely egy szoftverkiszállítási platform, így mondatai nem mentesek az önPR-tól.

Bansal nem tartja erős versenytársnak az AWS, a GitHub, az Azure, vagy a Google Cloud Platformokat, amelyek mind saját CI/CD-eszközöket kínálnak. "A felhőcégeknek mindig van eszköztáruk mindenre" - mondta Bansal. "A Harness termékei jelentősen felülmúlják azt, amit a hiperskalálók nyújtani tudnak. Erősen koncentrálunk erre" - mondta. "Ha van egy kis alkalmazásod vagy egy kis környezeted, akkor jók lehetnek neked azok [a hiperskalálók], de általában nem tekintjük őket konkurenciának. Az iparág nagy része arra törekszik, hogy a mérnöki gyakorlatát és az eszközláncát úgy alakítsa ki, hogy az több felhőszolgáltatónál is használható legyen" - mondta.

Bansal szerint a mesterséges intelligenciának is van szerepe. "Egy telepítés sokféle okból meghiúsulhat. A fejlesztőnek meg kell néznie a naplókat, és ki kell találnia, mi történt. Mi könnyen segíthetünk összegezni az egészet, és egyszerű angolsággal közölni, hogy mi az ami nem sikerült, és hogyan lehet kijavítani"." A mesterséges intelligencia azonban hibázhat - a kódgenerálásban és máshol is. Ennek az a következménye, hogy az MI által megtakarított időt az "ellenőrzés következő generációjába kell fektetni" - mondta Bansal. "Az MI világában a minőségbiztosítás szerepe még fontosabbá válhat, mint a fejlesztőé. Az MI megírhatja a kódot, de egy embernek kell validálnia és ellenőrizni, hogy az működik-e."