Home Blog Talks Projects

Carleton Computer Science: Maximizing Your Honours Project

What I learned from my honours project, how you can avoid common mistakes, and get more from yours
Author
Matthew MacRae-Bovell
January 1, 2026

raven-teaching

In Carleton’s Computer Science program, the Honours Project / Thesis has the potential to be one of the most rewarding and enriching experiences of your undergraduate degree.

Having just completed my own honours project, I wanted to share some insights and strategies as well as all of the REAL documents, emails, and deliverables I actually submitted to give you an example of how I made the most of the opportunity.

To keep my personal experiences separate from general advice, I have annotated descriptions of “what I did” with ⭐ icons as what I did has flaws and may not be the best approach for everyone.

My Project Deliverables ⭐

Don’t have time to read the whole article? Here are all of the REAL deliverables I created for my honours project:

Table of Contents

First: Decide What You Want Out of It

There is no single “correct” way to do an honours project.

However, before you even think about topics or supervisors, you need to answer a more fundamental question:

What do you want to get out of doing this project?

Some example motivations include:

  • Testing a potential Master’s supervisor before committing to graduate school

  • Building a portfolio piece or something to showcase on your resume

  • Developing research skills and delivering a paper with publishable results

  • Using the project as a means of building something useful for a community or cause you care about

  • Getting some credit with minimal effort (I don’t recommend this one!)

How you answer this question will impact how you approach the rest of the process.

Coming Up With a Project Topic

Once you have a clear idea of what you want to get out of the project, you can start brainstorming potential topics.

Before Brainstorming Ideas

Before you overthink this, it’s important to know that your project topic will evolve and change as you discuss it with your supervisor. They may have suggestions that lead you in a different direction, or have more interesting ideas that they believe would align with your interests.

For this reason, try not to get too attached to any one idea during your brainstorming phase. Instead, focus on generating a variety of ideas that align with your interests and goals.

I’ve anecdotally spoken with many students who’ve reached out to professors with one idea, but worked with the professor to mold their idea into something more valuable, novel, or impactful.

How To Brainstorm Project Ideas

Firstly, I’d recommend going through the Undergraduate Honours Projects and Theses Repository page to get a sense of what kinds of projects other students have done in the past.

I’d also recommend thinking about your goals by asking yourself questions like:

  • Is there an area of computer science that I am particularly passionate about? What unsolved problems exist in that area?

  • Is there something I have always wanted to build or create, but never had the time to pursue? Could I build something to solve a personal pain point or benefit a community or cause I care about?

  • Is there something I could build that would look impressive to potential employers or fit well on my resume?

My Brainstorming Process ⭐

Before I reached out to my eventual supervisor, I privately brainstormed a few ideas that I thought would be interesting.

For each idea I’d brainstormed, I made a one page document for myself with a brief description of the problem I was trying to solve and what my solution might look like.

Here is a picture of the REAL document I created for myself while brainstorming:

Ideas

Some of these ideas kind of sucked, but that’s okay! The goal of this exercise was to get my brain thinking about potential topics and solutions.

Another VERY IMPORTANT step I took was that for each idea, I validated that there wasn’t an existing solution or that the reason my idea didn’t already exist was not because it was impractical or because there was a better alternative.

How I Conceived My Eventual Final Idea ⭐

While I brainstormed many ideas, I want to give some insight into how my eventual final project idea came to be.

The idea that my supervisor decided to gravitate towards was the following:

“ChaosSpec: An Assertion-Based Chaos Testing Framework For Distributed Systems”

Ideas

This idea was born out of a personal pain point.

During one of my internships, I was tasked with verifying that when one of our services experienced failure or significant network latency, the overall system would still meet our speed and availability requirements.

For example, say your system had a backend service that relied on a database. You might want to verify that if the database became unavailable, your backend service would still be able to handle requests gracefully without crashing or timing out.

However, simulating these kinds of failures and network conditions in a controlled manner was quite difficult. My team at the time was using a tedious and error-prone manual process and I thought to myself: “There has to be a better way to do this.”

What I found was that while there were existing testing tools for this kind of problem, they mostly seemed tailored for large-scale enterprise systems, and were not very accessible for smaller teams or individual developers.

This led me to the idea of building a more lightweight and developer-friendly testing framework that could easily test these complex network conditions in a more automated way.

Contacting Potential Supervisors

Once you have a clear goal and some ideas in mind, visit the “Finding a Supervisor” page, which has a list of faculty members who are open to supervising honours projects and narrow down a few that align with your interests.

In the case that you do not have a pre-established relationship with one of the professors you believe would be a good fit, you will need to reach out to them via email or possibly in person during office hours.

Your outreach will lead to some kind of initial meeting and in that meeting you will discuss your ideas and see if they would be interested in supervising you.

When To Reach Out

I would recommend reaching out to potential supervisors at MINIMUM in the term prior to when you plan to start your honours project / thesis.

If you’re still a year or more away from starting your honours project, I’d recommend probing professors you enjoy early even if you don’t have a solid idea yet, just to get on their radar and see if they would be open to supervising you in the future.

You may have to reach out to multiple professors before finding one who is interested and available, so give yourself plenty of time.

Another piece of advice my supervisor gave me is that for teaching faculty members, months especially near the end of the term can be particularly busy, so try to send your inquiries at times when they may be less busy, such as early in the term or during breaks.

Don’t Be Too Specific (At First)

When reaching out to potential supervisors, you’ll want to mention some of your proposed topics or areas of interest, but how specific or broad your proposed topic should be will depend largely on what you want to get out of the project.

For example:

  • If your goal is to work with a specific professor to test out whether they’d be a good Master’s supervisor, you should include a few ideas, but mostly focus on a more general expression of interest. Having an overly specific idea may actually HURT your chances of working with them, as they may not believe your project aligns well with their priorities.

  • If your goal is to use this opportunity as a means of building a project you’ve always wanted to pursue, you should come with a more firm project proposal. If no supervisor is interested in that idea, then it may be a sign that you need to pivot your idea or pursue that project outside of the honours project framework.

Lastly, as mentioned in the “topic brainstorming section”, go into reaching out to potential supervisors knowing that your idea and project scope will change once you start discussing it with them. Especially if you’re trying to work with a professor whose background is related to your area of interest, as they will likely shape your project in a better direction.

Plenty of students will reach out to professors with one idea, but work with them to mold their idea into something better.

How I Approached My Supervisor ⭐

I reached out to my eventual supervisor, Dr. Jean Pierre Corriveau at the end of July 2025 with the goal of starting my honours project in the Fall 2025 term (about 1 month in advance).

Here is a very slightly trimmed down version of the email I sent him:

Dear Professor Corriveau,

My name is Matthew and I’m an undergrad student with a deep interest in software best practices, developer experience, and distributed system design.

I’m reaching out to see if you might be open to supervising my honours thesis.

(... additional background omitted for brevity: about me, my past experience, etc)

I’ve been brainstorming some project ideas, and I believe a few of them could align well with your expertise:

1. ChaosSpec: An Assertion-Based Chaos Testing Framework For Distributed Systems: (... additional description omitted for brevity)

2. LATCH: A Durable Webhooks Alternative for Real-Time Events: (... additional description omitted for brevity)

3. Serverless HTTP Mocks: A Developer-Friendly Alternative to Centralized Mock Servers: (... additional description omitted for brevity)

If any of my ideas seem interesting, or if you have other directions where you think I could contribute, I’d really appreciate the opportunity to chat and discuss the possibility of you supervising my honours thesis.

Thank you for your time and consideration.

Sincerely,

Matthew MacRae-Bovell

In hindsight, this email feels a bit long, but at the time my goal was to demonstrate that I had put thought into my ideas and was serious about pursuing this project.

After I sent this initial email, I received a response within a few days expressing interest in setting up a meeting to discuss further.

My Initial Meeting With My Supervisor ⭐

This meeting was my first time meeting my supervisor. During our initial meeting, we discussed my proposed ideas in more detail.

These were the main outcomes of this meeting were:

  • Validate that there was mutual interest in working together

  • To align on the project idea that I would pursue

  • Determine the project scope and deliverables

  • Discuss what my supervisor wanted to see in the proposal

We ultimately aligned on the idea of ChaosSpec, and my supervisor provided helpful feedback on how to refine the project’s scope and objectives.

He also outlined the specific questions and sections he expected in the proposal, which made the next steps much clearer and easier to plan.

Creating Your Proposal

Once you and your supervisor have aligned on a project idea, the next step is to create a formal proposal.

What To Include in Your Proposal

The provided guide says the following “The proposal should give a clear and concise overview of the project, indicating the motivation, main objectives, equipment requirements, a description of what will be implemented, what will be tested, and what analysis will be performed on the results. It must be clear as to what is expected at the end of the project, including the deliverables.”

Overall, I found this description to be fairly accurate. However there are a few additional points I’d like to emphasize:

Use References: In the motivation / problem description, it’s expected that if your proposal makes any claims, that references be used to back up those claims. This should really go without saying, but a lot of students in our program have never read an academic paper before. This might not apply to you if your project is more applied, but if you’re proposing something novel, it’s important to situate your work in the context of existing literature.

Clearly Define Your Project Scope: One of the most important aspects of your proposal is clearly defining what you will and will not be doing. I would suggest intentionally lowballing your scope to ensure that you can complete the project within the given timeframe. It’s better to have a smaller, well-defined project than an overly ambitious one that you can’t finish. I would go as far as to explicitly say what WILL and what WON’T be included in your project.

Evaluation of Success: Although the SCS description mentions “analysis of results”, I think this could be better said as “evaluation of success”. If your project is proposing a new solution to a problem, you need to clearly define how you will evaluate whether your solution is successful or better than what already exists. There is a very wide range of possible evaluation strategies, such as user studies, comparisons to existing tools, performance benchmarks, formal proofs, etc. Your evaluation strategy will depend largely on the nature of your project.

The Proposal Length

The provided guide says that “The proposal is usually a two-page document”. However, my proposal that I made in Google Docs with size 11 font, pictures, tables, and code examples ended up being 6 pages long. However, I believe that if I’d made the same proposal in Latex with a small font, I’d probably be able to fit it into 2 pages.

The truth is that the proposal is ultimately more an exercise for you to clarify your own understanding of the project and its goals rather than a strict document that must adhere to a specific length.

My Actual Proposal ⭐

Here is a link to the REAL proposal I submitted for my honours project.

My proposal is definitely not perfect, but it at least gives you an idea of the structure that is expected.

At this point, I also made sure to create a proof of concept implementation of the core idea to demonstrate its feasibility.

You can find the REAL proof of concept implementation I created on GitHub here.

This proof of concept was a minimal implementation that demonstrated the technologies I was specifying in my proposal would actually work together as intended. In my case, that was validating that I could manage the orchestration of Docker containers and network fault injection using Testcontainers in the Jest testing framework.

I completed my first draft of the proposal on August 9th, 2025 and went through 2 rounds of asynchronous feedback over email with my supervisor before submitting the final version on August 27th, 2025.

The feedback I received was mostly focused on clarifying the scope of the project and to include specific features my supervisor wanted to see in the final deliverables.

My Project “Schedule” ⭐

One of the proposal sections is the “Project Schedule”, which is a rough timeline of what you plan to accomplish each week during your project.

While I made an effort to predict what I would do each week, the reality is that my project pivoted around the 1/3 mark to focus on a more broad research question around testing in general rather than just building a specific tool.

This pivot meant that my original schedule became mostly irrelevant, but that’s okay! The purpose of making the schedule should really be an exercise for you to think through how you will manage your time and what milestones you want to hit.

Doing My Project ⭐

Once your proposal is approved, it’s time to actually start working on your project!

I would say that on average I put in about 5 hours per week. With some weeks having 0 hours, and other weeks having 10+ hours. Additionally, I spent more time in the writing phase than needed because I was aiming to create a report that could be converted into a conference paper. This was my first time trying to write something of that quality, so it took me longer than it would normally take.

The reality is that since every project is different, there is no one-size-fits-all approach to managing your time and work, so I don’t really have any concrete advice that applies to everyone.

However, here is how I approached my project and as well as the key deliverables I produced by the end of it.

My Supervisor Meetings ⭐

I had roughly bi-weekly 1 hour meetings with my supervisor throughout the term.

I treated the meetings the same way you might treat a 1-on-1 with a manager at a job. Going into these meetings, I would always come with an agenda and a list of questions to discuss. Meaning it was very driven by my needs rather than just a status update.

The kinds of questions I would ask would NOT focus on implementation details (as a supervisor should not be expected to know your code inside and out), but rather on higher level questions about design decisions, paper structure, evaluation strategies, and research directions.

I also was able to get a lot of mentorship and advice regarding graduate school, research, publishing papers, etc from my these meetings which was definitely an invaluable bonus for anyone considering doing a Master’s.

Pivoting My Project Focus ⭐

One of the key turning points in my project was my supervisor suggesting that the real value of my work was not just in building a specific tool, but in creating a broader pattern or technique that could be applied more generally. This insight led me to pivot my project towards a more research-oriented direction.

This occurred around early October, so I thankfully still had enough time to adjust my project scope and deliverables accordingly.

The main difference this pivot made was that instead of just building a specific tool, I focused on establishing a pattern for a new software engineering technique. This meant that the evaluation of my project also shifted towards demonstrating the effectiveness of this technique instead of just showcasing a single tool.

While the tool I was building would still be part of the final deliverables, it came secondary to the broader research question I was exploring.

The original problem I had been trying to solve was simplifying “network resilience testing”, but after the pivot, my project evolved to researching whether a broader pattern could be used to simplify any kind of resilience testing.

Academic Tool Recommendations ⭐

Firstly, I would highly recommend using Zotero to manage your references and citations.

Secondly, when you have references you’ll quickly realize Google docs just doesn’t cut it for writing academic papers. Now the de facto standard is LaTeX, but I tested out Typst while writting my report and found it to be much simpler to use if Latex is intimidating to you.

Lastly, sometimes searching on Google Scholar just isn’t enough to find the right papers. Tools like Elicit and Connected Papers definitely were additions I wish I had known about earlier.

My Final Report ⭐

The following is my REAL final project report.

I intentionally wrote my report to be of “publishable intent” using the IEEE conference paper template, meaning that I structured it in a way that would make it easier to convert into a conference paper in the future.

A very good piece of advice I was given early on was to “always be writing”. While you won’t have your results write away, forcing yourself to write early will help you clarify your thoughts and identify gaps in your understanding that you can then go and fill through research and experimentation.

I would also recommend NOT writting your report in a linear fashion. Meaning don’t start with the introduction, just start writing whatever section you feel most ready to write and then piece it together later. I probably rewrote my introduction atleast a dozen tiems as I kept changing the direction of my project and refining my understanding of the problem space.

A few odd things you might notice about my report:

Overly Verbose Background Section: My background section is quite a lot longer than you’d see in a typical paper. This is because the target audience for my report is hypothetically someone marking my project who should not be expected to have deep knowledge of the topic area. In a typical paper, you’d want to be more concise and focus on the most relevant related work.

Repeated Content and Explanations: Some sections of my report feel repetitive, but this was intentional to ensure clarity for the reader. In a shorter paper you’d want to avoid this, but since my report is longer and readers may only read certain sections, I wanted to make sure each section could stand on its own.

Use of Graphics: It’s my understanding that in a proper conference paper you wouldn’t typically as many graphics as I have in my report (especially “decorative” ones).

Evaluation Strategy: My evaluation strategy is relatively light compared to what you might expect for evaluating a novel software engineering technique. This is one of the bigger regrets I have with my idea more so than my project. Going into the project, I didn’t really have a grasp on what would constitute a strong evaluation, and as a result, my evaluation ended up being simply a comparison against existing tools, which isn’t bad, but what would be expected here is some kind of user study with developers in this area to demonstrate the effectiveness of the technique in practice.

My Project Repository ⭐

You can find the REAL repository for my honours project on GitHub here.

There isn’t anything super special about the repository structure, but it’s worth noting that I contains three key folders

  • /chaos-spec-lib: The actual “tool” implemented for this project
  • /evaluation: All the logs and scripts used for evaluating the tool
  • /example-service: A sample distributed system used to demonstrate the tool

What I Learned From My Project ⭐

Other than obviously learning a lot about the topics I was researching, I would say that this project taught me a lot about how to approach research projects in general.

Simple things like how to more effectively read academic papers, how to structure a research paper, and how to evaluate the success of a research project are all skills that I developed through this experience.

In trying to produce a report of publishable quality, I also learned a lot about the “game” of academic publishing, like finding the right conferences to submit to and how to navigate the peer review process.

What I Would Do Differently ⭐

My biggest regret with my honours project was NOT considering how I would evaluate the success of my project from the beginning.

Anyone can have a new idea or build a new tool, but to make a meaningful contribution to the field, you need to demonstrate that your idea or tool is effective in practice.

Unfortunately, my idea was one that would be best evaluated through user studies with real developers, which I did not have the time or resources to conduct within the scope of my honours project.

Conclusion

Completing my honours project was one of the most rewarding experiences of my undergraduate degree.

I’d encourage anyone considering doing an honours project or thesis to take the plunge, as it’s a great way to work on something you know you’ll actually care about as well as work 1-on-1 with a faculty member.

If I can manage to actually publish a paper based on my honours project, I’ll be releasing a follow-up article detailing that experience as well.

If you have any questions about my experience, feel free to reach out to me via email or by booking a coffee chat!


Special thanks to Dr. Jean-Pierre Corriveau for supervising my honours project and Justin Zhang for giving me a lot of early advice on how to approach research in general.