A reflection: My first system development project
This is a write up as a personal refection on my first system development project as part of a course at Simon Fraser University (Bus 465 — Spring 2021) on things I did, learned and would have done differently in my future projects.
1. Project management
Have a timeline, and be realistic
When I said this, I mean a real timeline that you would follow, not just any list of things to do and random dates on it for the sake of showing on the report. And give yourself more time than you needed, especially when it comes to producing the codes, because when you are planning, you had no idea how much time it would take to troubleshoot a problem, for something that you haven’t envisioned to encounter (like changes or unexpected incidents). I spent most of my time finding solutions to my broken pieces of codes that I initially did not allocate anytime for.
Everything has a reason
While designing the schema for database, I was quite confused about which goes where, like there are so many reasonable approaches that we could do, admin information can be in a separate table of it own or just another column in the user table, or a part of admin information can be in a separate table and part of it can be in the user table since an admin is also a user. Only deeper into the project I realized that each option would produce a slightly different constraint scenario when you change the information in the table(s). It’s important that you see the reason behind that design and choose what is appropriate.
What I would have done if I were to do it again would be try to create a sample database on paper and try some common CRUD scenarios and see what would happen with the design.
Whatever you decided on paper would be the skeleton for your production, so putting more thought into it would never be insufficient, especially when your team is using a waterfall framework, or only one sprint cycle for this small project. Keep in mind that changes in later phases of production would be more costly compared to during the planning phase.
Communication is key
I was not an assertive type of person during a group project and sometimes it might cause me more time and effort to work on the project. I used to feel bad when my idea was not selected among the peers and the fear of rejection creep in unknowingly, causing me holding thoughts. This is bad because it’s likely we have our own bias and perhaps the idea was actually not good enough to be used, but what if it’s a brilliant one, we would miss out the chance to turn the project into something at a higher level, or maybe our colleagues can add/adjust to make it more suitable to the context. We only know if we overcome the fear…
By actively thinking that we are seeking for constructive feedback for our ideas, maybe we can persuade ourselves that rejection is not that intimidating.
Being responsive also helped during a project with tight time constraint since we can resolve a problem more effectively as a team instead of individual.
2. Deployment
What to do when you have too much to do
As mentioned earlier, I was a terrible at time management during this project, and it caused me a lot of trouble because I overestimated myself. Who would have thought there would be bugs in such simple project. Luckily my team was nice enough to collaborate together during the last minute overtime and we got things to work but things might not be always that fortunate.
What helped during this project was that I followed the advice of Dr. Stephen R. Covey when planning one’s life: put in the big rocks first, then the gravel, then sand, then water. I created a stateless, static design for the whole website first, then move on to stateful and functional features later. My approach could be inappropriate in professional context, but when our team was under time constraint to show the MVP (most viable product), we needed to make sure the audience can see demonstration of the feature even if it was only as a placeholder.
Change management
Not having version control was one of the biggest risks we decided to take during this project. Since our team was not familiar with GitHub, we just stored our files locally and there were some times that I badly wanted to revert to the previous version but we did not have anything to fall back to. Fortunately the application worked after some troubleshooting but it was definitely scary building a house while not having insurance.
When we worked on both front end and back end, things turned out to be much more connected to each other than I expected. I was sort of aware that they are supposed to be that way during the design phase but wow they could be detrimental. For examples, you could do whatever you want when making tables (with datatypes and constraints) with the SQL database but it would hinder your ability to retrieve data from the form if done incorrectly. Who knew form input can store arrays but SQL table cannot…
I guess it was just a learning experience for me so I don’t make the same mistake again, but the most important lesson I had was there’s no such thing as too detailed during the planning & design phase.
Always review the use cases and make sure you are on the right path
Something that I neglected while working on deployment phase was not coming back to the use cases frequently enough. I had some moments not knowing what a detail should be like, and made decisions based on personal judgement. Instead, the correct approach would be to review the use case, project goals and use them as guidance to my decision, that would clear my confusion in a more logical manner. Who knew use cases are meant to be reviewed…
3. Troubleshooting & final result
Speaking of troubleshooting, there’s a famous saying: have you tried Google it? — everyone.
Well, I believe everyone can Google and find the solution by themselves, but have you consider asking people who know your project context, who can provide you the answer for you? Stack overflow might have a bunch of results from 2 of code to page length that solves a similar problem, but perhaps your mentor, project manager, teacher can give a better strategic answer that clear your confusion. Perhaps the problem you had was not really technical, and they can clarify what you/they wanted.
Sometimes, even technical problems can be hard, don’t afraid to ask them if you have spent considerable effort to troubleshoot them on your own.
I myself made a lot of assumptions, and asking a person I know usually give me the answer I needed, hopefully that will be something a shy person like me do more frequently when I have tough challenges.
Final result
The time has come and your stress level is at its peak (or is it just me?), you can only change a few minor things in the project and wrap up with the report & presentation. It’s understandable that you had great times and perhaps some bad times, what important is that you learned from the experience and make it more enjoyable during the next project.
Let me know what lessons you learned from your projects and how would you do it differently in the future!
You can see the code and use cases of my project at: https://github.com/thmsng/bus-465-project
