Finally, a graduate!

 

At last .. looool 😀

The Graduation Project Rhapsody

[This post is mainly dedicated to FCIS students class’09 (now senior students), and anyone else starting their graduation project or interested to know more about that issue …]

So, let’s get started. Mmm-How?! I know most of you are stuck at the point: starting up!
Well, I was there a year ago, exactly a year, and I’ve passed with the same experience. I’ll try to deliver that experience to you as much as I can in this post …

Factors to consider ..

Before starting, there are a few factors that you need to consider:

• Working Team
• Project Topic
• Technologies and Programming Languages used
• Contribution
• Roles and Time Management
• Supervisors
• Sponsors and Funding
• Documentation, Presentation and the Final Seminar

I’ll go through each of them separately through the post.

Who’s gonna fight on your side?

YES, it’s a fight! Who’s gonna back you up?
One of the most important factors in the graduation project is working team. Therefore, picking your teammates is crucial. Let’s go through what you need to notice during the selection phase:

• Background:
  Having different backgrounds has its benefits and drawbacks. Benefits appear in combining different experiences and knowledge backgrounds behind the project; giving you more space to come with better outputs. Let’s say your project includes a part that has database interaction through a rich interface. Someone who’s worked a lot with databases would help, along with someone who – let’s say – knows WPF to create the exquisite interface. In another example, someone who has worked with WebServices earlier, could help much in case you need to upload some “functionality” online for a mobile application to connect and use.
  On the other hand, “wide” differences cause problems. Different experience levels lead to one team member being more experienced, does work faster and is more efficient than the other. So, so much time is wasted in explaining, reviewing, fixing, then re-coding the latter’s tasks. Make sure you vary, but that your levels lie in some close range though.
• Commitment:
  People have different levels of commitment and “interest” to get their work done. Some don’t sleep if some task is incomplete, while others could go to the movies because someone else “will sure” do their work.
  During the project, you’ll have to assign tasks to specific persons due to some fixed dates. It would be killing that some get their tasks done, while others are sleeping or out having fun. That’s why you should all have the same level of commitment – either you all go out and to hell with the work, or you all spend sleepless nights to finish it up!
• Means of communication:
  It’s really stupid for someone who’s working online 24/7 to send another teammate the project updates in an email thread, when the later is not a “fan” of computers or the Internet, so they just don’t check their mails that often!
  You have to agree on some sort of communication method; mobile or phone calls, SMS, emails and email threads, user groups (as Yahoo!), Facebook (LOL!), Google Notebook, Visual Studio Team Suite, whatever!!!!! Just make sure your all on the same track …
• Human blending:
  Make sure there’s a minimum level of acceptance and coping between the team-members. You don’t have to be “friends”, but at least you have the needed respect and understanding to get along for a whole year!
  In a project, there are always conflicts, disagreements, problems, miscommunication, misunderstandings, and you name it! If you can’t cope, or can’t deal with other teammates, believe me there’s no time for kiddy-games! Be professional – this is a project!
  It’s much better if you could pick people you can “work” with from the start – work with is something, and friends is another!
• Grow up!
  This is a project; the closest undergraduate experience to real work. There’s no chance that you’re settling for a “bad” group just because they’re your friends for the past 2-3 years and you can’t tell them you had an offer with the “perfect” group. If you can’t work with them – then leave! You’ll lose more – all of you – with you on the team.
  It happens a lot when a team of five, one of them is much more “experienced” than the other four. This one gets an offer to join another team – a better, more experienced team, with a better project, better chances to come with better stuff. They refuse just because they can’t leave their friends! Give me a break! I’m not that mean by the way, but this is work for God’s sake, it’s not an outing!
• Departments:
  Some people pick the team (or project topic) according to the departments you join. If you’re working hard from the beginning of the year, it won’t make much difference. Let’s say your project does some Image Processing, you won’t study that unless you are in the first semester in Computer Sciences Department. If you started your project already before taking the course, then you being in this department makes no difference as you haven’t taken the course yet. Of course, if your lazy enough to start by the middle of the second semester (and for sure, it’s not a huge project then), well, only then it may differ.
  Always keep in mind, if your project needs a certain topic to be studied, then go study it and do some research, don’t depend on a department or a course. You can pay any professor or TA a visit to help you out, then you’ll still have to work on your own.

Deciding on the project topic ..

Most topics you’ll think of are either ..

• .. too easy (a website doing a usual task),
• .. repeated (a tool implements one or two features of a $5,000 package, where you feel you’ll be doing like 1/10 of the real thing and like 10% of its efficiency),
• .. too old (because you’ve seen it zillions of times online, free, commercial, and already submitted to college in previous years by your ancestors),
• .. or too hard (operating system? game engine? may be in ten-years!)

Well, it’s totally WRONG to see it that way!

The graduation project is not an assignment, it’s not a task to be delivered tomorrow. It’s a challenge; where you get to prove you’ve learnt something. It’s a proof of concept; prove you can make it, you don’t have to go through the whole thing to do so. It’s an experiment; apply a concept, bring it to life. It’s your contribution; add something to the world.

So, again, let’s go through those four types ..

• Easy: Build an easy website, or a common tool, but add something new to it. If it does the usual task, no addition, no contribution, no application of some theory or concept, AND easy? Then NO!
  As long as there’s something unique about it, something that makes it “different”, then OK …
• Repeated: Adobe has their Photoshop, Autodesk have their Maya, Microsoft have Visual Studio, so what’s the point of re-building an image processing package, 3D modeling package, or an IDE and/or  a compiler? Mmmm .. yours could be faster, more efficient, with better output, applies a different methodology to reach same results AND you added to it at least one new feature, good enough? YES!
  Moreover, if the project is repeated AND huge, then building the whole thing is just as good as challenging Autodesk to build a New-Maya (Naya) that – if in the market – could compete with their Maya. Just try to avoid the traditional topics ..
• Old: Don’t do something we’re sick of, something that has been killed with research, leaving you nothing to add. Go for stuff you can add to, enhance, alter, extend, evolve, or change into something better or different at least. Don’t literally “repeat” them.
  You can dig old graduation projects, “inherit” them and go on with their future work for instance …
• Hard: Nothing’s hard to build. Officially speaking, after your third year in FCIS, you’re done! There’s nothing more you need to start an enormously huge project – but experience of course! So, you shouldn’t have any problems by now to build an operating system for instance, or understanding how a 3D model is represented or a compiler is built. Even if you don’t, you’re ready to understand it in no time. So, don’t worry about that! The problem is something else – it’s called “feasibility”!
  Is it feasible to finish this project on time? Do you have enough resources? And by that I mean man-power, needed software, tools and hardware if needed, knowledge and experience with the topic, field, programming language, concepts, etc. and most of all, time, esp. with the load of the fourth year depending on your department, and finally, your team members and the way you handle stuff (will discuss all of that next). If you have a vision for how you could survive all that in a way that makes building such project “feasible”, then go for it … As a friend of mine says, “Try to challenge the unknown!”

Last thing to mention, deciding on the graduation project topic requires two main things: research and background.

You need to do a lot of research on each topic to know if it’s too easy, killed before, reinvents the wheel, or infeasible to get it done. Also, research will allow you to know more about the subject; how you could enhance it, add to it, change it, skip it, cancel it, and most of all, what you already know about it and what you don’t – so you can start working on. Also, follow up with bloggers and Google Summer of Code; that’ll help you brainstorm and stay updated!

The other thing, the background, plays as an important factor in your choice. For instance, people who have worked or had internships in the summer time, or people who know different programming languages, or people who have experienced several tools and technologies, will sure have a wider variety of choices to pick from than other people who only made their assignments and studied for their finals, if they did in the first place! Your background helps shape your choices, so start teaching yourself, if not for and through the project, then at least for later … !!!

C++ or C# .. ? Oracle or MySQL .. ?

Most people don’t have a problem with questions of this sort – it’s 90% of the time Microsoft Visual Studio 2005, C# and Microsoft SQL Server 2005. Why? Because that’s what we know and what we’ve studied! LOL

Now that you’ve finished your third year, you should know by now that technologies and programming languages are just tools, it’s the concepts that drive them. If I want to do a task X, there has to be several options, languages or tools to get it done. I “should” pick the most suitable solution with respect to the whole project. I said “should” because not all of can afford such choices. If X is better done in C++, perhaps I can do that, that doesn’t imply that you could do the same!

Pick a language you all know, and that serves you project. Same goes for the tools and technologies used. Unless you’re experienced enough to start an Extreme Programming journey and learn something new along the way, then don’t go for crazy stuff now and mess with your output. Sometimes you’ll be forced to deal with new stuff – heard about Symbian? You’ll sure do if your project is about mobile applications. At some point in our project, we had to do some demo, either in WPF (C#) or QT (C++). It was late, and the only solution to know which of them was better, was to build a whole demo to know how it goes. I haven’t worked with any of them earlier – yet, I was ready for both! (= learning a new technology in no time, mastering it, then develop an advanced demo). Thanks God, one was enough!
Again, such insanity doesn’t imply you should do the same. It needs experience, if you can’t do, or not willing to, then don’t!

Whatever you settle for, I suggest you manage your project in an iterative style. Define phases, milestones, and requirements. Define a time plan with deadlines for each phase. Make sure each phase is a separate deliverable (i.e. Phase 1 produces an application that does A and B, then phase 2 produces and application that does A, B, C and D, and so on). So, if anything goes wrong, you still have something solid to deliver. Doing that requires that you have defined objectives from the start, so you can limit the scope of every phase.

One last thing I’d like to come across, is source control. Each developer working on his own then one poor guy integrating the whole thing is somehow a silly scenario. It’s time you learned more about source control. Mentioning that, it’s good to keep tasks, appointments, bugs, etc. online somewhere (Google Docs?).

So what? Is there more to it?

Even though the “contribution” thing was mentioned earlier, I do want to stress that the graduation project is about providing you the experience and the chance to learn something new. You have to do some research and “add” to the topic something – regardless how small, but you did add something! Don’t give anyone a chance to tell you something like “So what? There’s a tool on some website that does the same thing, and even better?” Make sure you have at least one thing that is better, faster, more optimized, handles more cases, etc.

Some people do much effort and great work to do some task that eventually happens to be pretty much pointless. I’ve once attended a seminar for some colleagues who have built a web application that allows you to upload PowerPoint presentations to some website as a part of the project, then view them later. Through this process, each slide is converted into an “image”, so it can be viewed through the webpage (as a slideshow). After they’ve showed this part, the first question was “What’s the point of the whole image conversion thing? Don’t you know that you can view PowerPoint presentations inside the browser?” … I guess the point is clear enough now!

I’ll be the policeman .. LOL

It’s good to have roles. Each team member is responsible for one or more tasks, so if anything goes bad, you know who to kill! Distribute roles according to individual capabilities, experience and personalities. Each member can handle more than one role – roles don’t put equal loads, keep that in mind!

Some roles to mention:

• Project Manager/Team Leader: Responsible of setting and following up tasks.
• Time Keeper: Reminds you of deadlines, task due dates, meetings, appointments, deliveries, etc. and also takes notes during meetings.
• Engagement Manager: Talks to professors, TAs, administrations, companies, etc.
• Configuration Manager: Sets up the technical environment for the developers – brings you the tools you need, manages source control, includes, libraries, headers, databases, etc.
• System Architect: Devices the design of the project, the data work flow, etc.
• Developers.
• Testers (Quality Engineers).

All team members are considered developers of their own tasks and testers of others’ work. Depending on the type of the project, more or less roles could be defined. As an example, with a project with a main database concern, you will need a Database Analyst. It doesn’t matter what you call the role, but somebody has to take it!

Make sure you have a clear vision of the projects, tasks and milestones, against time and due dates. Sticking to them will save you much more hectic time at the end of the year, not mentioning having to cut down project objectives due to the insufficient time left.

Supervisors

Professors don’t have enough time to follow up with you. TAs, mmm, depends! Some are available; some don’t show up till your finals. So, make sure you pick people who can benefit you in some way. Pick professors or TAs that could help you with explanation of concepts, theories, using technologies, etc. If your project has some basic Image Processing, make sure you reach for a professor or a TA who’s in the field. If you’re working in C++, try with some TA who has some experience with that to help you with the 10,000 linking error you’ll have. Sometimes also you can go for prestigious professors; with their presence in your final seminars, the attacks become less aggressive, they will back you up if they are convinced with what you do.

Sponsors and Funding

Usually, they do nothing. Most sponsors declare that they won’t be providing any financial sponsorship from the first day. Others don’t offer or don’t have enough skills to offer technical sponsorship – that’s in huge projects. So, try picking some sponsor related to your topic. Most projects don’t need much funding – hey, it’s a software, you just pay developers and that’s your unpaid job for now! You only need money if you need to buy specific hardware devices or rent some hosting or domain online. If your project is about a mobile application, try to reach for telecom companies as Vodafone to provide you with a mobile device and a free line for Internet connection for instance. If you win the ITIDA (ITAC) funds, it would be great, but you’ll still dive into much hassle with the faculty to get your money back. Moreover, the only mandatory expenses would be printing the documentation.

Documentation, Presentation and the Final Seminar

Some people believe that a project is all about the presentation and the documentation.

Think of the presentation as how you market or sell your product. You’ve done so much work and you have like 10-20 minutes to demonstrate how much effort you’ve done to make such a great thing – if you succeed and I like it, you get the mark .. If not, you know! The most important presentations are the first and the last; the first proposes your idea and defines how people will treat you and look at your project for the rest of the year, while the last is the one that marks your grades. On the other hand, the documentation is the only official record of what you’ve done. It should explain each and every detail related to your work, its background, your “contribution” and the challenges you faced.

I do suggest that everything you do, should be documented; photos, notes, documents, blog posts, whatever! Make a blog for your project, and write a post whenever you do something. Along the year, you’ll forget what problems you face and how you solved them, the choices you had to make, and the results you’ve reached. The blog will help you much in writing your documentation (I should tell you that you should write the documentation through the whole year of the project implementation, you won’t do that, so go for the blog thing instead!).

Your first and at least your last presentations have to be dazzling. In your final seminar, your presentation should contain mainly four things: the problem definition and how your project solves that, your contribution and what makes your project different, whatever challenges you’ve passed, and finally demos. Make sure you make it as short as possible (10-15min, coz you’ll take longer), and that you don’t list or dive into implementation or deep technical details – if they want to know more, they’ll ask! Keep it more as a “marketing” presentation rather than a “technical” one. Remember, your final marks are mainly based on your presentations and documentation, not the executable of your project!

---

Hope this helps .. Best wishes ..
And don’t forget to invite me to your finals to watch 😀