Bir yazılımcının tahmini: Bahçıvan olacağım
Geçen hafta soru şuydu: Yazılım geliştirme gerçekte nedir: bir sanat mı yoksa mühendislik bilimi mi? Benim tezim, yazılım geliştirmenin her ikisinden de biraz içerdiği yönündeydi, ancak çoğu zaman günlük yaşamdaki sanatsal yönü unutuyoruz ve çoğu zaman bu ölçeğin gerçekte nerede durduğumuzu bile bilmiyoruz: Biz sanatçı mıyız yoksa mühendis miyiz?
Duyuru
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Etkinlik ve hizmet odaklı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Bu blog gönderisine yalnızca geliştirici kanalında değil, aynı zamanda YouTube'daki ilgili videonun altında da çok sayıda yorum yapıldı. Özellikle bir yorum dikkatimi çekti: Yazar temelde benim ifademe katılıyordu ancak bir noktayı farklı görüyordu. Sanatın tahmin edilemeyeceğini söyledim ama ona göre her şey tahmin edilebilir: geliştiriciler genellikle emin olmadıklarında veya bilmediklerinde büyük bir rakam vermekten korkarlar.
Uzay mekiğini takdir ediyorum
Bu beni düşündürdü, çünkü emin olmazsam ya da temel bilgiye sahip olmazsam yüksek bir rakam vermeye cesaret edemediğim için tahmin yapamam. Aslında bir tahminde bulunmak mümkün değil. Böyle bir durumda basitçe büyük bir rakam verecek olsam bu bir tahmin değil, sadece bir tahmin olurdu.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Son tahmin: Golo bahçıvan olacak
Bana sıfırdan bir uzay mekiği inşa etmenin kişisel olarak ne kadar zamanımı aldığını sorarsanız, buna nasıl cevap vereceğime dair hiçbir fikrim yok. Büyük bir sayı söyleme cesaretine sahip olmam bana yardımcı olmuyor, çünkü bu, tahminimi daha sağlam kılmıyor: İster beş, ister on, ister yirmi yıl desem, her şey aynı anlama sahiptir, yani pratikte hiçbiri yoktur. İşte bu yüzden bana göre bu bir tahmin değil, söylediğim gibi sadece (zayıf) bir hipotez.
Ancak bu soru beni yalnız bırakmadı ve birkaç gün önce girişimci bir arkadaşım “Yazılım bahçıvanı mısınız?” başlıklı ilginç blog yazıma dikkat çekti. Chris Aitchison tarafından dikkatinize sunuldu. Ana mesajı, biz geliştiricilerin mühendis değil, bahçıvan olduğumuzdur.
Bahçe bakımı gibi yazılım geliştirme
Elbette, bu karşılaştırmayı ilk okuduğumda biraz tuhaf buldum ama blog yazısının çok iyi bir noktası var: Mühendislik projelerinin temelde tahmin edilebilir olduğunu ve bu nedenle bir köprü veya gökdelen tasarlamanın ve hatta inşa etmenin mümkün olduğunu söylüyor. örneğin hava durumu açısından oldukça doğru bir şekilde tahmin edilebilir. Çünkü artık bir köprünün ya da gökdelenin nasıl inşa edildiği biliniyor ve durumdan duruma çok fazla farklılık göstermiyor ve çoğu durumda da ilgili ortamdan bağımsız oluyor. Elbette fiyat farklılıkları var ama bir köprünün ya da gökdelenin inşa edildiği temel prensip aslında aynıdır.
Ancak bir bahçe oluşturmak istiyorsanız işler tamamen farklı görünüyor. Elbette kabaca bir planınız da olur ve hangi ağacı, hangi çalıyı, hangi çiçeği nereye dikeceğinizi vb. söyleyebilirsiniz. Ancak hangi taşın veya desteğin nerede kullanılacağının genellikle önceden kesin olarak bilindiği bir binadan farklı olarak, bir bahçede her bir yaprağı veya her bir çiçeği detaylı olarak tahmin etmek mümkün değildir. Ve eğer deneseydim bu oldukça çılgınca olurdu.
Aslında bugün dikilen bazı nergis soğanlarının gelecek baharda kaç çiçek açacağını tahmin etmenin imkânsız olduğu aşikardır. Hava, iklim, toprak koşulları vb. etkenlere bağlı olarak bir sonraki kışı atlatıp atlatamayacaklarını doğru bir şekilde tahmin etmek dahi mümkün değildir. Elbette deneyimli bir bahçıvan olarak burada belli bir duygu ve deneyime sahipsiniz ama bunu garanti edemezsiniz.
Proaktif bakım
Aynı şey yazılım için de geçerlidir: Yazılım da benzersizdir ve büyük ölçüde çevresine bağlıdır. Dahası, yazılım hiçbir zaman tamamlanmaz, her zaman daha da geliştirilebilir, tıpkı bir bahçenin hiçbir zaman tamamlanamayacağı gibi. Bunun nedeni yalnızca ortamın değişmesidir: donanım değişiyor, temeldeki işletim sistemi değişiyor, kitaplıklar ve API'ler değişiyor vb.
Zaman içinde yazılımımdaki tüm bu değişiklikleri hesaba katmaya devam etmem gerekiyor. Elbette: yazılım kendi başına eskimez, ancak bugün nadiren beş veya on yıl öncekiyle aynı koşullarda çalıştırılıyor. Bunlardan herhangi birinin işe yaraması için proaktif olarak bu konuda bir şeyler yapmanız gerekir.
Deneyimin farkına varın
Elbette, yazılım bahçıvanlarının (yani geliştiricilerin) biraz deneyimi varsa, araçlarını biliyorlarsa ve becerikli yazılım geliştirme konusunda beceriye sahiplerse bu çok daha iyi çalışır. Tıpkı bitkilerin “yeşil başparmağı” olduğu söylendiği gibi, yazılım geliştirme alanında da algoritmalar ve veri yapıları tasarlama konusunda diğerlerinden daha iyi becerilere sahip insanlar var.
Bu yeteneğin ölçülmesi kolay değildir; bunun için özellikle iyi bir ölçüm yok. Ancak deneyimli ve yetkin geliştiriciler, meslektaşlarını duygularına göre çok kısa sürede tanırlar. Başka bir deyişle: Eğer yazılımı kendiniz geliştirmiyorsanız, gerçekten iyi geliştiricileri belirlemek zor olacaktır. Çoğu zaman sonunda içgüdüler karar verir ve ardından kararın feci derecede kötü olmadığına dair umut gelir.
Bu arada, eğer bahçe metaforunu sevmiyorsanız, yemek pişirmek ya da enstrüman çalmak gibi buna benzer başka disiplinler de var. Bu iki örnek de teknolojinin kullanımını gerektiriyor ancak her ikisi de gerçekten iyi olmak istiyorlarsa saf teknolojinin çok ötesine geçiyor. Teknolojiye hakim olmak gerekli ancak yeterli olmayan bir önkoşuldur.
Tahminim mi? Maksimum 1 milyar euro…
Bu nedenle, bu da beni başlangıç noktasına geri getiriyor, bence yazılım geliştirmede tahmin pek mantıklı değil.
Elbette bana Go'da bir veritabanıyla iletişim kuran ve JSON'u döndüren veya alan bazı API yolları sunan bir web sunucusu yazmamın ne kadar süreceğini sorarsanız kabaca cevap verebilirim çünkü bunu birkaç kez yaptım. çoktan. Ancak bu önemsiz örnekte bile büyük etki yaratabilecek belirsizlikler var:
- API'nin kimlik doğrulaması var mı?
- API CORS'u destekleyecek mi?
- API için test stratejisi nedir?
- API belgeleri gerekli mi?
- API sürümü değiştirildi mi ve eğer öyleyse hangi kalıba göre?
- Önbelleğe alma veya proxy'lerle ilgili özel hususlar var mı?
- …
Ancak olası tüm detayları önceden incelemeden tam olarak tahmin edemiyorsam, konu ve içerik açısından daha önce hiç yapmadığım, tamamen yabancı bir alan için efor tahminini nasıl sağlayabilirim? Benim için?
Elbette yorumun orijinal fikrini alıp şunu söyleyebilirim: “Eh, muhtemelen bir milyar avrodan fazlaya mal olmayacak.” Ve büyük olasılıkla bu değerlendirmemde haklı olacağım: Bu hiç kimse için iyi değil.
Bilgiye dayalı bir tahmine giden yol
Sorun bununla ne yapılacağıdır. Bazen şirketler, bir geliştirmenin karlı olup olmadığını ve sonunda buna değip değmeyeceğini değerlendirebilmek için bazı rakamlara sahip olmak isterler. Her ne kadar geliştiriciler olarak bizim bakış açımıza göre anlamlı bir tahminde bulunmak çoğu zaman mümkün olmasa da, bu, tahmin konusunun temelde haklı olmadığı anlamına gelmez. Sadece orada durup “Üzgünüm, bunu takdir edemiyorum” demenin pek bir faydası yoktur ve kimseyi gerçek hedefe yaklaştırmaz.
İşte bu yüzden inanıyorum (ve bu aynı zamanda şirketimde, yerel web'de de kullandığımız prosedürdür): Eğer bir şeyi çok fazla bilinmeyen olduğu için tahmin edemiyorsak, geliştirme projesinin öncesinde, içinde deneyeceğimiz bir araştırma projesi olmalıdır. En önemli sorunları çözmek için. Yani amaç başlangıçta bir “kavram kanıtı”, bir “çığır açan buluş”, bir “prototip” veya buna ne demek istiyorsanız onu geliştirmektir. Bununla birlikte, başlangıçta mesele, daha fazla bilgi edinmek ve makul bir tahminde bulunabilmeniz için sizi daha iyi bir konuma getirecek başlangıç deneyimi kazanmaktır.
Ve bu araştırma değerlenmiyor, ancak bir zaman aralığıyla sınırlandırılıyor. Örneğin, belirli şeylerin nasıl çalıştığını, çalışıp çalışmadığını vb. öğrenmek için dört hafta harcıyorsunuz. Bu dört haftanın maliyeti, harcanan zamana göre faturalandırılabildiği için önceden bilinmektedir. Ve sonra sonuca bakarsınız: Eğer umut vericiyse, ilerlersiniz ve yol boyunca yavaş yavaş güvenilir bir tahmine yaklaşırsınız. Ancak sonuç umut verici değilse, aramaya devam edip etmeyeceğinize ve tekrar bir zaman kutusuna yatırım yapıp yapmayacağınıza veya onu kendi haline bırakmayı tercih edip etmeyeceğinize karar verebilirsiniz.
İş ile el ele
Bana göre bu, sırf bir rakamı söylemek için büyük bir rakamı söylemekten çok daha iyi bir yol. Tabii sonuçta firmanın da üzerine düşeni yapması gerekiyor. Ancak bir tahmine ihtiyacınız varsa, öncelikle sağlam bir tahminde bulunabileceğiniz makul bir temel oluşturmanız gerektiğini belirtmenin iyi bir fikir olduğunu düşünüyorum.
Deneyimlerime göre bunu net bir şekilde açıklayabilirsiniz ve bunu açık ve şeffaf bir şekilde iletirseniz şirket de genellikle bunu takdir eder. Çünkü bu şu anda öyle olduğunu gösteriyor Olumsuz Herhangi bir şey söylemeniz, ancak talebi ciddiye almanız, güvenilir olmanız ve sorunu yapıcı bir şekilde ve her şeyden önce birlikte çözmeye çalışmanız gerekir. Zaten yazılım geliştirmede önemli olan da budur: İlgili herkesin bir araya gelmesi. Öyleyse neden çaba tahminiyle başlamıyorsunuz?
(kendim)