Brzine razvoja
Stanje softverskog razvoja ne prestaje da mi održava pozornost. Imamo pregršt alata i praksi kojih nije bilo pre samo desetak godina, a opet, kao da nismo daleko odmakli.
Ko o čemu, ja o paralelama razvoja nekada i sad - tja, koristim preimućstvo proteklog vremena.
Kada pogledaš, postoji samo jedna tačka (bez povratka) koja daje razvoju smisao: delivery, isporuka softvera. Tek kada se softver pusti u upotrebu, počinje da donosi vrednost i opravdava svoje postojanje.
Ako bi trebalo da izdvojimo jednu metriku koja je potpuno jasna i nepromenljiva, to bi bilo vreme. Brzina razvoja je, dakle, vreme potrebno softveru da dostigne tačku isporuke.
Nazad na moderne alate i prakse. Fokus trendova, kako mi izgleda, je u skraćivanju vremena za razvoj, čime se brzina isporuke povećava. Gde god da pogledaš izviru naznake, primeri, upustva kako da za još kraće vreme napraviš nekakvu funkcionalnu aplikaciju. Klikni malo ovde, prevuci API tamo, ovde kod, onde cvet, sve na dugme i - bam - aplikaciju vidi svet.
Zvuči da gradim naraciju na stranu gde odbacujem nove trendove, upirući prstom u svetle primere prošlosti, kudeći budućnost (dakle: sadašnjost) za koju smo se, jelte, borili. Iako nema neistine u izrečenom, nezrelo - i, donekle, prozaično - bi bilo tako lako odbaciti napredovanja softverske industrije (šta god to značilo).
Moderni alati i prakse, dakle, donose napredak. Zašto onda nisam u mirom s stanjem stvari? Zašto imam osećaj da se unatoč tome softver ne razvija toliko brzo koliko je obećano?
Dve vektora
Reč je o tome da postoje dve komponente brzine razvoja.
Razvoj novih funkcionalnosti je prva takva brzina razvoja. Upravo tu moderni alati i prakse dolaze do izražaja. Vreme potrebno da se od praznog ekrana dođe do aplikacije nikada nije bilo kraće. Isto važi i za projekte koji su u toku - dodavanje novih funkcionalnosti traje kraće usled postojanja biblioteka, specifikacija, protokola, moćnijih procesora, jeftinijeg hardvera… Biću slobodan da kažem da bujica JavaScript razvoja potiče upravo iz ovog ubrzavanja: odjednom postaje lako napisati JS kod koji će se izvršiti svuda.
Dolazim, konačno, do zapleta. Druga komponenta razvoja je brzina razvoja promene (ispravke, dopune, tehnički dug). Nažalost, ona ne napreduje; i to je ono našta mi osećaj ukazuje (i brine). Štaviše, čini se da upravo benefiti brzog razvoja novih funkcionalnosti štete brzini razvoja promena! Odnos količine potrebnih promena i novih funkcionalnosti takođe nije blagonaklonjen rezultujućem vektoru brzine razvoja.
Ishod, međutim, nije samo prosta kompozicija vektora. Efekat stanja modernih alata i praksi se očitava pogrešnim očekivanjima. Usled obraćanja pažnje na samo bržu komponentu razvoja, menadžment, pa i svi mi ostali, stičemo očekivanja da je razvoj softvera značajno… jednostavniji nego što to zapravo jeste. Jasno je dalje odmotavanje priče: zahteva se više za kraće vreme.
Današnje metodologije upravo i adresiraju promenu kao ključno svojstvo modernog razvoja. Ipak, ne vidim da se očekivanja menjaju. Umesto da samo ukazujemo da je promena sastavni deo razvoja, čini mi se da bi trebalo da se okrenemo razumevanju svojstva kapaciteta promene. Ovaj koncept prevazilazi samo softverski razvoj; što više razmišljam o njemu nalazim da je ide pod ruku sa sveopštom silom entropije - razuđivanja - koja je ništa drugo do neprestana promena. Naš kapacitet da reagujemo na promene, bilo u softverskom razvoju ili drugim nivoima postojanja, jeste mesto kojem treba posvetiti pažnju i razumevanje.
Razvoja softvera je daleko složeniji proces nego što to želimo da prihvatimo.