Industria dezvoltării de software se schimbă — permanent

În 2003 am fondat DCSL Software, care ulterior a devenit One Beyond. Am ieșit în 2023 după ce am dus compania la nivel internațional și am crescut-o la peste 300 de persoane. De atunci, am fondat un start-up de robotică și am strâns peste 4 milioane de lire sterline în finanțare de seed.  

Nu m-am așteptat niciodată să scriu din nou software de producție. Am încetat să mai scriu cod zilnic în 2014, nu pentru că nu puteam să o fac, ci pentru că asta se întâmplă când o companie crește. Angajezi oameni care sunt mai buni decât tine la execuție, te concentrezi pe leadership și treptat tastatura se îndepărtează. Timp de aproape un deceniu, acest lucru mi s-a părut complet natural.  

La ce nu m-am așteptat a fost că, aproape zece ani mai târziu, mă voi regăsi înapoi în scaunul dezvoltatorului — nu nostalgic, ci practic. Nu experimentând, ci construind o platformă de robotică cu adevărat complexă. Și nu prin a reinvăța fiecare framework sau limbaj care m-a depășit, ci lucrând într-un mod fundamental diferit.  

Această schimbare personală este cel mai clar semnal pe care l-am văzut că ceva structural s-a schimbat în dezvoltarea software.  

Cum proiectam software-ul înainte — și de ce  

Când am început, eram ferm în era waterfall. Acesta nu era o ideologie, era economie. Software-ul era lent și scump de construit, așa că singura abordare sensibilă era să gândești foarte atent din start.  

Scriam specificații detaliate pentru că trebuia. Contractele dependeau de ele. Livrarea depindea de ele. Scrierea unei specificații bune era o abilitate de specialist, și una la care se întâmpla să fiu destul de bun. Puteam vizualiza cum ar putea arăta produsul finit înainte să existe, să prevăd zonele de complexitate și să descriu comportamentul cu suficientă precizie încât o echipă să poată construi pe baza lui.  

Această abilitate era rară și dificil de predat. Mulți oameni se confruntau cu ea pentru că imaginarea unui sistem complex care nu există încă este cu adevărat dificilă. Dar conta, pentru că a greși târziu în proces era dureros și costisitor.  

Cu timpul, industria s-a îndreptat către Agile. Public, aceasta a fost prezentată ca o modalitate mai bună de a răspunde la schimbare. În tăcere, a fost și o recunoaștere că pentru sistemele mari, de lungă durată, nicio specificație nu supraviețuiește intactă. Afacerile se schimbă, utilizatorii se schimbă, tehnologia se schimbă, iar a pretinde altfel adesea cauzează mai mult rău decât bine.  

Agile era pragmatic, dar a venit cu un cost. Am abandonat în mare parte design-ul profund inițial și l-am înlocuit cu descoperire incrementală. Aceasta a funcționat, dar a și normalizat o mentalitate în care a gândi prea departe înainte era văzut ca inutil sau chiar riscant.  

Ce s-a schimbat — și de ce am început să construiesc din nou  

Motivul pentru care am putut să revin la dezvoltare hands-on nu este că am găsit brusc timpul sau dorința de a reinvăța o decadă de instrumente. Este pentru că AI a schimbat fundamental costul experimentării.  

Aceasta este partea care este adesea înțeleasă greșit. Adevărata schimbare nu este că codul este mai rapid de scris. Este că încercarea lucrurilor este acum ieftină, rapidă și în mare parte reversibilă.  

Lucruri care ar fi necesitat cândva săptămâni de dezvoltator pot fi acum încercate în minute. Poți explora o abordare, să vezi cum se simte, să o arunci complet și să încerci o direcție diferită cu foarte puțină penalizare. Pur și simplu nu era posibil înainte.  

În trecut, exista un atașament emoțional și financiar puternic față de cod. Dacă ceva a luat doi dezvoltatori trei săptămâni să construiască, erai în mod înțeles reticent să-l arunci. Deciziile se întăreau devreme, nu întotdeauna pentru că erau corecte, ci pentru că inversarea lor era prea costisitoare.  

Acea constrângere a dispărut și acesta este ceea ce m-a atras înapoi. Acum pot opera la nivelul la care sunt cel mai puternic — înțelegerea problemei, modelarea sistemului, observarea când complexitatea se insinuează — în timp ce AI se ocupă de mecanică. Nu scriu cod în modul în care o făceam la douăzeci de ani. Îl dirijez, îl rafinez, îl corectez și ocazional îl opresc să meargă într-o direcție complet greșită. În practică, acest lucru se simte mult mai aproape de conducerea unei echipe decât de scrierea de cod. Ești efectiv șeful — stabilești direcția, revizuiești rezultatul, observi scurtăturile leneșe și rezisti când ceva nu se simte bine. 

De ce design-ul încă contează — mai mult ca niciodată   

Ar fi ușor să presupui că această nouă libertate face design-ul mai puțin important. În realitate, îl face mai important.   

A avea o idee clară și detaliată despre ceea ce încerci să construiești este încă extrem de valoroasă. De fapt, îmbunătățește activ rezultatul AI. Cu cât intenția este mai clară, cu atât rezultatele sunt mai bune. Gândirea vagă produce pur și simplu sisteme vagi mai rapid.  Ce este important de înțeles este că AI se comportă foarte asemănător cu o persoană. Vrea să fie de ajutor. Vrea să-ți dea un răspuns. Dacă ești vag, va umple golurile. Dacă ești neglijent, va face presupuneri. Dacă nu îl provoci, va continua cu încredere pe calea greșită.  

Diferența este că design-ul nu mai este un artefact fragil, de unică folosință, care trebuie să supraviețuiască neschimbat ani de zile. A devenit un ghid pentru experimentare mai degrabă decât o constrângere asupra ei. Poți păstra o viziune puternică asupra direcției în care te îndrepți în timp ce ești încă dispus să încerci, să arunci și să evoluezi calea care te duce acolo.   

Noua abilitate este să știi când explorarea este productivă și când este doar zgomot. AI va continua cu plăcere să genereze structură mult după ce ar fi trebuit simplificată. Nu știe când un fișier a crescut prea mult, când o abstracție scapă sau când ceva care "funcționează" astăzi va cauza durere mai târziu. Acele instincte provin încă din experiență.  

Ce strică aceasta în industrie  

Odată ce experimentarea devine ieftină, multe presupuneri de lungă durată încetează să mai țină. Planificarea nu mai este despre blocarea a tot ce e posibil în avans. Este despre stabilirea intenției, constrângerilor și limitelor.  

Estimarea devine mai puțin despre prezicerea efortului și mai mult despre înțelegerea spațiului pe care îl explorezi.  

Și relația noastră cu codul se schimbă complet. Există mult mai puțin atașament față de implementări specifice și mult mai mult focus pe comportament, structură și rezultate.  

Acesta este motivul pentru care industria de dezvoltare software se simte neliniștită. Mulți oameni încearcă să aplice modele mentale vechi unor instrumente noi. Aceasta funcționează pentru o vreme, dar ratează esența.  

Adevărata schimbare  

Motivul pentru care sunt încrezător că această schimbare este permanentă este simplu: nu aș construi din nou altfel.  

Singurul motiv pentru care pot reveni în mod credibil la dezvoltarea hands-on după un deceniu de absență este că constrângerile care m-au împins afară în primul rând nu se mai aplică. Software-ul poate acum evolua prin experimentare ghidată într-un mod care pur și simplu nu era posibil înainte.  

Aceasta nu înseamnă că experiența contează mai puțin. Înseamnă că contează diferit. Valoarea nu mai este în memorarea sintaxei sau a framework-urilor. Este în judecată, structură și în a ști când să te oprești.  

Acesta nu este sfârșitul dezvoltării software. Dar este sfârșitul modelului vechi. Și odată ce ai lucrat în acest mod, nu există cale de întoarcere.