Before the agile manifesto

Nowadays, if you are in the world of business, especially in software business, and criticize the "religion of agile methods", you are cursed. Scrum must be the method. There must be sprints, coaches, daily stand up meetings, post-its, burn down charts, tribes, masters, retros and other rituals... There is no room for good old fashion, heavy duty engineering and management. Besides, it is very popular to cancel the bad old practices. 

I am always into knowing the essence of the things around, extracting the root idea and being able to improvise for authenticity rather than being the follower of the popular narratives. Moreover, I don't believe that any method can save you. Only you can save yourself. There will be no eternal relief or salvation... I've already explained this in detail in one of my prior posts titled "Forget about failing" so I'm not going to repeat the same things here.

Today, I am going to cite two books for supporting my ideas. The first one is "Fundamentals of Computing II: Abstraction, Data Structures, and Large Software Systems". This book was published in 1993 from McGraw-Hill and used as our lab textbook of software engineering course in Ege University computer engineering department. Please have a look at the sample page below:


In this section of the book, a number of software project management recommendations are given. I am also writing the text to be noticed with my interpretations added:

Bullet 1:
Assign clearly defined tasks organized by functional area. This results in a product that has conceptual unity and does what was intended. It also makes for a more motivated programmer.

For me, this is about defining coherent software products and product development teams accordingly.

Bullet 2:
Use walkthroughs. Some evidence at this point suggests that walkthroughs are the most effective method for software quality control even better than formal verification! So walkthroughs are a critical component of any effective software team.

Here, the authors are stressing the importance of scenario based software proof-reading. Suggestions are similar to extreme programming, pair programming etc.

Bullet 3:
Do not add new programmers to an already late software project; this will only make it later. This statement was first expressed in The Mythical Man-Month by Brooks and since has come to be known as Brook's Law. It's not hard to see why this is true - when new people are added, they have to be trained. This takes substantial time away from people who are already working on the project. Also adding new people to a team increases the possible lines of communication - this can reduce everyone's productivity.

This refers to the autonomous and preserved development teams.

Bullet 4:
Include representatives of all user groups on the development team. Until the past few years, an analyst would interview users, and that would end users' involvement until they tested the final product. This was often unsatisfactory as users frequently do not know what they want until they have tried the software. Recall that prototyping is a software development technique in which the user interface is designed first and iteratively refined by working with users even before a full scale design is undertaken. Thus prototyping helps fulfill this guideline. Beyond prototyping, however, receiving user  input throughout the development process ensures a higher level of user satisfaction with the final product.

This portion is the heart of the message. In the early 1990s, authors were saying that "...Until the past few years, an analyst would interview users, and that would end users' involvement..." by using the past tense :) And they are suggesting to add users in the development team from the beginning, to follow iterative development with continuous user testing and feedback collection. They are not using any term like MVP which is, I think, the most ambiguous abbreviation coined ever but they are recommending to use software prototyping. After many years, software industry re-invented the wheel and called it MVP. Anyways... Let's keep reading...

Bullet 5:
Provide a supportive environment. Adequate workstations, technical support, and secretarial help make a team far more productive.

:) Impediment removers, fancy cubicles, SCRUM rooms, wall boards, post-its, markers... What more can I say?

As you can see, it was always there for the ones who have open minds and eyes.

The second book I am to share is "The Martian Principles for Successful Enterprise Systems: 20 Lessons Learned from NASAs Mars Exploration Rover Mission" by Ronald Mak. Professor Mak also wrote a chapter in the famous book "Beautiful Code", never miss it. I have chosen the book referring to the NASA practices because the projects managed by NASA are the triumphs of  humanity. The optimal combination of science, technology, engineering, general management, team building, performance tracking, project management etc. can be found in the works of NASA. I am now pasting a screenshot from the book, very sharp lesson:


Very neat indeed, nothing more to say.
 

kod-la-ma

 

Punch Card, Source: Computer Museum of America

Yapay zeka, makine öğrenmesi, veri mühendisliği odaklı lisans programlarının ortaya çıkmasıyla beraber bilgisayar mühendisliği ve özellikle yazılım mühendisliği mesleklerinin tanımı, sektördeki pozisyonlaması ve akademik kökleri üzerine daha sık düşünüyorum. Henüz bir sonuca varamadım ama fikirlerimi biraz düzene sokabilmek adına yazmak istedim.

Aslen, beni bu paylaşımı yapmaya iten tetikleyici birkaç hafta önce aldığım bir e-posta. Gelen mesaj, çalışanları bazı hobi aktivitelerine davet eden  bir tanıtım broşürüydü. Bahsedilen konular bahçe düzenleme, resim, yoga, dans, fitness, ahşap boyama, tenis, golf diye giderken birden listenin sonlarında karşıma "kodlama" çıktı. Öncelikle kategorik bir dumur yaşadım: Yıllardır komplike bir meslek sınıfında olan şey ne ara bir tür hobi aktivitesine dönüşmüştü? 

Bu arada, hobi kavramının sığlaştırılmasına genel olarak karşıyım. Mesela, biri "sinema hobimdir" diyorsa, o kişinin sinema izlemek için sistemli ve derinlemesine emek vermesini, sinemanın mantığı, tekniği, anlatısı, tarihi vb. üzerine sıradan insanlara nazaran çok daha fazla bilgisi olmasını beklerim. Bu düşünceme rağmen, listede kodlama adlı bir hobi görmeyi ilk planda sindiremedim. Sonra, biraz daha düşündüm üzerine, bir arkadaşımla da irdeledim durumu. Belli bir yere geldik...

Bir meslek ile bir hobi arasındaki fark nedir? Neticede listede yer alan diğer kategoriler de aynı zamanda birer meslek olarak icra ediliyordu. Ben neden kodlamaya takılmıştım?

Toparlamaya çalıştığım temel kuralları paylaşayım:
1. Bir konuyu hobi edinebilmek için o konunun meslek erbabı dışında olmalısınız.
2. Bir konu hakkında "hobimdir" diyebilmek için o konuya sıradan insanların sarf ettiğinden çok daha fazla emek vermelisiniz.
3. Bir alan hobinizse sizden o alanda performans talep edilmez, siz de performans garantisi vermezsiniz. Oysa o alan mesleğinizse, sizden performans talep edilir ve siz de performans garantisi verirsiniz.
4. Bir alanın hobileşebilmesi için giriş bariyerinin düşük olması gerekir.

Konuya böyle bakınca işin hobiyle ilgili yanı belli bir temele oturtulabiliyor. Gelelim mühendislik işlerine.

Eski çağlarda bilgeler hemen hemen her konunun uzmanıydılar. Meşhur örnekleri vermek klişe olur ama akla hemen gelen kişiler Pisagor, Platon, Ömer Hayyam ve Leonardo da Vinci'dir. Aydınlama sonrası akademik yaklaşım ise, her konuyu daha alt konulara bölerek düzenlemeye ve bu yönde uzmanlıklar geliştirilmesine dayalı olarak işliyordu çünkü bilimsel yaklaşım inanılmaz boyutta bilgi üretmekteydi ve bir insanın buna yetişmesi mümkün değildi (John von Neumann hariç :). Son yıllarda bu aşırı alt disiplinli yaklaşımın yeni bilgi üretimini sınırladığı fark edildi ve tekrar çok disiplinli çalışmalar örgütlenmeye gayret ediliyor (The Third Culture). Analiz artık limitlerine dayandı, yeni sentezlere gereksinim duyuluyor. Yani  konunun bir tarafında birden fazla mesleki bilgiye dokunabilen yeni tip profesyoneller ve akademisyenler var. Dolayısıyla, artık bilgisayar programlayabilen tıp doktorları, biyolojiye çok hakim elektronik mühendisleri, sanat tarihi uzmanlığı olan bilgisayar mühendisleri, makine öğrenmesi tekniklerini bilen avukatlar göreceğiz. Bir meslek hakkında aşırı sahiplenici bir tavırla meslek dışındakileri hariç tutmaya çalışmak veya onları hor görmek azalması gereken davranışlar arasında sayılacak. Çevik dönüşüm hamleleriyle şirketlerde kurulmaya çalışılan "siloları yıkın" temalı yaklaşımları mesleki silolar için de göreceğiz bence.

Meselenin diğer bir tarafı da kurumsal eğitimin sunduğu akreditasyonla alakalı. Diplomalardan bahsediyorum. Yıllar önce, kurumsal mesleki eğitim konusundaki riskler entelektüel çevrelerde dile getirilmeye başlanmıştı. Argümanları güçlü, güzel bir makaleye burdan ulaşabilirsiniz. Sadece ülkemizde değil, tüm dünyada geleneksel kurumsal eğitim yetersiz kalmaya başladı. Bununla beraber, kişilerin kendi kendine öğrenmesini mümkün kılan bilgi ve iletişim teknolojileri alabildiğine yayıldı. Bilgiye erişmek çok kolay. Doğru bilgiyi yanlıştan ayırt edebilmek, kritik sorularla özgün sentezler yapabilmek çok daha önemli hale geldi. Bu meziyetlere sahip kişiler, karşılığında iyi para kazanabilecekler. Bu gerçekler ışığında bakılınca, bir konunun diplomasına sahip olmayan ama kendini o konuda çok iyi yetiştirmiş kıymetli profesyonellere rastlama olasılığının artacağı görülebiliyor. Yani, mükemmel elektronik mantık devreleri tasarlayıp üretebilen 17 yaşında bireyler diplomalılara rakip olacaklar. İlerde, bilgi/beceri sahibi olmak ile diploma veya sertifika sahibi olmak arasında bir korelasyon kalmayabilir. Son zamanlarda sosyal mecralarda paylaşılan sertifika resimlerinin adedi de bir fikir veriyordur bu trend hakkında sanırım. Neticede, "benim bu konuda diplomam var" diyerek o konudaki diplomasızları yok saymak veya hor görmek iyi bir strateji olmayacaktır diye düşünüyorum.

Hobilere dair koşulları yukarda sayarken alanın giriş bariyerinden bahsetmiştim. Bu oldukça geçerli bir koşul. Konunun karmaşıklığı belli bir eşiğin üzerindeyse ciddi bir alan eğitimi olmadan o konuda uzmanlaşmak ve hatta o konuda hobi aktivitelerine girişmek çok çok zor. Bazen de imkansız. Örneğin, hobi olarak genel cerrahi sahasına giremez çoğu insan. Bu gibi alanlarda yasalar da belli sınırlar koyuyor zaten. Meslek odaları, barolar vb. işin içine giriyor. Kodlama hobi olabildiğine göre yazılım mühendisliği mesleği yeteri kadar karmaşık olmasa gerek :) Veya yazılım mühendisliği kodlamanın ötesinde karmaşıklığa sahip olsa gerek. Veya yazılım mühendisliği mesleği yasal olarak düzenlenmemiş olsa gerek... Bilgisayar mühendisliği fiilen 1930 sonlarında, lisans eğitimi olarak da 1970 başlarında ortaya çıktı. Yani 80 yıldan uzun zamandır var olan bilgisayar mühendisliği ile çok daha eski olan elektrik/elektronik mühendisliği arasında gayet hoş biçimde çekilebilmiş olan sınır çizgisi malesef bilgisayar mühendisliği ile yazılım mühendisliği veya yapay zeka veya veri bilimi veya veri mühendisliği arasında tam olarak belirginleştirilemedi. Mesela veri bilimi konusunu tanımlayabilmek için aşağı yukarı her profesörün, danışmanlık firmasının ve kurumun kendine has bir Venn diyagramı var :) Konu uzmanlığı, matematik, istatistik, bilgisayar bilimleri başlıklarını ne ölçüde kesiştirerek veri bilimcisi profilinin tanımlanacağına dair reçete tam olarak kararlaştırılamıyor. Geçen yılın Turing ödülüne layık görülmüş olan Jeffrey Ullman'ın eğlenceli videosuna bir göz atmanızı öneririm. Bilgisayar mühendisliğindeki fiili durum ile akademik tasnif arasında geçmiş olan yaklaşık 40 yılı düşünürsek henüz bu çizgilerin netleşebilmesi için zamana ihtiyaç olduğunu söyleyebiliriz. 

Sonuç!?
Hobi olarak kodlama böyle yayılıyorken diplomalı "bilgisayarcılar" ne yapsın?

Acilen bir şey yapmaya gerek yok çünkü bu alanlarda inanılmaz derecede uzman açığı var. Fakat, bir strateji oluşturmak çok fayda sağlar. Bu stratejik duruşu sağlayabilmek adına pratik gözlemlerime dayanan birkaç tavsiyem var:

1. Alt disiplinlere saplanarak "ben Javacıyım, ETLciyim, databaseciyim, sistemciyim, networkçüyüm..." demeyi bırakın ve doğru senteze varabilecek kalibrede bilgisayar mühendisliği yapın: Fiziki katmanlardan bilgi sunumu katmanlarına dek sistemlerin içerisinde neler döndüğünü bilemezseniz fark yaratamazsınız. 

2. Mesleğinizde karşılaştığınız durumları tarif ederken sanayide yetişmiş çırak ağzıyla konuşmayın, okullu olmanın hakkını her ayrıntıda verin. Mesela "memory şişmiş, job patlamış, 5 paralel verdim, SQL çektim, donma problemi var vs." demeyin. Muayeneye gittiğiniz doktor sizinle öyle konuşsa güveniniz sarsılır, reçetesini almazsınız.

3. Sorumlusu olduğunuz sistemlerle ilgili bir problem bildirildiğinde konuyu rasyonel bir mühendis hassasiyeti ve ciddiyetiyle ele alın. "Ben denedim oldu, bizim loglar temiz, testte baktık çalıştı, kapatıp açtık düzeldi, olmaması lazım aslında, bir daha olursa haber verin vb." demeyin. Sorun neredeyse tespiti orada yapın, sorunu temelden çözün. 

4. Şaşırmayın. Bilin. Mesela, Julia neden Python'dan hızlı, Go neden Java'dan hızlı, Scala neden daha portable bilin. Yerinde kullanın. Dogmatik inanç geliştirmeyin. Teknoloji fanatiği olmayın. 

5. Bilgisayar sistemlerinin kullanıcısı değil geliştiricisi olarak yaklaşın her konuya. Asla "teknik olarak imkansız" demeyin, teknik olarak hep imkanlıdır. Uygun tekniği bulun.

6. Kendi kendinize öğrenin ve çok hızlı öğrenin. Lise 1 talebesi kendi kendine 3 haftada Python öğreniyorken, bir bilgisayar mühendisi olarak, şirketinizin sizi Python kursuna göndermesini beklemeyin, geride kalırsınız.

7. Stackoverflow veya Kaggle göçtüğünde, ya da İnternet bağlantınız olmadığında dahi bilgisayar sistemlerini geliştirebilecek bir mesleki seviyede olun.

8. Eskiden kendinizi özel hissetmenizi sağlayan efsaneler vardı: "Bizim iş biraz da sanattır, bizim beynimiz çok farklı çalışır, bilgisayar sistemleri biraz da mistiktir..." kabilinden tavırlara girmeyin. Hesap yapın. Geliştirdiğiniz bütün yazılımları ezbere bilin.

9. Bir işin yapılmasını sağlayan bilgisayar sistemlerini geliştiriyor olmak o işin erbabı olmak anlamına gelmez. İşler genelde irrasyonel durumların ilginç şekilde yönetilmesiyle sürer ve o dünyada sonsuz parametre vardır. Bilgisayar sistemleri ise programlanmış rasyonel etkileşimleri icra eder. Aklınız karışmasın. İki tarafı da bilin, iki tarafı aynı sanmayın.

10. Her sistemi kendine has bir meta-dil işleten parametreler yumağı haline getirmeyin. Yani her şeyi parametrik yapmak iyi mühendislik yapmak değildir. Parametreyi yanlış değerle beslediğinizde hata almazsınız ama programı yanlış yazarsanız büyük ihtimalle geliştirme fazında hata alırsınız ve bu iyi bir şeydir.

11. Kendi geliştirdiğiniz sistemlerden bahsederken sanki bir başka kişiden bahseder gibi konuşmayın: "Sonra listeden keyleri beşer beşer çekip, kayıtları sunucuya gönderiyor ve arada kayıt atlarsa hata vermiyor... saçmalıyor..." demeyin. Bunu düşünen ve hayata alan sizdiniz. 

12. kod-la-mayın; //:)

end;