First Project

My first project as a second year student in degree, the horror that still remains.

Background

At the time of this project, I was learning Java, a new language included in our curriculum. It was introduced to familiarise us with Object-Oriented Programming (O.O.P.). I had just entered my second year and wasn't familiar with most people or their talents. When the faculty announced that we had to create a group project, there were two options:

Two projects for each semester.
One project spanning both semesters.

I chose the latter for a simple reason: I could complete the entire project in the first semester and relax in the next. Initially, this seemed like a good plan, but boy, was I wrong.

The Hunt

It was the start of the second year, and the lingering effects of COVID-19 continued to shape our college experience. The first year had been entirely virtual, conducted through Zoom meetings where faces remained largely unfamiliar despite attending lectures together. As the new academic year began, the situation mirrored the previous one: COVID was slowly receding, yet physical attendance at universities remained restricted. Amidst this backdrop, our only real connection remained the virtual realm of group chats. With the announcement of a new project, everyone rushed to form teams, and I found myself in a fortunate position. Despite my limited visibility during lectures, where I was known just enough for my name to ring a bell, my role as a supplier of assignments and academic information had garnered me some recognition. People eagerly sought to join my group, and I didn't have to search far for willing collaborators.

However, the challenge lay not in finding members, but in selecting them wisely. I faced a dilemma: how to discern between potential teammates when I lacked insight into their skills and personalities. Rejecting anyone based solely on their name seemed unjustifiable. To navigate this, I decided on a pragmatic approach: I formed a group with the first three individuals who expressed interest. My plan was to distribute tasks evenly among us, fostering a collaborative spirit where we could support each other if anyone faced difficulties with their assignments. Looking back, I realise now that this strategy had its shortcomings. Had I known better, perhaps I would have taken more time to assess each person's strengths and compatibility before hastily forming our team.

Project Selection

Since the project group was formed, I had extra brainpower to find topics for the project. The project was to be decided by the group, and the faculty would approve it. At first, we thought this was a blessing since we could tailor things to our skill set. However, it was later revealed to be a curse. It turns out that when students are given an open field, they don't roam the entire ground but instead get confused about where to go. We got caught in the Paradox of Choice; there were so many things to do, and all of them seemed tempting.

We made a list of potential topics based on the small amount of programming experience we had. The topic we picked was an attendance manager. We had no idea how to make it, but it seemed easy on the surface; we just had to figure out a way to mark attendance using software instead of pen and paper. 'What could go wrong?' we said to ourselves.

Turned out, a lot did. At that point the only program we had ever written was in C, which was a hello-world program.

We gave the project for approval, and apparently, it got approved. Whether the faculty had high hopes for us or just wanted to mock us is still a mystery to me.

The Tragedy

The group was formed, the project got approved, and a separate group chat was established specifically for the project. Everything seemed set, except for one little thing: no one had any idea what to do. We were a bunch of students, excited to create our first-ever project, but none of us had any prior experience with such endeavours. We had skipped an important step during project selection: deciding on the architecture and tech-stack. Which programming language should we use? What kind of software should it be—a command-line interface (CLI) application or a full graphical user interface (GUI)?

Being new to software development, our initial reaction upon seeing a terminal was that it was something only hackers used. Therefore, we unanimously decided to create a GUI application. By our second year, we were not yet familiar with any Integrated Development Environments (IDEs) or the concept of using them. Most of the programs we had written until then were so small that Notepad sufficed for coding. In our naive minds, we thought Notepad was the tool everyone used to write programs (later discovering that all IDEs are essentially fancy versions of Notepad).

We chose to write our program in Java because it seemed more user-friendly than other languages, and C was too intimidating for us at the time. We had heard stories about the disastrous consequences of improper memory allocation, which further influenced our decision.

We began our journey by compiling a list of tasks and skills necessary to complete the project. The initial checklist looked something like this:

Master the art of creating a user-friendly GUI (Graphical User Interface).
Discover an effective method to store student entries securely.
Develop a reliable system for recording attendance.
Implement attendance marking through intuitive GUI buttons.
Ensure that our solution surpasses the efficiency of traditional pen-and-paper methods.

Each item on the list posed its own challenges, pushing us to learn new technologies and refine our approach as we progressed towards our goal.

We distributed the tasks accordingly. Given my existing knowledge of Java, I had a head start and proposed, 'I'll begin working on the GUI. Meanwhile, the rest of you can focus on mastering Java to handle the logic for storing and marking attendance.' Perhaps, I placed a bit too much trust in my team.

I started writing code with my trusty notepad and a terminal. Since I didn't use any IDE, I didn't have the luxury of pressing a button to compile and run the program. Instead, I would write a few lines of code, compile it, and then run it. Without a debugger, I wrote the entire 600 lines of code using this approach. Initially, it was tedious, but over time, the process of compiling and running became almost seamless, as the code would execute correctly on the first try.

I finished the GUI using dummy functions, which consisted only of print statements. After completing this part, I handed over the code to my teammates, assuming that since they had been learning Java, they would be able to handle the remaining logic—it was just CRUD operations, after all. Right? Wrong. I couldn't have been more mistaken. It turns out not everyone shares the same interest in coding as I do.I am not saying what i wrote was a master piece the thing looked like this.

public void Month_update(String input) throws EncryptedDocumentException, IOException{
		fis = new FileInputStream(fileName);
		wb = WorkbookFactory.create(fis);
		sh = wb.getSheetAt(Sheet_index);
		no_of_row = sh.getLastRowNum();
		int roll = Integer.parseInt(input);
		row = sh.getRow(roll);
		
		c1=row.getCell(1);
		int temp1 = (int) c1.getNumericCellValue();
		c1=row.getCell(2);
		int temp2 = (int) c1.getNumericCellValue();
		c1=row.getCell(3);
		int temp3 = (int) c1.getNumericCellValue();
		c1=row.getCell(4);
		int temp4 = (int) c1.getNumericCellValue();
		c1=row.getCell(5);
		int temp5 = (int) c1.getNumericCellValue();
		c1=row.getCell(6);
		int temp6 = (int) c1.getNumericCellValue();
		c1=row.getCell(7);
		int temp7 = (int) c1.getNumericCellValue();
		c1=row.getCell(8);
		int temp8 = (int) c1.getNumericCellValue();
		c1=row.getCell(9);
		int temp9 = (int) c1.getNumericCellValue();
		c1=row.getCell(10);
		int temp10 = (int) c1.getNumericCellValue();
		c1=row.getCell(11);
		int temp11 = (int) c1.getNumericCellValue();
		c1=row.getCell(12);
		int temp12 = (int) c1.getNumericCellValue();
 
		Jan.setText(Integer.toString(temp1));
		Feb.setText(Integer.toString(temp2));
		Mar.setText(Integer.toString(temp3));
		Apr.setText(Integer.toString(temp4));
		May.setText(Integer.toString(temp5));
		Jun.setText(Integer.toString(temp6));
		Jul.setText(Integer.toString(temp7));
		Aug.setText(Integer.toString(temp8));
		Sep.setText(Integer.toString(temp9));
		Oct.setText(Integer.toString(temp10));
		Nov.setText(Integer.toString(temp11));
		Dec.setText(Integer.toString(temp12));
		
	}

The above code has only one task: to update the attendance of students. However, there's a small catch—it updates the attendance for all months simultaneously. In other words, one cannot simply update the attendance for the current month alone.

Now I had the task of handling the CRUD operations myself, which I initially thought would be straightforward. However, there was a hurdle—I didn't know how to use databases. The Java connector I tried using didn't seem to work as expected. Frustrated, I decided to abandon the idea of using a database altogether and opted for an Excel sheet instead. After all, what could go wrong?

The workflow was as follows: the user would select an attendance sheet containing all the roll numbers and names. Then, they would choose the month and simply click 'Present' or 'Absent' accordingly. This entire operation directly interacted with an Excel sheet. For this setup to function correctly, the Excel sheet needed to be properly formatted.

Only I knew the chaos unfolding in the backend, and it gnawed at me throughout the review process. While the application technically worked—not to say it didn't—it was marred by terribly inefficient and poorly written code. The magnitude of its shortcomings was so profound that to this day, it continues to haunt me.