how not to do? ep.1: Capstone Project
In this letter series -how Not to do?-, I want to talk about the things I have done wrong and even doing wrong. In this oversharing era, people prefer to talk more about the things they have done, accomplished or won than the bad experiences. And I even find the way failures are talked about mostly disingenuous. Most of the speeches in a conference or motivation day are about success stories, maybe one or two of them just mention “Don’t be afraid to make mistakes!!”. Even fucked-up nights are designed to observe success stories behind the failures. “Yes I fucked-up 1 million but you know what?? I made more than I fucked-up in last year ;)”. Since mistakes are so important, as a young, and junior developer, I felt that I had to say something about it as someone who makes mistakes frequently. In this series of articles, I will talk about the mistakes I made in my business and social life.
Episode 1: Capstone Project for Engineering Students
Since the subject is still hot for me, I want to start with the most epical failure of my college life, THE CAPSTONE PROJECT. Before I start, I have to point out that I did not fail the course. I had to disclaim that at the beginning of this subject because I don’t want to be judged with “you did the same thing with the people you judge!”. If I did not fail the course, you might say, what is a failure story in this? At this point in the topic, we need to talk about definitions of success and failure, which will be too complex for me to philosophize about. So, as juniors who love to read documentation, let’s take a look at the definitions on the engineering side of the subject.
When you look at the books about software projects’ management, you can see that most of them define success as “satisfying all predetermined requirements of all stakeholders of the project”. Failure will be the opposite. With a deeper look, you will see the keywords: functional & non-functional requirements, time, and money are the key points of measuring success. If you examine each keyword in more detail, you will understand the concept better; but this is not the place for this letter.
Firstly, I want to describe the CAPSTONE PROJECT to clarify how important this project is to graduate. I would like to tell you in another article that being a programmer with a diploma is not that different from the process of struggling with a lot of procedures that will not work for you in the industry but I have to mention it: “GRADUATING FROM COLLEGE IS NOT THE BEST WAY TO BE A DEVELOPER!”. Even though I’m speaking as if studying at college is not good, remember that my meaning in these sentences is about unnecessary procedures. After these disclaimers, let’s define it. Basically, the Capstone Project is the name of a graduating project in many colleges. I am writing you the answers to the “Why Capstone?” question by quoting directly from my university, Bahcesehir University.
“As an outcome of an engineering education, a student should be able to solve and communicate a complex engineering problem in an interdisciplinary environment making creative use of fundamental engineering principles, knowledge and skills that they acquired during their undergraduate program. The capstone project acts as preliminary practice for real-world experiences with focus on good engineering principles, value to society, and innovation.”
I think the main problem about this system is the answer to the question “How many meaningful, valid, brand-new projects are there in the world our students can make?”. In this system, which clusters dozens of projects consisting of repetitions of each other, the project that we put in the first place in our preference list and which was assigned to us at the end was a mobile application project. And, everything had begun..
For the project we were 3 Software Engineering students and 2 Management Engineering students. The project was simple. We needed to make a mobile application about Corona, which was like a savior to the Turkish academy, which had already lost its ability to generate ideas. The main function of our app would be to show how many vaccinated/unvaccinated people are around.
Since we’ve defined failure from an engineering perspective before, the question “Why do you think your project failed?” Let me answer your question. We screwed up badly in planning, we missed a bit of the functional requirements of the project, and we overqualified the non-functional requirements of the project a bit in the planning and execution phases. In conclusion, I can say that the two main keys that make the project fail are over-self confidence and bad planning.
First reason for failure was about the general definition of the project which contains job descriptions, functional & non-functional requirements, and blurred deadlines. As a Software Team we were thinking that the other team has the major impact and responsibility on the project and they were thinking the exact opposite. And we did not talk about it, until it was necessary. We had some strict ideas about implementation of projects such as technologies, designs. These strict ideas caused overconfidence and this overconfidence between closed friends caused delays in the planning phase.
Second reason for failure, again it was basically a planning mistake, was about implementation of ideas. We knew which technologies would be used in the project but We ignored our inexperience about using those technologies. Combined with this ignorance and poor planning regarding the times when work needs to be done, we all have one monitor filled with training videos or documents and another with work to deal with. For example, I strictly decided to use Flutter for development of mobile apps. But, did I check that there are any packages for our functional requirements? NO, ABSOLUTELY NO… As a junior developer at my level of knowledge, I could not create a map package that contains heat-map layers and the official Google Maps Flutter package has no heat-map layer support. When I recognized that situation, ignorance had begun and we focused on all the other developments. All the last week of the project was just about this function, and it was not joyful, I swear. If there’s even something not fun about the projects, it is not a successful project at the end even if all the problems are handled.
Third reason for failure was about technical issues and the ways we try to solve them. As I mentioned maybe thousands of times before, the time problem caused us to not spare enough time for technical problems and to not find best-practice solutions for them. When I look at my first and last commit on Github, I can see the difference between an engineer’s hand, and a building contractor ‘s hand from Trabzon, Turkey. In the beginning, I was paying attention to the architecture I was trying to construct; lately, I could see the codes getting longer and disappearing in themselves.
Conclusion in one sentence: make a good plan and take two badass developers before you start anything.
