43



yalnızken
karnındaki küçük evren
yoksa seni besleyen

derinleşmeden
yüzeyden
alıp vermeden
eğlen

uzaklaş insan lekesinden

içerden bilgilen
dışardan zevklen
hiçbir şey beklemeden

isteyen gülsün
isteyen ağlasın
sen giderken. 

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;
    

Şemyaza

 

sayılamayan saatlerin
düşmüş meleklerle
gecelerde
ıslak ve sıcak
kurbanların nerde?

bilinmeyeni açık ettiğin
açıktakileri lanetlediğin
karanlıkta nurlanan
kadim ayinin
ne zaman?

yükseltecek olsan 
yakar seni
sözlerin
ışık sanıp izlediğin
şeytanlarına 
verdiğin.


How I became a computer engineer

 

Ege University Computer Engineering Department, July 2021

I enrolled in Ege University in 1995 and graduated from Computer Engineering Department in 2000 with bachelor's degree. During that period, my dear professors worked really hard to create a computer engineer from me :) 

I must salute Prof. Erden Başar, Prof. Mehmet Özel Ergen, Prof. Sinan Yılmaz (R.I.P.), Prof. Ahmet Kaşlı, Prof. Fikret İkiz, Prof. Halil Şengonca, Prof. Levent Toker, Prof. Oğuz Dikenelli, Prof. Yasemin Topaloğlu, Prof. Aylin Kantarcı, Prof. Mustafa Türksever, Prof. Ata Önal, Prof Şaban Eren, Prof. Serdar Korukoğlu; and of course the teaching assistants of that time: Osman Ünalır, Güzin Şeker, Cenk Erdur, Selçuk Kaptan, Muhammet Cinsdikici, Nur Zincir, Aziz Can Yücetürk, Aybars Uğur, Ahmet Koltuksuz, Özgür Gümüş and Tuğkan Tuğlular.

What a crew!

Thank you, thank all of you a thousand times!

Today's story is about Tuğkan Tuğlular. The course was Microcomputers. Fifth semestre. We were following the great textbook "Structured Computer Organization" by Andrew Tanenbaum. Thanks to Tuğkan's enthusiasm, every assignment of the course was forcing us to use x8086 Assembly programming language. To be honest, Tuğkan was always giving us the freedom of using any applicable programming language but somehow all of us were using Assembly :) Here is the famous assignment:


The task was clear. Connect 2 computers through serial port (nowadays there are no serial ports on computers) and let those computers simultanously send files, chat messages, mouse pointer locations to each other. During all those operations, current system state must be reflected on the screen online. Of course, it was said that "The program can be written in any programming language..." as the last sentence of the assignment :))

During my undergraduate education, I have submitted many computer programs that were designed to solve many different problems. Those were developed by using Pascal, Quick Basic, C, Parallel C, Visual Basic, Delphi, PL/1, Java, even GPSS and of course, Assembly. However, I was sensing that the assignment above was a bit harder than others. First of all, you must be programming the Intel 8251 chip in a perfect way to meet the criteria of simultaneous communication. Keeping the integrity of the transferred data was another challenge: Which bit is beloging to mouse position data, which one is carrying the information of the file transfer or chat data? Data packages must be encapsulated well. Data loss must be avoided so you need a robust communication protocol... 

Actually, in the Microcomputers course, it was an obligation for students to understand what is going on under the many layers of the abstractions of microcomputer systems. What bare metal is capable of. How it is possible to come up with unversal solutions given a very limited hardware capacity. By assigning such difficult term projects, Tuğkan was knowing that the classroom was developing a sort of computational mastery. His project management philosophy was also astonishing :) He was saying "Guys, if I give you 1 month, you'll deliver after 30 days; if I give you 1 week, you will deliver on 7th day; if I say 3 days, you will deliver on the 3rd day. So why should I wait?". It was valid :)) And it still is valid.

Anyways, challenge was accepted in 1998 and we built the project team of three: I, Yılmaz and Volkan. In the old days, only available microcomputers to us were in the department building. In the dormitories or homes there were no computers. Therefore, we had to design the software on paper firstly. Then, we should have reserved a computer in the microcomputers lab of the department, and complete coding/compiling etc. there, in that given time slot. 

We shared the tasks in a way that I and Yılmaz were to develop the communication module and Volkan was going to develop the graphical user interface. In the dormitory, we designed the Assembly program on paper. A sample piece of note is below:


After the designs had been completed, we got to the lab and coded the program by following our notes on papers. Then, the miracle happened. 
We compiled the code. 
No errors. 
Okay. 
We linked the program. 
No anomalies. 
We started the executable file. It just worked well! 

For a third year computer engineering student, in such a challenging project, and the given complexities of Assembly programming language, it was just a miracle. I am still remembering my feelings of satisfaction and how we celebrated the moment. A couple of pages of the program listing is as follows:



At the end, it was just another assignment. But the meaning of this assignment to me is tremendous. The time we ran this program in our first attempt with no errors was the time I evolved into a computer engineer.

After that moment, I have developed millions of lines of code in many years. Even today, I know that some of my programs are running on some servers, in a confident way. It just gives me a warm feeling. I loved computer engineering. I am still in love with my profession and all the underlying science. In the last years of my active software development, I was setting such challenges to myself: "Tester will never find a single bug after I deliver my program" or "The developer who will be examining my program after me will adore me and my level of engineering" :) Fun times...

I am a very lucky guy because even today, I am so privileged to be a colleague of Yılmaz and Volkan in Yapı Kredi. And again, thank you Tuğkan for transforming me from a student into a professional.

Respect!

Forget about Failing!


Agile mindset and culture have been promoted for years. Organizations are getting slimmer, hierachies are vanishing, the world is trying to do everything through scrum teams. People are thinking on post-its, working with post-its. Humanity is doing digital transformation with post-its. Perfect!

Coaches, facilitators, mentors, consultants and all the other members of the familia are cursing the "old school" doctrines, burrying the wicked waterfall software development method, so on and on...

And of course the notion of failing! 

"Fail fast, fail often" motto, told by literally every one to every one. Written everywhere. People like the shocking effect of the slogan which is a linguistic poison in my idea. 

The word "fail" is being repeated so often and pervasively that it starts to disturb the mindsets of the young professionals. I am against the tendency of promoting failure culture. And never praise it.

Of course, it is easily understandable that the people who are advising to fail for success are aiming to emphasize the importance of learning new things about the universe. This is not a new notion. It is called "trial and error", one of the fundemantal methods of learning and problem solving. The issue here is that, it is not the perfect way of problem solving. Actually, it costs more when compared with the alternative ways. It is possible to learn things without failing. 

Moreover, it is not proper to start projects with the "failure in your mind". Nowadays, the narrative came to a point that, as if it is impossible to be successful without failing. It is not correct. It is shallow. It is a reflection of a way of popularism which praises mediocrity. Saying "you can be an average person, don't worry, there is a method to save you: if you fail enough, you'll be victorious at the end". It is not true. No ultimate methods can save you. Extraordinary people and extra ordinary events shaped the history and marked the characteristics of humanity. Repeatable methods merely work well if you want to scale up with average masses. Therefore, if you are to launch creative initiatives proposing real added-value, failure driven iterations are not the ideal paths to follow.

Let's look at problem solving.

When you face a problem in your way, in most of the times, you use heuristics to find a solution. It's a much more faster and efficient method than trial and error is. Or you may apply algorithmic approaches for solving the problem. Or you may follow trial and error. However, if you don't have any hypotheses before starting the trial and error process, you end up with no information gain. So the main goal in problem solving is to gain new information to apply to the problem and it is obvious that there are many ways of information gaining, or learning, methods in the world. You don't have to fail to learn. In most of the times, success is not a function of your knowledge and competence. Environmental factors, let's call them context or ecosystem dynamics, are playing a crucial role. If you analyse the journeys of a set of startups, you can see that successful and unseccessful ones are doing exactly the same things. I wonder how deterministic failure prophets would explain this situation. Methodologically, there is no lock-in to failure driven prodecures, there are better alternatives of reaching success.

Take the motivational factors. 

You need to feel the fire and the desire for success while you are starting things up. Failure is not a catalyst in the process. You must be brave enough to take the risks and move forward after facing blocking factors in your route. The magical factor here is not how you are good at failing but how you are resilient and solid after facing obstacles. It is you, not the method. The better you are at applying the methods, the more chance you have to be successful. Virtuosity matters. And it is about practice and training. No matter what your profession is, you must separate the training session and the performance session. Train like hell. Get down, get up, read, sweat, bleed, meet people, ask questions, expand yourself and get perfectly ready to the performance. During the performance, which is your professional daily life, never ever fail. Get the job done! Get the job done every time! Get the job done perfectly! If you face unexpected situations, just improvise like Tango performers do. No one superimposes any coreography to Tango performers, they are the experts of fundemantal steps and patterns. And they improvise perfectly on the stage. They simply handle things. For being able to improvise during the performence, you had to do your training well enough. Otherwise, you will become a failure machine. And believe me, it will not make you victorious in the end.

As I am getting to the conclusion, I want to remind that implying scientific methods to business is valuable if you know the essence of the science. It is well known that science and rationalism are being used as management tools by the authorities. A government may state that "scientific norm of the human psyche is defined as XXX, if you are not in the area of XXX you must take that pill, or the authority may send you to hospital as an obligatory measure". There are many examplars of that management style. We must never forget that science is humble in nature. Science never asserts that it will solve everything about the universe or it will bring the ultimate salvation. Science always tries to minimise the grey area, finds some variables for explaining some situations under well defined conditions. In most of the times, science gets back to you with greater but new questions, new unknowns. It is a never ending spiral. Therefore, proposing some formulae as an ultimate solution to a problem in business is almost always shallow and it is a sort of fashion. People may refer to scientific research outcomes for fortifying their formulae. It changes nothing. Be a free, intellectually sufficient, brave, hard working and creative person. 

On the stage, never ever fail!    

An Algorithm for Composing Articles on AI

 

A typical AI Image

1. Pick a big real life problem which has not been solved yet
2. Write the title of the article by following the grammar below
    Can AI solve [Problem_Name]?
3. Introduce the concept of AI and its brief history
4. Introduce the nature of the problem you selected in bullet 1
5. Present available data
6. Present possible AI methods to apply for solution
7. Stress on the shortcomings and barriers that prevent you devising the AI methods presented in bullet 6
8. Stress on the future possibilities and hopes
9. Pick an image combining binary numbers, brain, electronic circuits, robot head or hand and human head or hand (e.g. the image above) and embed the image in the article
10. Publish

İç = Dış

İnsanları dış görünüşlerine göre değerlendirmemek konusunda hayatımız boyunca birçok farklı otoriteden ders veya öğüt alıyoruz. Çok masum, yerinde ve anlaşılır bir önerme gibi görünen bu öğüdü biraz inceleyelim.

İnsanlar hakkında yargıya varmak için onların dış görünüşü yerine iç dünyalarının durumunu kıstas olarak almak için kişilerin iç ve dış yapılarının birbirinden bağımsız ve ayrı olduklarını önden kabul etmek gerekir. Dolayısıyla, bu öğüdü hayata alabilmek için fenomen/numen, öz/töz felsefi ikilemleri ekseninde düşünür ve yaşar olmak lazımdır. Oysa, felsefenin ontoloji dalı dünyayı algılamanın bambaşka yolları da olabileceğini anlatır. Örneğin, Spinoza'nın tekilci yaklaşımına ben daha yakınımdır. Halk arasında böylesine bir erdem vasfı yüklenmiş "insanları dış görünüşüne göre yargılamama" önemesinin bir felsefi dayatma barındırması dahi altyapısının evrensel olmadığına işaret ediyor bence. 

Konuyu fazlaca teoriye boğmadan örnekler üzerinden devam edeceğim ama öncesinde durumu nasıl ele alacağımı bir mantık kurgusuyla izah etmek istiyorum:

1. Diyelim ki insanlara şeklini, dış görünüşünü veren çeper oldukça katı ve insanların daha değişken ve esnek olabilen iç görünüşlerini perdeler nitelikte (Şekil 1). Bu durumda, iç dünyanın malzemesi iç dünyanın sınırı ile dış çeper arasındaki boşlukları zamanla dolduracaktır. Aynı bir kabın içindeki suyun kabın şeklini alması gibi.

Şekil 1: Katı dış çeper, esnek iç çeper

2. Diğer bir olasılık, insanlara dış görünüşlerini veren sathın esnek olduğunu kabul etmektir. Bu durumda, iç ve dış dünya arasındaki doğal gerilim ve farktan doğan denge insana zaman içerisinde değişebilen ve iç dünyanın yarattığı güçlerin dışarıya şeklen yansıyabildiği, aynı şekilde dış dünyadan gelen etkilerin de içeriye rahatlıkla şekil verebildiği bir düzen sağlar (Şekil 2).
Şekil 2: Esnek dış çeper doğal iç-dış kuvvet dengesiyle şekil alıyor.

Bu iki koşulda da iç dünyaya şekil veren çeper ile dış görünüşü sağlayan çeperin birbirine eşitlendiğini görüyoruz. Sınırlar ve limitler konusu bu yazının çapını aşabilecek derinlikte olduğundan ayrıntısına girmeyeceğim ama nesneye şeklini veren daima onun sınırlarıdır. Bu yüzden çeper benzetmesi üzerinden değerlendirme yaptım. Aslına bakarsanız, üçüncü bir durum daha var: İç dünyanın çeperinin katı, dış çeperin esnek olması. Bu da benzer bir sonuç verdiğinden, uzatmamak adına ayrıca yazmıyorum.

Eğer yukarıdaki analizim doğruysa, iç daima dışa eşittir. Yani ne görüyorsak, onu okumayı bilmeli ve o ölçüde yargılar geliştirebilmeliyiz. Yapısal çözümlemeyi bir yana koyup da pratik hayata biraz daha duru bakabilsek yine benzer bir notaya varırız bence. Bir insana baktığımızda, o  kişiye dair apaçık görebildiğimiz binlerce ipucu ve bilgi sağlayıcı varken, kişinin ruh dünyasına dair mistik tahminlerde bulunmak çok daha karmaşık ve masalsı değil mi? Ockham'ın basitlik yasasına göre davranmakta fayda var: Bir olay iki farklı yöntemle açıklanabiliyorsa basit olanı takip et. Örneğin, bir adam ceketiyle pantolonunun rengini uyduramamışsa onun estetik kabiliyetlerinin ve öz-algısının biraz düşük olduğu yargısına varmak çok doğrudan, açık ve delile dayalı bir yöntem. Ama toplumsal öğüt bize neyi öneriyor? Renkleri tutturamamış olabilir ama yine de estetik açıdan gelişmiş ve öz-algısı yüksek biri olabilir. Belki de uygun renkte giysi alacak parası yoktu. Belki, evindeki ayna kırılmıştı. Hemen yargıya varma. Bu bakış, çok daha dolaylı, istisnaları hep göz önüne almayı gerektiren ve kişiliğin dışa yansıma niteliğini yok gibi kabullendirmeye çalışan bir yaklaşım. Sade değil.

Çocuklar, belli bir yaşa gelip de toplumsal kurallarla törpülenene kadar gördüklerini okumak konusunda çok net ve başarılılar. Mesela, bir doktor elinde iğne ile yaklaşıyorsa, annelerinin "acımayacak, korkma" kabilinden sözlerini pek dinlemez, ordan uzaklaşmaya çalışırlar. Oysa biz yetişkinler, hareketleri anlamlandırmak konusunda neredeyse körleşiyoruz. Tam tersine, sözlü ve sembolik mesajlara aşırı anlam ve değer atfettiğimiz bir hayat kuruyoruz kendimize. Hikayeler yaratıyoruz bol bol. Hem de başkalarının sözleriyle çerçevelenmiş hikayeler. Örneğin, iş hayatında bir yönetici eline birkaç defa fırsat geçtiği halde sizi hiçbir zaman terfi ettirmiyor ama sizinle çok olumlu konuşmalar yapıp, neden başkasını seçmenin daha doğru olduğunu izah ediyorsa, bu diyaloğun, söylenenlerin yarattığı tat ve yankılarla yaşamaya yatkınlık gösterirsiniz. Sözler ve bıraktığı tatlar ve kafanızda kurduğunuz hikaye ile yaşayıp gidersiniz. Doktor iğneyle yaklaşıyor olabilir, önemli olan size söyledikleridir(!) Sizce doğru olan bu mu? Yoksa apaçık görüneni okumak mı?

Masallar, kıssalar, atasözleri ve birçok kültürel etmen bizi görünenden koparmaya hizmet ediyor nedense. Kurbağayı öpersen prense dönüşür. Padişah kılık değiştirip halka karışır. İyi görünen kötü çıkar, fakir görünen zengin çıkar... Dahi profesör diye bir tipleme vardır mesela, tüm davranışları, saçı, sakalı saçma sapandır, tırnakları pistir ama çok iyi icatlar yapar. Bunun gibi körleşmeyi öven, yanılsamayı ana akım değer haline getiren bir sistemde bulunuyoruz. Acaba sebebi nedir?

Kendi hayatımdan bir örnek vereyim. Yıllar önce, veritabanı sistemlerimizin tasarımı ve yönetimi konusunda bir yabancı danışmandan hizmet alıyorduk. Danışmanın hali, tavrı, görünüşü hoşuma gitmiyordu. Mesela, aynı kişiyle 4-5 kez tanışıyordu. Unutuyordu tanıştığını. Vücuduna hakim değildi. Kıyafetlerini kendine yakıştıramıyordu. Yemek masasında çatal/bıçak hakimiyeti zayıftı. Çoğu zaman parmaklarıyla destek yaparak tabağındaki yemeği çatalına alabiliyordu. Şöyle düşünmüştüm: Bu danışman kendi hayatını tasarlayamamış vaziyette, bizim sistemlerin tasarımı konusunda ne fayda sağlayacak? Neticede bu kişi bir rapor yazdı ve gitti. Biz de işimize baktık, pek bir fayda sağlanamadı.

Diğer bir vaka: Yaşanan bir teknik talihsizlik nedeniyle birçok kişi sosyal mecralarda son zamanlarda normalden uzun mesajlar paylaştı. İçeriği bir yana, mesajların çoğunda imla bozuktu. Bence bu bir göstergedir. İmlası, grameri bozuk biri, iyi matematik de yapamaz, duru bir zihinsel yapı da kuramaz.

Kulağınıza önyargı gibi geldiğinin farkındayım. Elimdeki öncü bilgilerle yaptığım yargıdır, doğru. İlerde daha çok bilgi edinirsem, yargılarımı da düzeltirim. Ama asla gördüklerimi yadsıyıp insanların ruhi durumları hakkında masallar uydurmaya çalışmam. Neyse ki tarihte böyle düşünen tek kişi durumunda değilim. Abartılı bir yöntem de olsa fizyognomi adında bir yaklaşım var. İnsanların yüz ve uzuv şekillerine göre derinlemesine karakter genellemesi yapma teknikleri bütünü. Yüzyıllar boyu devletler, istihbarat kuruluşları vb. yapılar bu tekniklerle insan tanımlamaya çalışmışlar. Eğlenmek için incelemenizi tavsiye ederim. Ayrıca, kültürel kodlarımızda beni destekleyen sözler de var: "testide ne varsa dışarıya o sızar" iyi bir örnek.

Görebildiğimiz kadar çok görüp, o ölçüde kararlar vereceğimiz; her şeyi bilip, hiçbir şeye körü körüne inanmayacağımız bir dünya da mümkün. Yeter ki ışık olsun.

Regressive Progression of Technology

 

Tablet 5 of the Epic of Gilgamesh

Some of my friends know that I have been talking about regressive progression of the technology for at least 7-8 years. After years of small talk, now it is time to write about it. 
I cannot say I am the inventor of the term "regressive progression". When I scan the literature there are three references containing the term: One is in the field of arts, the other is in zoology and the last one is Henri Lefebvre's sociological analysis approach called regressive-progressive method. Therefore, my type of use of the term can be accepted as an authentic one because it is purely on the interpretation of the technological advancement. However, it is obvious that this post has no academic qualities, this is just a personal attempt to put a note in the eternal history of the Internet.

In my opinion, when a particular technology reaches a certain level of maturity, its use case reflects the first use case of the phenomenon in the known history. Tablet may be the most understandable example: In the history, mankind used clay tablets for recording, spreading and categorizing information. Then leather used for this, then papirus, then paper, then digital computers connected to keyboard and CRT displays, then LED displays and after years of progression we are using tablets again. Even the name is the same: Tablet. Think about the use case: A human being holding a tablet for reaching information. Totally the same. As if nothing happened in thousands of years, as if technology has progressed for re-creating the regressive way of the use case.

The other example can be the method of barter in trade. We know that barter is the first type of trade in the history which works like this: Peers are exhanging their products directly with each other instead of using any intermediaries or medium of exchange such as money. Then think about the progression of global trading system: We invented money, markets, state, governments, taxation, many ways of transactions, capitalism, communism, open markets, stock exchange etc. Finally, today we again are talking about peer-to-peer direct transactions through blockchain networks. Just like barter, no entities between peers. Very similar to the tablets case, thousands of years of progression in trade system results in the re-creation of the regressive use case.

Remember the carrier pigeons used for postal delivery. And look at the drones. Again, many years of development in technology but the use case regressed.

Cell phones are examples too. People were climbing hills and shout or whistle for peer-to-peer vocal communication in the ancient times. Cell phones were introduced and use case regressed again. Think of the interim systems used in the history up to the introduction of cell phones.
 
So, if my theory is sound, what is the mechanism that supports the regressive progression of the technology? I tried to picture the idea in the charts below.

Chart 1: Number of functions a single technology can encapsulate.

Chart 2: Number of different technologies needed for a single function.

We know that technology is actually a packaged form of knowledge. Therefore, while technology is progressing in time, the level of the knowledge it represents is increasing too. As a result, a single technology becomes capable of encapsulating many functions that can work by needed knowledge underneath. Take the example of the tablets, we need knowledge for symbol manipulation, information transfer, information security, information storage etc. for the use case desired. Today, we have enough maths, Internet, batteries, silicon chips, multicore CPUs, solid state disks and some more tools embedded in a single tablet computer which can promote all necessary knowledge for the typical use case. When that level of sophistication reached, all the unneeded details disappear or eliminated and we see the simplest form of the function: A man holding a tablet for information exchange. Complex engineering serves for simplicity as I explained in one of my posts.

Okay, if this theory works fine. How can we use it? 

We can use it for futuristic purposes. In futurism, there are some methods for identifying and following trends. It's called SEPET analysis: If you're studying a topic, you must take the aspects of society, economics, politics, environment and technology for understanding the trends that may affect future. For the T of futuristic analysis, you can use regressive progression interpretation way. I already have used it for cars in one of my LinkedIn comments. Of course, it was a sudden analysis saying that there will be hyper powered shoes for personal mobility purposes. The route of the analysis was like this: Humans were on foot, then shoes, then animals, then cars pulled by animals, steam cars, petrol engine cars, electric cars. We are here now. My regressive progression estimate may tell that there will be electric powered shoes which will make the cars or bikes obsolete for personal mobility puposes. 

It may be true or not but I believe it worths thinking a bit more :) 

B-right

 

that yellow light
in my heart
I thought I forgot
as safe as home
as far as winter star

wise and bright

remember 
for what once god sacrified
his eye on the right

so 
smile
reach
touch
sober or not
just ignite.

İlham

 

Euler's Identity

İlham kelimesi son zamanlarda birçok sahada ön plana çıkarılıyor. İlham veren liderlik, ilham veren girişimcilik hikayeleri, ilham dolu tasarımlar, ilham ile tetiklenen duygusal arınma maceraları, kişisel gelişim yolculukları, TED konuşmaları ve varyasyonları... Listeyi uzatmak mümkün.

Kabul etmek gerek. Güçlü ve çekici bir ibare ilham. Eskiden sadece sanatsal yaratımla ilişkili kullanılıyordu, artık birçok alanda, özellikle de motivasyonla ilgili temaları bezemek için biraz da kolonileştirilmiş bir biçimde vurgulanmakta. İş dünyası "heyecan" kelimesini de bir aralar benzer biçimde tepe tepe kullanmıştı. Projeler, girişimler, operasyonlar, pozisyonlar hep "heyecanlı" diye nitelendiriliyordu. Coşku eksiğini derinlikli bir jargonla ama bir o kadar da mekanik bir metodla bertaraf etme çabası gibi algılardım hep.

İlhamla ilgili en güzel düşünce rotalarından birine birkaç yıl önce rastlamıştım: "Create inspiration from your limitation". Kulağa hoş gelen bir slogan olmasının yanında, analiz edildiğinde güçlü bir argümana da dönüşüyordu:

1. Sınırlar, iyi okunursa bir çerçeve çizmene yardım eder
2. Çerçevenin tutarlı olması için çerçeveye dair kurallar yaratman gerekir ve bir şablon oluşturursun
3. Şablon dahilinde kural ortaya koyma çabası yaratıcı bir faaliyettir ve zeka ister
4. Yeni kuralların yeni sınırlar yaratır

Murat Pak'ın bir yazısında rastlamıştım bu mantık silsilesine. Orijinali İngilizce'ydi ve biraz daha akışkandı: Limits>>frames>>frameworks>>rules>>intelligence & creativity>>new limits.

İlhamın kaynağı hala birçok disiplinde araştırılıyor. Samuel Taylor Coleridge tarafından afyon etkisinde bir rüyadan kalkıp bir anda yazılan Kubilay Han şiirinin hikayesindeki gibi gizemli düşlerden beslenenler, daima ayakta yazmak veya uzun yürüyüşler yapmak gibi günlük ritüelleri ilhamın tetikleyicisi olarak görenler, bir kişiden ya da öğretiden ilham alanlar, çok çalışarak ilham kaynağını canlı tutacağına inananlar gibi birçok örnek var. Kesin cevap bulunmuş değil.

Kendi yaşamıma baktığımda, çocukluk ve gençlik dönemlerimde ilham veren uyaranların kısır olduğu bir iklim vardı diye anımsıyorum. Uyaranlar azdı ama ilham vardı. Devlet parasız yatılı adında bir müessese vardı, hala devam ediyor mu bilmiyorum, biz o çerçevede okuyan yatılı fen lisesi öğrencileriydik. Doksanların başı. Televizyon kısıtlıydı mesela kantinde. Yarım saat filan Murat Murathanoğlu tarafından sunulan NBA Action programını izler, ilham alıp 4-5 saat basketbol oynardık. Lise takımımız il bazında başarılıydı. Birçok arkadaşımız iyi üniversitelerde okudu, yurt dışında okuyup çalışanlar, üst düzey rollerde çalışanlar eksik olmadı. Güçlü bir rehberlik veya yönlendirme yoktu, gezip üniversiteleri önceden inceleme şansı da yoktu. İlham kaynağımız ÖSYM sınav kılavuzuydu. Üniversiteler, bölümler, geçen yıl uyguladıkları taban puan ve kabul edilen öğrencilerin yüzdelik başarı dilimleri bilgilerine günlerce uzun uzun bakar "vizyon" geliştirirdik. Bir kampüs hayal ederdik. Bir okul. Bir meslek... Bölümün adından ilham alırdık. Taban puanından ilham alırdık.

Dünyaya açılan pencerelerimiz kısıtlıydı. Mesela TÜBİTAK'ın o zamanlar küçük boy yayımlanan Bilim ve Teknik dergisini evire çevire okur, düşünürdük. Bir ayin gibi tekrar tekrar aynı dergiyi okumak. Düşünmek, okumak... Aklımda durumu iyi özetleyen bir imge kalmış: Bir Pazar günü, karanlık bir öğlen, pansiyonun alt katında demir muhafazanın içinde birkaç kanalı zar zor çeken bir tüplü televizyonda kalitesiz bir program açık; Doğu Anadolu'nun uzak illerinden gelmiş bir öğrenci Mehmet İsmet Ulusoy tarafından yazılmış Modern Matematik kitabına çalışıyor. Bir saman kağıt, bir kurşun kalem. Bir masa. Bir soruyu çözmeye çalışıyor. O öğrenci ODTÜ Bilgisayar Mühendisliği bölümünü kazandı ve uzun yıllardır kurucusu olduğu çok başarılı bir yazılım şirketinde CEO rolünde. Faaliyet gösterdiği sektörün kanaat önderlerinden biri. İmkansızlıklarla dolu o loş televizyon salonunda ilham veren hiçbir şey yoktu. İlham almayı bilen istekli bir çocuk vardı. Kısıtların içinde derin düşünen, bilgi üreten, çözüm geliştiren bir çocuk.

Güzellik bakanın gözündedir derler ya ilham da onu alabilen, bir vizyon yaratabilen, akıllı kişilerce yokluklar içinden dahi imbiklenebilecek bir olgu bence. Fakat, daima sergilendiği gibi, hikaye biraz tersten işletiliyor. Mesela, Sir Isaac Newton ve elma ikilisinde ilham veren elmadan daha çok bahsediliyor. İlham alan Isaac ikincil bir figüre dönüşüyor. Yıllar sonra kurulan şirkete Isaac değil Apple adı veriliyor. Veya birçok kursta ilham veren liderliğin "sırları" öğretilmeye çalışılıyor ama ilham alabilmenin koşulları çoğu zaman es geçiliyor.

Konuyu özetlemek gerekirse, ilham alabilme konusu bir insanın yaratcılığıyla, arzularıyla ve zekasıyla ilişkilidir bence. İlham vermek ise etrafınızda bu ayarda insanlar yoksa sadece bir imkansızlıktan ibaret.