My teacher in college, sir Elmer Buenavides, who is now the dean of the College of Computer Studies at Sultan Kudarat State University (Isulan Campus), invited me a few weeks ago to be one of their speakers (and judge of some contests) of their first PSITS intercampus convention. I first hesitated to respond positively to his invitation… because I’m not a very good speaker (I’m not an “in-born speaker” 
, if there is such a thing), and because I needed to study or review something to prepare myself for a possible interview (which will not happen anymore because of some changes in plans). But he was able to persuade me, so…
Also, the reason why I volunteered to speak at DevCon Davao last October 2017 is because of this fire burning inside about sharing these clean architecture and TDD ideas… This will be another opportunity to spread these ideas!
… I went there…
It was a very humbling experience.
They have this contest named “Problem Analysis and Solution Making”. Very intersting contest, right? From that contest, I learned that there are (at least) two analysis and design methodologies: Stuctured Analysis and Design and Object-Oriented Analysis and Design. During the judging session, most teams received lots of comments from the judges because they made some mistakes. The reason for the mistakes is because that was the first time they were exposed to that kind of contest, and they were not familiar with some of the diagrams that they were required to create during the contest.[1]
But even though the contestants made some mistakes, that was already a very good start and a very good exposure to these kinds of things.
If I had this kind of exposure during my college days, it would have been very great!
They also have the usual programming contest. The first PSITS conventions in our area did not have programming contests, so I’m happy that they have programming contests now.
During the practice session of the programming contest, I was one of those tasked to help the teams find a solution when they encounter some problems. Only four teams participated in the contest. Most of the contestants are not used to reading input from a text file so one of the facilitators, Jamen Mama, created a simple program to show them how to get input from a text file.
I can understand the frustration of the contestants about getting the input from a file because I also felt the same when I first tried to solve similar programming problems in the past. Automatically reading input from a file requires a kind of small shift of thinking. — It is just the same as reading input from a human user. The only difference is that when reading input from a file, you do not have to wait for the next input because all input is already in the file. (I remember that reading about the C++ streams library was one of the things which helped me figure out how to manage inputs from a file.)
No team was able to answer any of the practice problems. But the wonderful thing is that during the contest proper, one of the teams was able to answer three problems out of nine! Wow! Another team was able to answer one problem.
Most of the nine problems was not really hard if one has years of programming experience already. Five of the problems are what they call “ad hoc, easy” problems. Another one is also “ad hoc” but I think is it “medium hard”. The remaining three problems might still be easy to some, but they require some knowledge in algorithms and perhaps mathematics, so they are hard to me (at least for now) because I do not have a rich background in algorithms and mathematics. 
I was not in the computer lab during the contest proper because the time of my tech talk was in conflict with it. And also because I had to judge on some of the other contests.
But during the giving of awards in the evening, I was able to talk to one of the members of the winning team of the programming contest. I asked him what problems they were able to solve. They were able to solve three of the “ad hoc, easy” problems. That was a very good start. I congratulated him for solving those problems, hoping that it will encourage him to learn more and to continue in that path.
And… About my talk… I’m not sure if it was a success or not. At the end of the talk, I asked the students if they learned something. Some said they learned a little…
But I made it clear during the talk that my purpose for choosing that topics is that they might be exposed to these clean architecture and TDD ideas very early in their life (because I know that it will take a long while before an idea will sink in and consume the mind of an individual ).
Here is a picture I have during the giving of certificate after the talk:
And here is another picture of me with the guest speaker, Ms. Elizabeth Buazon (I stole this from her facebook profile ):
[1] Among the diagrams required in the contest were Data Flow Diagram and Entity Relationship Diagram for Stuctured Analysis and Design; and Use Case Diagram, Activity Diagrams and Class Diagram for Object-Oriented Analysis and Design.
I encountered these diagrams before but I can’t remember anymore the specifics about them (except ERD and class digrams perhaps). And the reason why I can’t remember their specifics is because I do not always see these kinds of diagrams at work. We do not always use them at work. And the reason for that, I think, is because of the influence of what is called “Agile” in mainstream software development. In Agile, BIG upfront design is discouraged, because in the real world requirements change many times even during the early phase of a software project. I heard from the masters that we can do tiny bits of upfront designs at the start of each iteration, but not one BIG upfront design.
It also seems to me that in Agile creating lots of documentation is discouraged, because lots of documentation is hard to maintain. I heard Uncle Bob said that a two-page document/digram explaining the entire structure/architecture of a software project will suffice — a two-page document will not be hard to maintain.
I also found, yesterday, a talk by someone named Glenn Vanderburg. The title of the talk is “Real Software Engineering”. He talked about whether or not we should call ourselves “engineers”. He talked about “Academic” vs “Mainstream” software engineering and Agile. This picture below pretty much tells the story…
