Bir yazılım geliştiricisi için takdir: Bahçıvan oldum
Geçen hafta yazılım gelişiminin ne olduğu sorusu muydu: sanat mı yoksa daha çok bir mühendislik bilimi mi? Tezim, yazılımın gelişiminin her ikisinden de bir şeye sahip olduğu, ancak çoğu zaman günlük yaşamdaki sanatsal yönü unuttuğumuzdu ve çoğu zaman aslında bu ölçekte nerede olduğumuzu bile net değiliz: biz sanatçılar veya mühendisler miyiz?
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Bu blog yazısında sadece geliştirici kanalında değil, aynı zamanda YouTube'da ilişkili video altında da çok sayıda yorum yapıldı. Özellikle bir yorum fark ettim: Yazar beyanımı büyük ölçüde kabul etti, ancak farklı bir nokta gördüm. Sanatın değerli olmadığını söyledim, ancak görüşüne göre her şey tahmin edilebilir: Geliştiriciler, belirsizlik veya cehalet durumunda çok sayıda vermekten çok korkuyorlardı.
Uzay mekiğini takdir ediyorum
Bu beni düşündürdü, çünkü eğer emin değilsem veya temel bilgi eksikliği varsa, o zaman tahmin edemem çünkü bana çok sayıda vermeye cesaret edemiyorum. Aksine, takdir imkansızdır. Eğer böyle bir durumda çok sayıda vermiş olsaydım, değerlendirilmezdi, ama benim için öneriliyor.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Son Tahmin: Golo bahçıvan olur
Bana ne kadar süredir sıfırdan bir uzay mekiği inşa etmem gerektiğini sorarsanız, kesinlikle ne cevaplayacağımı bilmiyorum. Çok sayıda ifade etme cesareti bana yardımcı olmaz, çünkü bu tahmini daha sağlam hale getirmez: Beş, on veya yirmi yıl dersem – her şey aynı anlamı, yani neredeyse hiç kimse vardır. İşte bu yüzden bence bir saygı değil, dediğim gibi sadece (kötü).
Ancak, bu soru gitmeme izin vermedi ve arkadaşınızın bir arkadaşı beni birkaç gün önce çok heyecan verici blog yazısında “Yazılım bahçıvan mısınız?” Chris Aitchison'un bilincinde oldu. Onun kilit mesajı, geliştiriciler olarak mühendis değil, çok daha fazla bahçıvan olduğumuzdur.
Bahçe bakımı olarak yazılım geliştirme
Bu karşılaştırmayı ilk kez okuduğumda, biraz garip buldum, ancak blog yazısı mükemmel bir noktaya geliyor: Mühendislik projelerinin esasen tahmin edilebilir olduğunu ve bu nedenle bir köprü veya gökdelen planlamasını ve inşasını tahmin etmenin mümkün olduğunu söylüyor. Çünkü bir köprü veya gökdelen nasıl inşa edileceği artık yeterince biliniyor ve bir uygulamadan uygulamaya çok fazla farklılık göstermiyor ve çoğu durumda ilgili ortamdan da bağımsız. Tabii ki fiyatta farklılıklar var, ancak bir köprü veya gökdelenin her zaman nasıl inşa edildiğinin temel prensibi her zaman aynıdır.
Ancak, bir bahçe yaratmak istiyorsanız çok farklı görünüyor. Açıkçası da yaklaşık bir planınız olacak ve hangi çalı, o çalıların, çiçeklerin vb. Nerede dikilmesi gerektiğini söyleyebilirsiniz. Ancak, genellikle taşın nerede kullanılacağı veya hangi taşıyıcının kullanılacağı önceden bilinen bir binanın aksine, her bir tabakayı veya her bir çiçeği bir bahçeye ayrıntılı olarak dahil etmek mümkün değildir. Ve eğer denerseniz de oldukça abartıydı.
Aslında, önümüzdeki baharın bugün bazı narciso soğanları ekileceği tahmin edilemez olduğu açık olmalıdır. Zamana, iklime, toprak kalitesi vb. Tabii ki, uzman bir bahçıvan olarak, burada belli bir his ve belirli bir deneyime sahipsiniz, ancak 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 çevreye bağlıdır. Buna ek olarak, yazılım asla bitmez, ancak tıpkı bir bahçede asla hazır olmayacağınız gibi, üzerinde bir şeyler geliştirilebilir. Bunun nedeni, çevredeki ortamın değişmesidir: donanım değişir, aşağıdaki işletim sistemi değişiklikler, kitapçılar ve arılar değişir vb.
Tüm bu değişikliği zamanla yazılımımla düşünmeliyim. Açık: Yazılım kendi başına yaşlanmaz, ancak bugün beş veya on yıl önce aynı koşullarda nadiren gerçekleştirilir. Bunun çalışması için proaktif olarak bunun için bir şeyler yapmanız gerekir.
Deneyimi tanıyın
Tabii ki, yazılım bahçıvanları (yani geliştiriciler) belirli bir deneyime sahipse, araçlarını biliyorlarsa ve akıllı yazılımın geliştirilmesi için bir yeteneğe sahipse bu çok daha iyi çalışır. Tıpkı birisinin “yeşil başparmak” olduğu bitkilerden bahsederken, yazılımın geliştirilmesinde algoritmalar ve veri yapılarının tasarımında diğerlerine kıyasla daha iyi bir yeteneğe sahip insanlar da var.
Bu yetenek iyi ölçülemez, bunun için özellikle uygun bir metrik yoktur. Ancak uzman ve vasıflı geliştiriciler, türlerini kısa sürede duyuruyorlar. Başka bir deyişle, tek başına yazılım geliştirmezseniz, gerçekten iyi geliştiricileri tanımlamakta zorlanacaksınız. Genellikle bağırsak hissi bu nedenle karar verir ve ardından kararın katastrofik olmadığı umudu gelir.
Bu arada, bahçeyle bahçeden hoşlanmıyorsanız, bir enstrüman yemek veya çalma gibi karşılaştırılabilir disiplinler de vardır. Bu iki örnek aynı zamanda teknolojinin kullanılmasını gerektirir, ancak her ikisi de gerçekten iyi ise, saf teknolojinin çok ötesine geçin. Bu nedenle teknolojinin ustalığı gerekli ancak yeterli olmayan bir ön koşuldur.
Benim saygım? Maksimum 1 milyar Euro …
Bu nedenle, ve bununla orijinal noktaya geri dönüyorum, bence yazılımın gelişimini takdir etmek zor değil.
Tabii ki, bana bir veritabanı ile iletişim kuran ve JSON'u geri döndüren veya kabul eden bazı arılar yolları sunan bir web yazmam gerektiğini sorarsanız, buna cevap verebilirim çünkü birkaç kez yaptım. Ama aynı zamanda bu banal örnekle, büyük bir etkiye sahip olabilecek belirsizlikler vardır:
- API'nin kimlik doğrulaması var mı?
- API CORS destekleyecek mi?
- Test stratejisinin API için ne var?
- API için bir belgesel mi?
- API sürümdür ve bu durumda hangi şemaya göre?
- Önbellek veya proxy'nin dikkate alınması gereken özel özellikler var mı?
- …
Ama önce tüm olası ayrıntıları önceden tartışmadan tahmin edemezsem, teknisyen ve içerik açısından hiç yapmadığım bir şeye nasıl saygı göstermeliyim, ki bu benim için tamamen bilinmeyen bir zemin?
Tabii ki, bu nedenle orijinal notu yorumdan alıp şöyle diyebilirim: “Şey, bu yüzden bir milyar avroya mal olmayacak”. Ve büyük olasılıkla bu değerlendirmede bile bir nedenim olacak – sadece kimse için yararlı değil.
-Profonde'da bir tahminin yolu
Soru ne yaptığın. Çünkü bazen şirket, bir gelişmenin zaten kârlı olup olmadığını tahmin etmek için ödeme yapmak ister ve sonunda çabanın buna değer olması muhtemeldir. Ve bir geliştirici olarak, makul bir tahmin sunmak genellikle mümkün olmasa bile, bu, tahmin sorununun temelde haklı olmayacağı anlamına gelmez. Kendinizi indirin ve “Üzgünüm, bunu takdir edemem” deyin.
Bu benim (ve bu aynı zamanda şirketimde yerel web'de kullandığımız prosedür) nedeni budur: çok fazla bilinmeyen insan olduğu için bir şeyi takdir edemezsek, geliştirme projesinden önce en önemli sorunları çözmeye çalıştığımız bir araştırma projesi olmalıdır. Dolayısıyla, bir “kavramın testi”, “itme”, bir “prototip” veya her şey ne demek istediğinizi geliştiren ilk amaç. Bununla birlikte, başlangıçta, sizi makul bir tahmin için daha iyi bir başlangıç noktasına getirmek için sadece daha fazla bilgi edinme ve ilk deneyimler edinme meselesidir.
Ve bu araştırma değerlendirilmiyor, ancak utangaç bir kutu ile sınırlı. Örneğin, belirli şeylerin nasıl çalıştığını, kimin çalıştığını ve benzerlerini öğrenmek için dört hafta ayırın. Bu dört haftanın maliyeti önceden bilinir, çünkü zamana göre faturalandırılabilirler. Ve sonra sonuca bakın: eğer umut verici ise, devam edin ve yolda güvenilir bir tahmine yaklaşın. Ancak, sonuç umut verici değilse, aramaya devam etmek ve bir kutuya tekrar yatırım yapmak isteyip istemediğinize veya kalmasına izin vermeyi tercih edip etmediğinize karar verebilirsiniz.
Şirketle el ele
Bence bu, bir sayı söylemek için herhangi bir yüksek sayı söylemekten çok daha iyi bir yol. Tabii ki, şirket de günün sonunda oynamak zorunda. Ancak, bir tahmin gerekliyse, öncelikle sağlam bir tahmin yapabileceğiniz makul bir temel oluşturmanız gerektiğini bildirebilirsiniz.
Benim deneyimim, bunu anlaşılır bir şekilde anlayabilmeniz ve işin açıkça ve şeffaf bir şekilde iletseniz bile bunu takdir etmesidir. Çünkü bu şu anda olduğunuzu gösteriyor Olumsuz Sadece bir şey söyleyin, ama isteği ciddiye alıyorsunuz, güvenilir olduğunuzu ve sorunu yapıcı bir şekilde ve her şeyden önce birlikte yüzleşmeye çalıştığınızı. Ve sonunda olan şey bu, yazılımın geliştirilmesinde önemlidir: ilgili tüm konular buluşuyor. Öyleyse neden çabanın saygısıyla başlamıyorsunuz?
(RME)