Kod okunmaktan çok çalıştırılır
(olano.dev)- “Kod yazıldığından daha çok okunur” ilkesi, yazar yerine bakım yapan kişiyi öncelemek gerektiği fikrinden çıkarak kullanıcıyı, operasyonu ve işi de dikkate alan bir karar modeline genişler
- Kodun değeri inceliğinde değil, kullanıcının amacını karşılayıp karşılamadığında yatar; ürünü erken ve sık şekilde kullanıcılara göstermek ve geri bildirimi sürece katmak önemlidir
- Kodu production’da “çalıştırmak” dağıtımı, yükseltmeyi, gözlemlemeyi, denetimi, izlemeyi, düzeltmeyi ve kullanımdan kaldırmayı da kapsar; uzun vadeli işletim maliyeti, geliştirme sırasındaki rahatsızlıklardan çok daha büyük olabilir
- KISS, yalnızca kodu sadeleştirmekle kalmaz; hareketli parçaları azaltan ve hata modlarını anlayarak hata olsa bile sistemin çalışmasını sağlayan bir operasyon ilkesine genişler
- Bütçe, pazarlama, teslim tarihleri, paydaşlar, yatırımcılar ve siyasi çıkarlar karar süreçlerine dahil olduğundan, kullanıcıyı memnun etmek ile gelir yaratmanın her zaman örtüşmediğini kabul etmek gerekir
Öncelik modelinin genişlemesi
- “Kod yazıldığından daha çok okunur” sözü, kodu ilk yazan kişinin gelecekte onu okuyup değiştirecek kişilerin maliyetini göz ardı etmemesi gerektiği anlamına gelir
- Bu ilke; sadelik, test ve dokümantasyon gibi bakım yapılabilirliğe yatırım yapmanın gerekçesidir
- Sıkıştırılmış haliyle bu,
maintainer > authormodeli olarak görülebilir
Kullanıcı geliştiriciden önce gelir
- Kod bir amaç için araçtır ve yazılım bir kullanıcıya hizmet etmelidir
- Ne kadar iyi yazılmış olursa olsun, bir kod ya da ne kadar incelikli olursa olsun bir teknoloji, amacı karşılayamıyor ve iyi bir kullanıcı deneyimi sunamıyorsa değerini kaybeder
- Öncelik sırası
user > maintainer > authorşeklinde genişler; geliştirici rollerini ayırmazsak buuser > devolur - Kullanıcının ne istediğini tahmin etmek ya da yalnızca sormak yerine, programı erken ve sık şekilde kullanıcının önüne koyup geri bildirimden öğrenilenleri yansıtmak daha iyidir
Çalıştırmak production operasyonunu da kapsar
- “Çalıştırmak” yalnızca programı açmak değil, production’da işletmenin tüm sürecini kapsar
- Dağıtım
- Yükseltme
- Gözlemleme
- Denetim
- İzleme
- Düzeltme
- Kullanımdan kaldırma
- Dan McKinley’nin Choose Boring Technology yazısı, bir sistemi güvenilir biçimde sürekli çalışır halde tutmanın uzun vadeli maliyetinin, onu üretirken yaşanan rahatsızlıklardan neredeyse her zaman çok daha büyük olduğunu savunur
- Bu bakış açısı eklendiğinde model
user > ops > devolur - Birçok yazılım anlamlı ölçekte production’a ulaşamaz ve doğrulanmamış varsayımlar üzerine inşa edilir
- Kodu production’da işletince KISS, kod düzeyinin ötesine geçerek hareketli parçaları azaltma ve hata modlarını anlama meselesine dönüşür
- Önemli olan bir şeyi dağıtmak ve başarısız olduğunda bile çalışmasını garanti etmektir
İş ayrı bir eksendir
- Kullanıcıyı düşünerek geliştirmek sizi ileri götürebilir, ancak “kullanıcı için değerli olan yazılım organizasyon için de değerlidir” varsayımı basitleştirilmiş bir soyutlamadır
- Geliştirici açısından iyi yazılımı yapmak ve iş tarafının bunu paraya çevirmesi şeklinde ayırmak kolaydır; ancak sonunda çalışma sürecine iş perspektifini dahil etmeniz gereken bir an gelir
- Bu ayrım, tüketici yazılımları ve kurumsal yazılımlar için genel olarak işler
- Model
biz > user > ops > devşeklinde genişler - Bütçe en açık örnektir; kullanıcı ihtiyaçlarını karşılamak için kaynaklar sınırsız olmadığından maliyet ve faydayı ölçmek gerekir
- Pazarlama, teslim tarihleri, paydaşlar, yatırımcılar, kişisel çıkarlar ve politika da kararları etkiler
- Yalnızca yazılım, ekip ve kullanıcılar açısından doğru görünen bir karar, organizasyonun bütünü dikkate alındığında doğru olmayabilir
- Bazen kullanıcıyı memnun etmekten ziyade gelir yaratan işi yapmak gerekir
Model üzerinden geliştirme organizasyonunun kokuları
-
Bakımı imkânsız kod:
author > maintainer- Zeki ama tembelce yazılmış kod, spagettiye ve “hayalet ormanına” dönüşür
- Erken optimizasyon, yalnızca belirli bir kişinin dokunabildiği modüller gibi sorunları içerir
-
Kullanılamaz yazılım:
dev > user- Kullanıcıdan öğrenmeyen ya da teknolojiyi öne alan ekiplerden çıkar
- Aşırı tasarlanmış programlar, kullanıcı deneyimini kötüleştiren “modernizasyonlar”, tarayıcı özelliklerini bozan web uygulamaları buna örnektir
-
“Benim bilgisayarımda çalışıyor”:
dev > ops- Operasyon düşünülerek tasarlanmamış yazılımdır
- Küçük veri yükleri için gösterişli veritabanları kullanmak ya da küçük bir ekibin mikroservis ekosistemi işletmesi gibi aşırı karmaşıklıkları içerir
- Arıza olduğunda gece yarısı uyandırılan kişi ile tasarlayan kişinin farklı olduğu yazılımlar da buna girer
-
“Doğru olan”:
dev > biz- Kodu başlı başına amaç gibi ele alma durumudur
- Gösterişçi zanaatkârlar, Titanic’in müzisyenleri ve Lisp Hackers buna örnektir
-
Özgeçmiş odaklı geliştirme:
dev > *- Ortada risk yokken ve geliştirici istediği gibi davranabildiğinde ortaya çıkan yazılımdır
-
Hayali yazılım:
biz > user > ops > dev- Yapılmış ama production’a çok az çıkan ya da hiç çıkmayan yazılımdır
- Charity Majors buna living a lie diyor
- Kullanıcısı olmayan yazılım da hayali yazılıma girer; bir problemi çözmeyen, yanlış problemi çözen ya da kimsenin hiç sahip olmadığı bir problemi çözen yazılımdır
- Abartılmış bir teknolojiyle her şeye vurup sonunda belirsiz bir kullanım senaryosuna benzeyen bir şey çıkarma durumunu da kapsar
-
“Geç kapitalizm”
- Girişim sermayesi destekli yazılımın iş modelinin olmaması ya da tekele dönüşecek kadar büyüdükten sonra kullanıcıları sömüren bir iş modeline sahip olması durumudur
Kullanıcı ile iş arasındaki gerilim
biz > user, kabul edilmesi zor sonuçlar doğurur- Yazılımı öğrenme biçimimiz, son kullanıcıların sorunlarını çözmek üzerineydi; The Pragmatic Programmer’ın son ipuçlarından biri de yalnızca kod teslim etmek değil, kullanıcıyı memnun etmek hedefiyle özetlenir
- Yazılım yaygınlaştıkça bu varsayımı sürdürmek giderek zorlaşıyor
- Birçok yazılım kullanıcıyı önemsemiyor, onu manipüle ediyor ya da kullanıcıyı ürün haline getiriyor
- Bu sorun yalnızca sosyal medya ile sınırlı değil
- Oda rezervasyonu, yemek siparişi, Windows Başlat düğmesine tıklama sırasında bile kullanıcının dikkatini çekmeye çalışan pop-up’lar çıkıyor
- Google aramasında, çöp yığını gibi sonuçlar alındığı ifade ediliyor
- İyi bir şey yaptığına inanmak ile sektörün kayda değer bir kısmının kârlı gördüğü şey arasındaki uyumsuzluk, birçok yazılım profesyonelinin rahatsızlığını açıklar
- Ekonomik gerçekliği görmezden gelen eski hale dönemeyiz; ancak kullanıcılara zarar vermemek için daha güçlü bir etik tutuma ihtiyaç var
- Kullanıcı her zaman işin önüne geçemeyebilir; ama iş de koşulsuz olarak önce gelmemelidir
user > ops > devbiz > ops > devbiz ≹ user
1 yorum
Hacker News yorumları
Bazı kullanıcılar bir sistemi sevdikleri için değil, şirketleri satın aldığı için kullanır.
Böyle durumlarda, tanım gereği iş tarafı kullanıcıdan önce gelir ve geliştirici gerçek kullanıcılar yerine müşteri şirketteki orta kademe yöneticilerin taleplerine göre hareket eder. Çünkü bunu yapmazsa sözleşmeyi alamaz. Sonuçta kullanıcı, geliştirme ekibi orta kademe yöneticinin hoşuna gidecek yeni özellikler yapmakla meşgulken, baştan savma sunulmuş işlevlere bağlı kalır.
Biraz alaycı olabilir ama bir mühendis olarak temelde böyle bir şirkette olup olmadığını bilmek faydalıdır. Örneğin çevrimiçi perakendeciler kullanıcıya karşı çok hassastır; Almanlar X’i, Amerikalılar Y’yi seviyor diye web sitesinin ülkeye göre farklı sürümlerini bile tutabilirler. Çünkü küçük bir değişiklik gelirde büyük fark yaratabilir.
Buna karşılık bazı şirketlerde ürünü satın alan kişi gerçek kullanıcı olmadığı için kullanılabilirliğe neredeyse hiç duyarlılık yoktur.
Sözleşmeyi almak için müşteri şirketin kontrol listesini karşılamamız gerekiyordu ama kullanıcı deneyimini de önemsiyorduk. İyi kullanıcı deneyimi, müşterinin katı gereksinimleri arasında neredeyse hiç yer almıyordu.
Rakip yazılımı kullanmak çok eziyetliydi; biz de bu noktada farklılaşmak istedik. Bunun sayesinde eğitim kolaylaştı, kullanıcılar daha memnun kaldı ve mümkün olduğunda kendi yöneticilerine ürünümüzden daha fazla satın almalarını önerdiler.
Sonuçta bunun %80’i “yazılımımız berbat değil” gururundan ve empatiden geliyordu; ama uzun vadede marka oluşması açısından bizim de çıkarımızaydı.
Ürün odaklı büyüme stratejisi seçmiştik, satış elemanımız yoktu ve ürün ekibi tamamen kullanıcı deneyimine odaklanmıştı. Sorun, ürünü kullanıcılara satmıyor olmamızdı. Yazılımı satın alanlar, kullanıcı organizasyonundaki başka kişilerdi ve gerçek ürünü doğrudan denemişlikleri de yoktu.
Başarısız olmaya mahkûm bir yaklaşımdı. Alıcıların zihnini anlayacak, onlara faydayı anlatacak ve kullanıcıları da organizasyon içindeki başka kişilere faydayı anlatmaları için koçluk edecek satış elemanlarına ihtiyaç vardı. Kullanıcı ile alıcı arasındaki boşluğu kapatmak gerekiyordu.
Bu yüzden mesele hangi kullanıcıların önceliklendirileceğine gelir: diğer kullanıcılar üzerinde etkisi olan azınlığın deneyimine öncelik vermek ile diğer kullanıcıların yönetime anlamlı veri sağlayacak kadar ürünü kullanabilmesini sürdürmek arasında denge bulmak gerekir.
Önemli olan yalnızca belediye başkanının, town manager’ın ve belediye meclisinin görüşleriydi. Raporlar iyi görünüyorsa ve fiyat uygunsa yeniliyorlardı.
Sahadaki toplantılarda, ürünü her gün kullanan insanların yüzümüze karşı bunun ne kadar korkunç olduğunu söylediği anları hatırlıyorum. Buna rağmen istisnasız şekilde, birkaç belirli bug’ı düzeltme sözü ve asgari bir fiyat artışıyla o müşteri sözleşmeyi yeniledi.
Bugün ≹ diye bir sembol öğrendim. “Karşılaştırılan iki nesneden hiçbirinin diğerinden büyük ya da küçük olmadığı, ancak mutlaka eşit de denemeyeceği bir ilişkiyi gösterir. Kesin biçimde sayısal olmayan karşılaştırma biçimlerinin bulunduğu alanlarda önemli bir nüans” deniyor (https://www.mathematics-monster.com/symbols/Neither-Greater-...)
Bunun yerine |z_1| = |z_2|, yani iki karmaşık sayının aynı mutlak değere sahip olduğunu yazmak daha açık görünüyor.
“Sonuç olarak ≹ sembolü, geleneksel ilişki operatörleri arasında bir orta zemin sağlamada önemli bir rol oynar” denmiş; ama bir matematik doktora öğrencisi olarak bunu hiç görmedim. Önemli bir rol oynadığına inanmak zor.
Oyunlar sürreal sayıların üst kümesidir; sürreal sayılar da gerçek sayıların üst kümesidir. Sürreal sayıların tanımı gevşetilerek tam sıralama özelliği kaybettirilmiştir.
Böylece başka sayılarla “karıştırılabilir” ya da “bulanık” olan garip sayılar ortaya çıkar. En basit örnek * (star)’dır; 0’dan ne büyük ne de küçük olduğu için 0 ile karıştırılır. 0’ın etrafındaki bulanık bir bulut gibidir ve 0║* olarak gösterilir.
Daha karmaşık bir oyun olan switch, daha geniş sayı aralıklarıyla karıştırılabilir ve “sıcak” kabul edilir. Switch’lerle sayılar oluşturunca daha ilginç sıcak oyunlar yapılabilir.
Tek bir cihazda üretilen olaylar her zaman tam bir sıraya sahiptir. Ancak çevrimdışı durumdaki iki cihazda olay üretirseniz hangisinin önce olduğunu söyleyemezsiniz ve iki olay arasında ≹ ilişkisi oluşur. Başka bir deyişle olayların eşzamanlı olduğu kabul edilir.
Bu yüzden “d > b > a” ve “d > c > a” gibi sıralar oluşabilir ama “c ≹ b” olur.
Bu tür durumlarda eşitlik bozmayı deterministik biçimde yapmanın yolunu tanımlamak, CRDT’lerin çözdüğü problemin büyük bir bölümüdür.
Bu nasıl mümkün olabilir?
Birçoğumuz için kodu 1 milyar kez çalıştırmanın maliyeti, bir geliştiricinin birkaç dakikalık zamanından daha ucuz olabilir.
AWS’te aylık sunucu maliyeti olarak 200 dolar harcarsam, web API kodumun önemli bir bölümünü 100 milyar kez bile çalıştırabilirim.
Bu yüzden insan okuyucular için optimizasyon her zaman daha iyidir; ekonomik olarak katlanılamayacak kadar yavaş olduğu kanıtlandığında ancak başka optimizasyonlar yapılmalı.
Yazı şu ifadeyle bitiyor:
user > ops > dev
biz > ops > dev
biz ≹ user
Sonuç, kodun nihai kullanıcı ve iş için var olduğu fikrine daha yakın görünüyor. Son ifade olan ≹, nihai kullanıcı ile işin ihtiyaçlarının aynı olmadığını, ama kodun varlığı açısından ikisinin de eşit derecede önemli olduğunu temiz biçimde ifade ediyor.
Kullanıcılar daha yüksek elektrik faturası, azalan ömür[0], kaçırılan fırsatlar, daha fazla hayal kırıklığı, daha sık donanım yükseltmesi gibi daha az belirgin yollarla bedel öder.
Üstelik kullanıcıların çoğu geliştirici maaşına ya da yaşam kalitesine sahip olmadığından, zarar onlara katbekat daha ağır gelir.
[0] Başkalarının zamanını boşa harcamak QALY’yi azaltmaktır.
Üretimde işletmeyi; yani dağıtım, yükseltme, gözlemleme, denetim, izleme, düzeltme, kullanımdan kaldırma vb. her şeyi kapsadığını söylüyor.
Başlığın sonucunu yazara geri söyleyecek olursak, “kod yazıldığından daha çok okunur” değil, okunamayan kod uzun süre çalışamaz ifadesine daha yakın.
Yine de ben geliştirmeye yanal geçiş yapmaya çalışan deneyimli bir sistem yöneticisiyim ve bu anlamda tamamen acemiyim.
Daha doğrusu “okunamayan kod uzun süre değiştirilebilir kalamaz” demek daha yakın.
Kasıtlı obfuscation’dan söz etmiyorsak, kodların çoğu emek vermeye istekli biri tarafından okunabilir; gerekirse kod formatlayıcılar da var.
Buna eklenecek bir sonuç daha var. Aşağıdaki her aşama arasında kullanım sayısı üstel olarak artar.
Birçok dilde her aşamadaki oran kabaca 1000 kat düzeyindedir; yani 1 dil tasarımcısına karşılık modül tasarlayıp dağıtan 1000 kişi, 1 milyon geliştirici ve 1 milyar kullanıcı olabilir. Somut duruma göre sayılar çok değişir ama nitel tartışma için ölçek kabaca doğrudur.
Esas nokta, birinci ya da ikinci aşamadaki çok küçük bir tembelliğin aşağı akışta dramatik biçimde katlanmasıdır. 1. aşamada “kendi rahatlığı” için 1 dakika kazanmak amacıyla yapılmış kirli bir hack, başka insanların değerli hayatlarından kelimenin tam anlamıyla milyonlarca saat çalabilir. Çünkü onları yavaş yazılımı beklemeye, çökme yüzünden hayal kırıklığı yaşamaya ya da 2. ve 3. aşamalarda özellik geliştirme geciktiği için beklemeye zorlar.
İlk iki aşamada gereken kalite düzeyini korumak muazzam bir öz disiplin ve kişisel etik gerektirir. Buna karşılık, çekirdek dil veya standart kütüphane tasarımıyla ilgili haklı gösterilemeyecek tutumların savunulduğunu her duyduğumda derin bir üzüntü duyuyorum.
“Bu keskin kenarın ortaya çıkış tarihinin tamamını bilirsen sorun yok! Sonsuza kadar tetikte olursan problem değil. Yanlış kullanmadığın sürece güvensiz, güvenlik açısından riskli, yavaş ya da sorunlu değil” gibi sözleri sıkça duyuyorum; çünkü bunların önümüzdeki onlarca yıl boyunca geliştiricilerin ayağına takılacağını ve milyonlarca, milyarlarca insanın yazılımını yavaşlatacağını biliyorum.
Yazar oldukça iyi bir deneyim kuralını alıp her şeyin teorisi hâline getirmeye çalışıyor gibi.
Derli toplu ve akıllıca görünüyor ama zorlama ifadeleri çıkarınca, yaygınca bilinen sıradan sözleri yeniden çiğnemeye daha yakın.
Bu yüzden ifade biçimi garip gelebilir.
Ayrıca “yaygınca bilinen sıradan sözler” olsa bile, bu yazı onları özellikle tutarlı bir biçimde iyi bağlayıp faydalı bir referans hâline getiriyor.
Birileri için her şey yenidir; benim açımdan sadece önyargılarımı doğrulamış olsa bile ilginç bir bakış açısıydı.
Yazarın çerçevesi, çok fazla farklı şekilde yanlış anlaşılabileceği için kullanışlı bir kısaltma ifade olmaya pek elverişli değil. Bu token’lar arasında mutlak bir sıralama olamaz.
Öncelikle burada “dev” tek bir kişi değil; birden çok kuruluşun ürün, mühendislik ve tasarım ekiplerine yayılmış, farklı uzmanlık ve kıdem düzeylerine sahip insanların toplamı.
“ops” da tek bir şey değil ve yalnızca mühendislik operasyonları anlamına gelmiyor. İş operasyonları, müşteri desteği vb. de buna dahil olabilir.
“biz” de tek bir şey değil. Markalaşma, pazarlama, satış, hukuk ve yönetim kadrosu, yönetim kurulu, düzenleyici kurumlar, kredi verenler, yatırımcılar vb. var.
Tüm bu insanlar hangi kodun yazılacağını, nasıl yazılacağını ve kullanıcılara ne zaman, nasıl dağıtılacağını etkiler. Hepsinin aynı problemi çözmesi gerekir.
Kurum içindeki birçok insan çoğu zaman herkesin aynı problemi anlaması, görmesi ve aynı hedefe doğru çalışması için vardır.
Ancak bu anlayış sürekli evrilir ve kurum geneline yayılmasında gecikme olur. Bu yüzden hedefin kendisi değişirken bile herkesin aynı hedefe doğru çalışmasında da gecikme oluşur.
Son olarak “user” da tek bir şey değildir ve hiçbir kullanıcı grubu statik değildir. Çeşitli kullanıcı grupları vardır ve bunların davranışları uzun vadede istikrarlı olmayabilir.
Bu nedenle etrafınızdaki tüm değişkenlerin nasıl değiştiğini anlamak ve kabul etmek, ardından bu bağlam içinde kusurlu ve bozuk dünyayı yorumlamak faydalıdır. Aksi halde herkesin berbat olduğu, her şeyin bozuk olduğu ve her şeyi baştan yapmak istediğiniz bir noktaya savrulmak kolaydır.
Etiğe yakın konuların tartışıldığını görmek sevindirici.
Yazıdaki “İyi şeyler yaptığımızı düşündüğümüz şeyler ile sektörün önemli bir bölümünün kârlı bulduğu şeyler arasında bir uyumsuzluk var ve bence birçok yazılım profesyonelindeki rahatsızlığın artmasının nedeni bu” kısmında rahatsızlık oldukça hafif bir ifade. Pek çok şey söylenmeden kalıyor.
Birkaç soru eklemek isterim. Kullanıcı müşteri, yani ödeme yapan kişi olmadığında ne olur? İşletmenin, ödeme yapmayan kullanıcılar dahil tüm kullanıcılara karşı etik bir yükümlülüğü var mıdır? Ücretli bir müşteri, işletmenizi kullanıcılar üzerinde olumsuz alt etkiler yaratacak şekilde kullanmak isterse ne olur?
Örneğin bir platform dolandırıcılığı mevcut alternatiflere göre daha kolay hale getiriyorsa, yanlış bilgi yaymayı kolaylaştırıyorsa ya da kullanıcıların görüşlerini uzun vadede yıkıcı ama çekici ve alışkanlık oluşturan biçimlerde şekillendirmeyi kolaylaştırıyorsa ne olur? Bunların hepsinin belirli bir süre boyunca başarılı iş modelleri olduğu kanıtlandı.
Bu dinamikler gerçekse, işletme bu tür sömürücü modellerin peşinden gitmeli mi? Gidecekse bunu daha sorumlu biçimde yapabilir mi? İşin daha etik bir versiyonu rakiplerin en kötü eğilimlerini hafifletebilir mi, yoksa sonunda sorunun bir parçası mı olur?
Temel sonuç açık. Bazı problem türleri iş modelinden daha büyük ve daha önemlidir. “Şirketlerin belli bir sağduyu sınırı içinde işlemesini sağlamak için hangi normlar ve kurallar gerekir?” diye formüle edilebilecek problemler vardır.
Son olarak netleştirmek isterim. Bir işletme doğası gereği bir dizi değer aktarır ve bundan kaçınılamaz. Yalnızca “popüler olan kazanır” tutumunu almak bile, kendi başına değerler açısından derin sonuçları olan bir seçimdir. Siyaset bilimciler ve tarihçiler çoğunluğun tiranlığı sorununu uzun zamandır biliyor. Siyasi felsefeniz ne olursa olsun, üzerinde düşünmeye değer.
“En iyi” etik sistemin ne olduğunu bilmiyorum ama bazı etiklerin diğerlerinden daha iyi olduğunu biliyorum. Ve etiğimizi incelemeden bırakmak yerine sürekli geliştirmemizi umuyorum.
Hangi problem ve alanların kendi etiğinize uyduğunu seçebilirsiniz. Bu yazı, sistemleri nasıl kurduğumuz ve çalışma önceliklerini nasıl belirlediğimizle ilgili.
İş dünyası aslında var olan bir şey değil; kaynakları organize edip birlikte çalışmak için bizim yarattığımız hayali bir yapı
İş dünyası her şeyden önemli değildir. Kullanıcılar birden fazladır ve bazen çıkarları çatışır. Her yerde olamaz ve her şey olamazsınız; bu yüzden öncelik belirlemek gerekir. Daha kârlı kullanıcıların ya da uzun vadeli stratejiye uyan kullanıcıların peşinden gitmek “iş için iyi” görünebilir, ama aslında hedef kullanıcılara hizmet etmektir. Sadece birkaç adım daha dolaylıdır
İç siyaset öyle karışır da kararlar bunun kullanıcı mutluluğuna nasıl bağlandığına bakılmadan yalnızca işin çıkarı için alınır hale gelirse, organizasyon toksikleşmiş demektir. Artık var olmamalıdır. Bir süre zombi gibi sendeleyerek ilerleyebilir ama düşüştedir ve iyi insanların hepsi ayrılır
Duyguların da durumlara verilen tepkileri açıklamak için oluşturulmuş bir yapıdan ibaret olduğu söylenebilir; ama atomlardan yapılmamış olmaları “gerçek” olmadıkları anlamına gelmez
İş dünyası, çoğu insanın hayatını belirleyen başlıca etken olduğu ölçüde vardır. Şehirleri, medyayı, hukuku, siyaseti, dış politikayı şekillendirir ve neredeyse önemli olan her şey üzerinde büyük etkisi olur. Gerçek olsun ya da olmasın, çevremizde somut etkiler yaratır
Açık kaynak dışında, parayı ödeyen tarafın neyin nasıl yapılacağını belirlediği oldukça açıktır. Bu karar o taraf için kötü, kullanıcılar için kötü, genel kamuoyu ya da çevre için kötü olsa bile. Elbette sektör ve devlet düzenlemeleri vardır ama genel olarak karar yetkisi şirketlerdedir
İşletmeler ne yazık ki sahiplerine hizmet etmek için vardır. Çoğu durumda, özellikle 5 kişiden küçük mikro işletmeler olmayan büyük şirketlerde, sahipler para ister; bu yüzden şirketteki herkes sahiplerine daha fazla para kazandırmak için vardır. Başkalarının mutluluğu, kullanıcıların mutluluğu bile, gelirle korelasyonu olduğu durumlar dışında tamamen ilgisizdir
Şirket içindeki bir başka yaygın teşvik de kendini korumadır. Bu yüzden karar vericiler para kazanmanın yanında kendi işlerinin güvenliğini de hesaba katar
Çalışanlar ayrılmaz. Çünkü şirket onları yeterince memnun eder. İyi para verip kendilerini bir “topluluğun” parçası gibi hissettirmek gibi yollarla, insanları kötü ya da yüzü olmayan bir organizasyonda çalışmaya devam ettirmek şaşırtıcı derecede kolaydır. FAANG ofislerine bakarsanız bu İK numaralarının ayrıntılı bir listesini görebilirsiniz
Böyle şirketlerin toksik olduğu ve var olmaması gerektiği konusunda hemfikirim, ama şirketler gerçekte böyle işler. Bu bir çöküş işareti değil; onlarca yıl sürebilen olgun ve sağlıklı bir işletmenin görünümüdür. Yöneticiler de ürünler de sahipler de değişir, ama işletme kalır
Ama önem özneldir. Kendi keyfiniz için yazdığınız kişisel kodsa iş tarafı önemli değildir. Bunu ana gelir kaynağınıza dönüştürmek istiyorsanız iş tarafı en önemlisidir. Çünkü yazılım kimseye hizmet edemiyorsa, kullanıcılar onu ne kadar sevse de gerçek gelire dönüşmez
Bir iş modeli yoksa kullanıcıların sevdiği, dağıtılabilir ve bakımı yapılabilir harika bir yazılım bile sönüp gidebilir
Başta şüpheliydim ama bu düşünce modelini sevdim
Elbette körü körüne izlenmemeli. dev > biz olan istisnalar da var; OpenAI olayı buna örnek. dev > ops olan istisnalar da var. Erken aşama startup’larda hızlı hareket etmek gerektiği için, özellikle iş tarafı nedeniyle dev > ops olabilir