3 ms·

There are a few issues with this kind of assignment. The first issue is that it's really hell on the TAs with all of the administrative work needed to do the s

There are a few issues with this kind of assignment. The first issue is that it's really hell on the TAs with all of the administrative work needed to do the swapping between phases. Software engineering is already one of the more annoying classes to TA, and this makes it even less palatable. The bigger issue is that, on the basis of fairness, you grade in later phases is very heavily dependent on factors that are outside of your control. If you get someone's code who just didn't complete the assignment--that is probably going to happen once a semester--you are going to be at a disadvantage. Even if there is an option to appeal to the TAs and get the unacceptable code base replaced with an acceptable one, that's still likely to be a few days' worth of work lost learning the codebase, discovering its incompleteness, and now you have to start over again. I'll also point out that it's not exactly real-world experience. It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code.

haskellandchill 4y ago
> It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code. what? I must be living a rare life.
- x86x87 4y ago
  Hahahaha. Most of the times the author has moved on a long time ago.
- filoleg 4y ago
  Yeah, that statement was the only thing that stuck out to me in an, otherwise, pretty good writeup that I mostly agree with. The only times I can think of where the previous author was able to help was either during onboarding (where you are expected to be given smaller-scope tasks with the context of that code being predefined for you) or during work on certain specific singular projects as a team. But at any large big tech company, you are probably gonna be jumping around more than a few different codebases (more often than not, large and being worked on for years), even if you work on a singular team/product. And most of the time, you are expected to figure as much as possible on your own, only reaching out to the people when you get stuck or encounter a specific issue. Other than that, you are expected to be able to build at least a janky proof of concept with as little help as possible. Most of the time, the help I sharply needed was rather targeted and not really related to the code itself overall. It would be something that is kind of extremely difficult to guess on your own without it being explicitly told (aside from docs/code comments), things like "everything looks fine, but I get stuck at this auth step, what's wrong there?" - "oh yeah, you gotta auth as a part of this specific group, so you need to be added to this security group in this config file". I am not trying to say that i am some genius and can get the structure and overall mental model of how a codebase works all on my own easily, only with the specific "gotchas" (like the ones mentioned in a paragraph above) giving me issues. Not at all. The only way I can mentally get a structure of the codebase and how the whole system works and operates (even as a rough/simplified model) is by looking at the design docs/documentation (very helpful, but far from sufficient on its own, more like a supplementary material of variable quality) and, most importantly, making small code changes and debugging the code using breakpoints to see how it all flows and where. Imo, understanding code through debugging and reading a lot into the code is an irreplaceable step for understanding a section of any significantly-sized codebase.
- ticviking 4y ago
  Most of my major professional achievements involve jumping into code like this, and solving some problem anyhow.
int_19h 4y ago
> It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code. The way this is more likely to work out IRL is that the last person who actually understood the design - not just the what's, but the why's - had long since moved on, and the "prior author" that you have access to can, at best, tell you where the dragons are.
8n4vidtmkvmk 4y ago
it's not rare at all for previous authors to just disappear. do you know what the turnover is at large companies?? reading the code is not the issue though, we also lose context. WHY was it done that way? was it a product decision, due to time constraints, or technical complexity? that should be documented but often isn't
NikolaNovak 4y ago
Thanks for the note and perspective. Some clarifications: 1. As noted, each team got to review and pick the code they would take after each phase as long as it's not your own. I remember drawing a graph of picked code lines and it was fascinating, evolution / survival of fittest at work. But it wasn't something one didn't have control of. 2. I don't know why it would make TA work either better or worse, we may not be fully understanding each other. You have 22 programs to put through a standardized test suite based on formal requirements all teams had to code to. It was far easier to grade than any other assignment I ever had. 3. I guess different people have different real world experience. All of COTS/ERP and a lot of enterprise applications are somebody else's code. Millions of lines of somebody else's code. So that's the norm in my life. YMMV :)
x86x87 4y ago
I would expect that code you get from Stage N-1 is functional across a range of tests that are agreed upon upfront. For the fairness aspect, I would also let students pick any Stage N-1 that is not their previous N-1. That would also teach em that not all is created equal (and probably identify approaches / ideas that they can incorporate in their work)
- ericbarrett 4y ago
  I love this idea. Maybe some extra credit if your Stage N-1 is the most popular choice?
  - hoosieree 4y ago
    This is brilliant.
  - NikolaNovak 4y ago
    That is exactly what happened. You got 1% extra mark if somebody picked your code. Seemed trivial at the beginning of semester,right? ...did I mention my team had previous real life experience? We put extrnsive code and documentation and FAQs online (this was like 99 or 2001 don't remember, but we'll before Github etc) , and committed to 7 day support of our code base. We got 18 out of 22 picks after phase 1. Of course competition was much stiffer further phases, but that too was like 3 valuable real world lessons learned for everybody!
    - x86x87 4y ago
      i mean... at 18 out of 22 you look at the teacher and say: look at me! I'm the teacher now!
ticviking 4y ago
I had a similar software engineering course experience to the one above with a lot of things out of my control. I got an A. By being humble reflective and proactive, showing the instructor that I was looking for solutions to the problem and giving an appropriate amount of time and effort to the class.
JackFr 4y ago
I think you could remove a lot of your fairness and logistical concerns by at stage N choosing one solution and everyone group has to start from there. Now for pedagogical purposes it might be that the professor chooses the best solution or a substantially worse solution. There might be some concern that this unfairly advantages one group over the others but it’s not completely clear to me that it does.
- jefftk 4y ago
  You could also choose two, which then ensures no team starts with their own work from the previous phase
Aeolun 4y ago
I don’t know the size of your university projects, or the speed you worked at, but most of my university projects could be understood in a day. The coding part was by far the most time intensive thing at the time.

haskellandchill 4y ago

> It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code. what? I must be living a rare life.

x86x87 4y ago
Hahahaha. Most of the times the author has moved on a long time ago.
filoleg 4y ago
Yeah, that statement was the only thing that stuck out to me in an, otherwise, pretty good writeup that I mostly agree with. The only times I can think of where the previous author was able to help was either during onboarding (where you are expected to be given smaller-scope tasks with the context of that code being predefined for you) or during work on certain specific singular projects as a team. But at any large big tech company, you are probably gonna be jumping around more than a few different codebases (more often than not, large and being worked on for years), even if you work on a singular team/product. And most of the time, you are expected to figure as much as possible on your own, only reaching out to the people when you get stuck or encounter a specific issue. Other than that, you are expected to be able to build at least a janky proof of concept with as little help as possible. Most of the time, the help I sharply needed was rather targeted and not really related to the code itself overall. It would be something that is kind of extremely difficult to guess on your own without it being explicitly told (aside from docs/code comments), things like "everything looks fine, but I get stuck at this auth step, what's wrong there?" - "oh yeah, you gotta auth as a part of this specific group, so you need to be added to this security group in this config file". I am not trying to say that i am some genius and can get the structure and overall mental model of how a codebase works all on my own easily, only with the specific "gotchas" (like the ones mentioned in a paragraph above) giving me issues. Not at all. The only way I can mentally get a structure of the codebase and how the whole system works and operates (even as a rough/simplified model) is by looking at the design docs/documentation (very helpful, but far from sufficient on its own, more like a supplementary material of variable quality) and, most importantly, making small code changes and debugging the code using breakpoints to see how it all flows and where. Imo, understanding code through debugging and reading a lot into the code is an irreplaceable step for understanding a section of any significantly-sized codebase.
ticviking 4y ago
Most of my major professional achievements involve jumping into code like this, and solving some problem anyhow.

int_19h 4y ago

> It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code. The way this is more likely to work out IRL is that the last person who actually understood the design - not just the what's, but the why's - had long since moved on, and the "prior author" that you have access to can, at best, tell you where the dragons are.

8n4vidtmkvmk 4y ago

it's not rare at all for previous authors to just disappear. do you know what the turnover is at large companies?? reading the code is not the issue though, we also lose context. WHY was it done that way? was it a product decision, due to time constraints, or technical complexity? that should be documented but often isn't

NikolaNovak 4y ago

Thanks for the note and perspective. Some clarifications: 1. As noted, each team got to review and pick the code they would take after each phase as long as it's not your own. I remember drawing a graph of picked code lines and it was fascinating, evolution / survival of fittest at work. But it wasn't something one didn't have control of. 2. I don't know why it would make TA work either better or worse, we may not be fully understanding each other. You have 22 programs to put through a standardized test suite based on formal requirements all teams had to code to. It was far easier to grade than any other assignment I ever had. 3. I guess different people have different real world experience. All of COTS/ERP and a lot of enterprise applications are somebody else's code. Millions of lines of somebody else's code. So that's the norm in my life. YMMV :)

x86x87 4y ago

I would expect that code you get from Stage N-1 is functional across a range of tests that are agreed upon upfront. For the fairness aspect, I would also let students pick any Stage N-1 that is not their previous N-1. That would also teach em that not all is created equal (and probably identify approaches / ideas that they can incorporate in their work)

ericbarrett 4y ago
I love this idea. Maybe some extra credit if your Stage N-1 is the most popular choice?
- hoosieree 4y ago
  This is brilliant.
- NikolaNovak 4y ago
  That is exactly what happened. You got 1% extra mark if somebody picked your code. Seemed trivial at the beginning of semester,right? ...did I mention my team had previous real life experience? We put extrnsive code and documentation and FAQs online (this was like 99 or 2001 don't remember, but we'll before Github etc) , and committed to 7 day support of our code base. We got 18 out of 22 picks after phase 1. Of course competition was much stiffer further phases, but that too was like 3 valuable real world lessons learned for everybody!
  - x86x87 4y ago
    i mean... at 18 out of 22 you look at the teacher and say: look at me! I'm the teacher now!

ticviking 4y ago

I had a similar software engineering course experience to the one above with a lot of things out of my control. I got an A. By being humble reflective and proactive, showing the instructor that I was looking for solutions to the problem and giving an appropriate amount of time and effort to the class.

JackFr 4y ago

I think you could remove a lot of your fairness and logistical concerns by at stage N choosing one solution and everyone group has to start from there. Now for pedagogical purposes it might be that the professor chooses the best solution or a substantially worse solution. There might be some concern that this unfairly advantages one group over the others but it’s not completely clear to me that it does.

jefftk 4y ago
You could also choose two, which then ensures no team starts with their own work from the previous phase

Aeolun 4y ago

I don’t know the size of your university projects, or the speed you worked at, but most of my university projects could be understood in a day. The coding part was by far the most time intensive thing at the time.