Uygulamalar ve web siteleri geliştiren küçük Hintli yazılım şirketlerinde artan teknik borç: Bundan kim sorumlu?

10 yıldır Hindistan yazılım hizmetleri sektöründeyim ve tüm bu süre boyunca iyi projelerin tamamlandığını ve harikalar yarattığını gördüm. İskelet ekiplerinin, gezegenin yarısında insanlar tarafından sevilen ürünler oluşturmak için acı veren koşullarda yorulmadan çalıştığını gördüm. Ve bu on yılda harika projeler üzerinde çalışırken harika anılarım olsa da, projelerin yokuş aşağı gittiğine ve yazılım ürünlerinin çeşitli nedenlerden dolayı berbat hale geldiğine de tanık oldum. Bu 10 yıl boyunca çevremde ve tanıdığım insanların etrafında olmasını dilediğimden daha fazla oldu.

Yanlış giden projeler hakkında çok şey konuşuldu. Tüm hiyerarşinin ormanlardaki bir besin zinciri gibi birbirini nasıl kovaladığına dair memler interneti sarıyor. Bazı insanlar programcıları buggy kodu yazmakla suçlarken, diğerleri yerine getirilmesi imkansız olan pratik olmayan sözler vermek için yönetimi lanetliyor. Hatta bazı kişiler, bu endüstrinin teknik önkoşullarını ve bağımlılıklarını anlamadıkları için müşterileri suçluyor. Ama neredeyse hiç kimsenin Teknik Borç veya Kod Borç hakkında konuştuğunu ve bu meseleyi medeni bir şekilde, parmakla göstermeden ele almadığını duydum. Çevremdeki insanlardan, katıldığım etkinliklerden veya okuduğum yerel bloglardan bu Tech Debt terimine bir kez bile rastlamadım.

Bu terimle ancak Amerika Birleşik Devletleri'ndeki Silikon Vadisi'ndeki blogları ve dergileri okuduğumda tanıştım. Bu, Hindistan'daki küçük ve orta ölçekli yazılım geliştirme şirketlerinde çalışan çoğu programcı ve yazılım yöneticisinin şimdiye kadar bu terimi daha önce duymadığı anlamına gelir. Öyleyse, terimin kendisini açıklayarak başlayayım. Teknik Borç veya Kod Borç, yazılım geliştirmede, daha uzun sürecek daha iyi bir yaklaşım kullanmak yerine şimdi kolay (sınırlı) bir çözüm seçmenin neden olduğu ek yeniden çalışmanın zımni maliyetini yansıtan bir kavramdır.

Basitleştirmek için parçalayayım. Belirli bir modülü veya tüm sistemi oluşturmanın en iyi ve en verimli yöntemini seçmek yerine, kolay bir seçenek seçmekten kaynaklanabilecek programlama ve tasarım sorunlarını çözme maliyetini hesaplamak için kullanılan bir kavramdır. Yazılım geliştirme alanında, tembelliğinizin ve geç kalmanızın sizi kıçından ısırmak için geri gelmesi olgusu, başka herhangi bir yerden çok daha sık gerçekleşir. Neredeyse Karma, programcılar tarafından sürtük olmanın sosyal bir temsilini almış gibi.

Lütfen beni yanlış anlamayın, tüm kod borçlarını programcılara yüklemiyorum. Hindistan'daki küçük ölçekli yazılım geliştirme şirketlerindeki projelerin %90'ından fazlasında kesinlikle ortaya çıkan kod borcundan kesinlikle birden fazla varlık sorumlu. Birkaç tanesine kısaca değinmeye çalışayım:

1. HIZLI VE AŞIRI AKILLI MÜŞTERİLER

Evet, besleyen ve bunu acımasızca yapan eli ısırarak başlayacağım. Küçük ölçekli dış kaynaklı yazılım geliştirme projeleri pazarı çok büyük ve oldukça parçalıdır. Bu küreselleşmiş piyasayı mükemmel bir şekilde haklı çıkaran gerçekten iyi şirketler varken, diğerleri sadece bu mükemmel düzenlemeden sadece düzensiz ve kontrolsüz olduğu için beslenen parazit şirketlerdir.

Bu, müşterilerin ihtiyaçlarına göre ortak olacak doğru şirketi seçme konusunda hata yapmalarına neden olur. Doğru inceleme becerilerine sahip olmamak onların suçu olmasa da, bir çöp şirketini gerçek bir şirketten ayırt etme konusunda temel sokak zekasına sahip olmamaları için suçlanacak kimse yok. Şimdi, yetersiz yetenekli bir ekiple devam etmeyi kabul ettiklerinde, gerçekçi olmayan beklentilerini ve zaman çizelgelerini boğuyorlar. Sadece bu da değil, bazıları aşırıya kaçıyor ve tasarım ve programlamada kendi önerilerini getirerek ne kadar akıllı olduklarını gösteriyorlar. (#notallclients )

Eğer bir yazılım geliştirme şirketinin müşterisiyseniz, onları kendi haline bırakmanızı ve işlerini yapmalarına izin vermenizi alçakgönüllülükle rica ediyorum. Bir doktora veya avukata gitmeyi deneyin ve onlara google'da ne arattığınızı ve sorununuz hakkında ne dediğini söyleyin ve yüzlerindeki tepkiyi görün. Kendi alanında hiçbir uzman, bir çaylak tarafından kendi alanı hakkında tavsiye almaktan hoşlanmaz. Yazılım mühendisleri istisna değildir.

İyi bir yazılım geliştirme ekibi bulursanız ve umut verici görünüyorlarsa, onlara alanlarını verin ve köşeleri kesme dürtüsü hissetmeyecekler, bu da projenizde daha az kod borcu ile sonuçlanacaktır. Ve bilin bakalım, çoğu zaman siz çocuklar, bu kod borcunu ödeyen müşteriler. “Değişiklik Talebi” sözlerini hiç duydunuz mu? Bahse girerim çoğunuzda vardır! İdeal bir senaryoda, hayatınızda bu kelimeleri asla duymamalısınız. Ama bu nadiren olur. Ve bu sözleri en çok duyduğunuzda, bir yazılım şirketinin müşterisi olmayı o kadar batırırsınız.

2. TEMBEL & SAHİP YÖNETİCİLER

Burada yöneticiler dediğimde, yazılım geliştirme şirketi tarafından proje yönetimi pozisyonunda olan herkes. İster proje yöneticisi, ister ekip lideri, ister teslimat müdürü veya şirket sahibi olun, bir projeyi bitirmek ve ödemenizi almak için ellerinizi çabucak yıkamaya çalıştıysanız, bir tarafsınız. projelerinizdeki bu miktardaki Teknoloji Borçlarında da suçlamak.

Buradaki en üzücü kısım, sizin asla teknolojik borcu ödemeyeceksiniz. Ya müşteri, standartların altında bir ürün kullanarak ya da aslında onu temizlemek için daha fazla para ödeyerek parasını ödüyor. Ve eğer müşteri değilse, yapmaları gerekenin çok ötesinde sonsuz saatlerce çalışmak zorunda kalarak bunun bedelini ödeyen zavallı programcılardır. Ama neredeyse hiçbir zaman bu orta adamlar değil, bu yüzden bana göre, bu teknoloji borcu konusunda en sorumlu kişiler olmalılar.

Onlardan birini işe alacaksanız, sahip olmaları gereken en büyük kalite ahlaktır. Ahlaki pusulaları doğru yönü gösteriyorsa, sorumluluk alacaklar ve proje lehine doğru kararı alacaklar ve bu da sonunda daha az teknoloji borcunun derlenmesine yol açacaktır. Bu bana Jack Ma'nın doğru lider için çalışmayı seçmekten bahsettiği ünlü sözünü hatırlattı. Burada bu senaryoda çok uygun.

3. PROGRAMCILAR

Ah evet, sizi de suçlayarak bu konuyu bitirmem! Ama hey, #notallprogrammers değil mi? Evet, ama programcıların neredeyse %94'ü. En azından Tech Mahindra'nın CEO'su CP Gurani, birkaç yıl önce BT mezunlarının %94'ünün bu iş için uygun olmadığı yönündeki şok edici açıklamayı yaptığında böyle düşünüyor. Bu rakama nasıl ulaştığını tam olarak bilmiyorum ama Hindistan mühendislik kolejlerinin bir ürünü olarak ve son 10 yıldır tüm bilişim mühendisliği ekosistemine tanık olduğum için Sayın Gurani'nin belirttiğine katılma eğiliminde olduğumu söyleyebilirim.

%94 mü, %90 mı yoksa %80 mi olduğunu tartışmaya çalışmıyorum. Ama size bir benzetme yapmak gerekirse, neredeyse hepimiz biliyoruz ki hamur yapmak için una, suya ve bir tutam tuza ve chapatis'i yapmak için bir oklavaya ihtiyacımız var. Ancak çok azımız gerçekten yenilebilir chapatis yapabilir. Bu çok basit bir süreçtir, ancak yine de başarılı olmak için biraz yetenek ve tonlarca pratik gerektirir. Programlamada da durum aynıdır. Tarifi hepimiz biliyoruz, ancak çok azı kollarımızı sıvadı ve ellerimizi kirletti ve bu zanaatta ustalaşmak için gereken sürece uyguladı.

Bu nedenle, ortalama bir programcı bir projede görevlendirilse bile, bilmeden, içine gömülü teknoloji borcu olan ve daha sonra farkına varmayacağı kod yazardı. Ve endüstrinin genel olarak nasıl olumlu bir şekilde işlediğini merak ediyorsanız, programcıların çoğu iş için uygun değil, bunun nedeni onların verimli yöneticileri ve işleri zor yoldan öğrenen deneyimli kıdemlileri. Bu taze ellere ve zihinlere, optimal kod yazmanın tehlikeli yollarında gezinmede yardımcı oluyorlar ve projenin sevkiyatını mümkün kılıyor ve onu ağır bir borçtan kurtarıyorlar. Ve sonunda, bu acemileri işlerinde iyi olmaları için uygun şekilde tımar ve eğitimle ya da BT endüstrisine veda etmeye başlarlar.

Sonuç olarak, bu işbirliğindeki 3 büyük tarafın hepsinin kod borcunu derleme suçunu paylaşacağını hissediyorum. Yine, bu parçayı endüstride yanlış olan her şey için bir aşağı parça olarak almayın. Korku ve kahramanların adil payıyla dünyadaki diğer herhangi bir endüstri gibi. Bunu yaptıktan 10 yıl sonra bile, hala hayatımda başka bir şey yapmazdım. Bu işi seviyorum, dünyanın dört bir yanındaki müşterilerden gelen heyecan verici projeler üzerinde çalışan küçük bir şirket olmayı seviyorum.

Amaç, tüm 3 paydaşı daha hesap verebilir kılmak ve yanlış işbirliği nedeniyle üzerlerine vurulan bu temel yumuşak kayıp hakkında onları bilgilendirmekti. Bir yazılım geliştirme ekibi, teknik borcunu doğru bir şekilde hesaplamak ve ölçmek isterse, Çevik metodolojiye ve hatta Şelale metodolojisine dayanan katı bir süreç modelini takip edebilir. Bu disiplinli yaklaşımı takip ettiğinizde, bu revizyon & onarım sprintlerini ayrı ayrı işaretleyebilecek ve bir aşamanın sonunda kaç tanesine ihtiyacınız olduğunu tam olarak hesaplayabilecek ve kolayca en alt seviyeye inebileceksiniz. bunun nedeni.

Bunu Samuel Beckett'in şu son alıntısıyla bitireceğim: