Tips on Surviving a 3rd Year IT Software Development Project
The third year software development project is an exciting opportunity for Information Technology / Computer Science students to work together in achieving greatness. This allows students to use their knowledge, and information gathering skills (yes StackOverflow, you have bailed out a lot of students) in crafting an amazing software project. In most cases, students have 1 year (technically 9 – 10 months) to create software; your imagination is your limit. Whilst this is meant to be a fun module, some students end up loathing this project due to problems that arise. This post will cover some tips and tricks which I feel are important. Get your cup of coffee (or tea) because this is going to be a good read.
It is important to note that the purpose of a third year project isn’t to see which group delivers the biggest, leanest and meanest software project, but rather to see if you are able to apply software design principles taught at university. As much as students hate group work, it is important in this case; because you are exposed to different people having different personalities and work styles. These dynamics are very prevalent in the office.
Ideally, you should strive to do your absolute best in your project. Prospective employers are aware of the project module, and take much interest in what you did in your 3rd year project. This is where they are able to measure your technical skills, knowledge and drive. Your projects at University are your selling points. With that out the way, lets get down to the list.
People and Groups! VERY Important!
When students get started with their 3rd year project, the first step is to form software development groups. The people you choose can either take your group to greater heights, or run the group to the ground. Don’t be quick on picking friends – the software development project is notorious for ending friendships and relationships. Ideally, you should pick people who are hard-working, and share the same goals and vision as you. Do not pick people who want to just pass, when you want to shine with a distinction in project, and possibly publish your project. Your group should be filled with people who are willing to pull their weight from start to finish.
Another important aspect here is the group size – groups are limited to 4 – 5 people per group. My recommendation here is your group should not exceed 3 people. Most groups that experience teething problems are large groups with 4 or 5 people. Also, with a large group, it is very easy for one or more members to slack off, and not make any real contributions to the project because they know there are other minds and hands in the group. Project judges typically expect a bigger scope from large groups, because there are more minds and hands present. Deliver anything less and you will be marked down.
If you are working in a group of people you do not know very well, take time off to know your team mates better. If you are all lovers of alcoholic beverages (I believe 80% of students love their alcohol), go out for drinks together. If there is an amazing movie at the cinema, go to the cinema together. The point here is to engage in social activities as a group so everyone knows each other better. Remember, your project team is your “ride-or-die”.
Once you have a group, it is equally important to pick the right supervisor. You should pick a supervisor who is able to offer valuable help and advice, as well as attend to your queries with haste. Unfortunately, not all supervisors are great supervisors – You get really good supervisors, and really bad supervisors. To uncover which supervisors to stay away from, ask a few senior students in your department about supervisors.
Communication and Decisiveness are Key
This is one of many key contributors to groups failing – lack of communication and decisiveness. The moment problems arise in your group with one or more individuals, these issues must be discussed with every member of the group, and your project supervisor. If a group member is slacking off, or disappearing for weeks without saying or making any reasonable contributions, do not keep quiet; act on these cases immediately. In the worst case scenario, it is much easier getting rid of slacking group members in the early stages of project than towards the end of project.
As a group, you should all meet at least once a week to discuss what is currently happening, what needs to happen, and what problems need to be addressed. In 2018, I believe all software development groups should include using Skype / Google Hangouts for meetings, as well as create an instant messaging group (WhatsApp group or Telegram group) in their communication plan. If you still believe all meetings should be held on a face-to-face basis, please consider updating your meeting methodologies – this is 2018, not 1975.
Do NOT Dedicate ALL Your Time to Idea’s, Planning and Documentation
3rd year students often fall into the trap that they need to spend as much time as possible coming up with a suitable project idea, as well as planning the system, and placing much emphasis on documentation. Remember, as much as having 1 year to finish your software project sounds like a lot of time, it really is not a lot of time. You will have other commitments to attend to; I assume you do not want to neglect your other modules, and want to graduate the following year (or end of the year).
Each member in your team should get 1 week to think of possible idea’s for the project. The following week, everyone should meet and share the idea’s they thought of, and vote for the best 3 ideas. With your group’s best 3 idea’s, speak to your supervisor about the viability of each idea. After voting for ideas, as well as consulting your supervisor about the viability of your best 3 idea’s, it will become clear which idea your team should take on. Once you have an idea, that is when you can start planning all the exciting stuff like functionality (using Use Case Diagrams) as well as your choice of technology. Remember, at this point, your functionality is subject to change, so these do not need to be cast in stone.
Another thing I have noticed with some groups is the extra emphasis on project documentation. While it is important your documentation is up to standard, you shouldn’t be spending so much time and effort on documentation. Each week, you should be spending some time doing a task which contributes to documentation. Then, when it is time to hand in documentation, you are simply compiling and adding final touches to your project documentation. Remember, you are an IT / CS student. If you truly believe project documentation should receive more attention than your software project, cancel your degree and go enroll for one of the BA degrees at your University.
The moment University opens for the new academic year, you should already be thinking about who you want in your group, what possible idea’s you have, and what your technology mix will be like. If the academic year starts in February, by end March, your group should have started coding. DO NOT start your coding a few weeks before the first judging round that requires working code… YOU WILL FLOP! By following this strategy, you will give yourself time to make needed changes as your requirements change, and give you a chance to impress the judges by bringing in extra functionality. If everything works well, your group will finish project a month or two early, thus giving you time to make improvements and enhancements to existing functionality.
Make Preparations While You Have Time
If you want to make your software development project life a lot easier, use your 2nd year of IT / CS to familiarize yourself with the technology you want to use in 3rd year. Find some time in your 2nd year to experiment with new technology. Making small (and probably meaningless) apps like tip calculators, interest calculators and so forth are good enough to get you exposed. If you want to have a little more fun, then by all means go for it!
I used my 2nd Year of IT to learn the basics of building native Android apps. When I got to the software development project, the learning curve was not so steep because I entered with some knowledge on Android development. I have seen some groups struggle to the point their marks take a big dive because they were not able to familiarize themselves with technology in time, or they were not able to use the new technology in such a way it caters for functionality planned for their project. This creates situations where students take horrible shortcuts, such as hard-coding functionality that shouldn’t be hard-coded, and unfortunately, the judges see through this very quickly.
Remember, when building your software project, you need to build in such a way it can handle errors seamlessly. In most cases, project judges will instruct you enter trivial values they know will cause a poorly coded system to fail, or break your system’s business rules. Some things judges have asked at my University include entering a past date for something that is date-sensitive, enter name instead of an email address in the email address field, try create an account with leaving some fields blank. I have heard of some judges executing SQL injection on some project groups which have a website.
Use Source Control and Backup! Ditch Flash Drives, Hard Drives and E-Mails
I cannot understand software development students who insist on using flash drives to distribute project files to other team members. It is disappointing, and heart-breaking to receive departmental group emails about a student who lost their flash drive, containing their final year project, in a computer lab. Often, this student does not have any other backups (or latest versions of their project), so everything was on their flash drive. There have been rare cases of students losing their laptops in a robbery, or students passing away.
If you want to full-proof your group from such situations, your project should be stored and managed on source control platforms like GitHub. You don’t need to know those scary Git commands, thanks to GitHub plugin’s on popular IDE’s like Visual Studio, and their Windows desktop client application. Managing your software project is a matter of making a few clicks, literally. In addition to source control, you should also periodically store copies of your project in the cloud – Microsoft’s OneDrive and Google Drive are popular cloud storage options which have reasonable free plans.
DO NOT Oversell; Undersell Your Idea
For the first round of judging, students are expected to pitch their project idea to a judging panel. At this point, you should paint a clear picture about what your group’s project is all about, the planned functionality and the technology mix. Again, these are subject to change. Many students make the mistake of bringing in a LARGE scope – I sat through the first round of judging where some groups came with a large scope, which does not match the number of people in their group. This gives judges reason to cast doubt on your idea and potentially mark you down. If you truly understand your idea and the business rules, you will answer any questions the judges have flawlessly.
Your scope should be structured in such a way it is just enough for the number of people in your group. Doing this will give you a chance to impress the judges by showing them more functionality than what you had planned – resulting in more marks.
TIP FOR THE ADVANCED KIDS: If you had started your coding your project a month or so before this moment, bring in what your group has done so far. This will leave a good impression with the judging panel that your group was able to deliver a great presentation and even bring a prototype, despite it not being required.
Say NO to Last Minute Changes
As a result of starting the coding process late, many students are under pressure to make sure they have working code for project judging. By making last minute changes to code, say, a few days or hours before presentation, you run the risk of breaking code that works. This has happened to so many students, and they get the shock of their lives when something that used to work does not work anymore.
As a general guide, you should make sure you are done with coding a week before presentation. The only things you should be doing a few days before presentation is preparing your presentation. This could be ensuring your project is deployed and running smoothly on a live environment (on a web server, or mobile phone), or ensuring your slides and speech are ready to go. Remember, you won’t get a second chance to impress the judges. Do not blow your only chance by coding a few days or hours before presentation. Murphy’s Law has this thing attacking vulnerable IT / CS students moments before their presentations.
Manage Your Time Efficiently
As mentioned earlier, as much as 1 year sounds like a lot of time, it really isn’t a lot of time. The biggest mistake you, as an IT / CS student can make for your project, is to let it take the backseat. Find a way of balancing all your commitments, social life and project life. If this means reducing or cutting out clubbing, or not going to see friends and family as often, then by all means do that. Time waits for no one, and it would be sad putting yourself under so much pressure because project had been neglected.
Final Thoughts on the Matter
The software development project is the perfect opportunity to learn something new and advance your skill set. When coming up with a project idea, please try come up with an exciting idea that is challenging, but not overly beyond what you are capable of achieving. Your problem solving skills, in a programming context, improve with complicated challenges posed by your project. DO NOT pick an idea because it is the easy way out – if you are passionate about programming, it will most likely bore you and kill your drive. Also, I have noticed in the couple of interviews I have gone through, employers are impressed and more eager to listen to what you have to say if you are able to impress them with an exciting idea. Simple, “shoe box” CRUD (Create, Read, Update and Delete) apps are far from being impressive, and the learning curve isn’t so exciting. Your group should strive to craft a project that will be remembered for many years by your peers and next year’s 3rd year students (they do hear about good and bad projects).