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.
 

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!