- Joined
- Aug 1, 2015
- Messages
- 518
Previous crunch video generated a lot of commentary, people are still commentating it, which reminds Cain of a Crunch related story in college.
This story is Cain's first serious experience with crunch. Engineering school, fourth year, Software Engineering class that all the Computer Science engineering students had to take. It was all fourth year CS students with three years of classes behind them and a lot of prerequisites, they all had roughly similar schedules. Two years in, you declared your major, afterwards your classes were pretty well defined. Cain is going to talk about a software engineering class that had a project portion. Entirely solo project, told on day one of the class, 50% of your grade. Cannot pass without it. Very large project, first thing the professor warned people to do is not to wait to get started. He said he would give very little homework, and was honest about that. Only other test was the final exam. You had two grades for that class, half your final, half of your project, both of them at the end of the semester. About 15 week long semester.
The project required you to simulate the job queue of a mainframe computer, requests would come into your simulation and they need resources. An executable needs a CPU and this much memory with an estimated runtime. A print job might need a printer to be grabbed to print out 20 pages. There may be a request to write something out to a floppy or hard drive.
Those jobs can be interrupted externally or internally. External interruption is whoever submitting the job stopping it, quitting the program. They did part of it, don't want it anymore. Internal interruptions are the CPU running out of memory, the printer running out of paper, the program crashing midway through. All of those are interruptions of the job that have to tell whoever requested the job a portion was done but they can't complete it. Some jobs have to be done continuously, if you get a print request, you need to print out the whole file before moving onto the next request. If you get five different print jobs, you can't just do page 1 of each file. Others, like CPU executables, can be swapped between. You can be running part of an executable and take that CPU use for use on another executable.
You had to get that simulation working, and it was to test different scheduling techniques for those jobs. Various scheduling techniques, such as shortest job first, which schedules the shortest total duration jobs first. Shortest remaining time is an alternative, which takes the total duration and subtracts what is already done, prioritizing what has the most progress done. Longest job first, others look for what job would take the fewest amount of resources. The professor provided all the scheduling techniques he wanted you to code and submit. When you submitted your simulation, you gave him the executable, he would run it on input data that simulated various jobs. Part of this input data would be the particular scheduling technique he wanted it to use on this run and then you would have to output it into a particular format and he would compare how well it was handled.
Cain started it in the that very week. Only worked a few hours when he started, had a few break periods between classes. Would go to the computer lab and spend two hours between classes working on the project. For the first few weeks, he saw nobody from the class there. After a few weeks, a girl Cain didn't know started showing up there (Possible she also started week one and their schedules didn't line up until then.) He asked her if she saw anyone from the class there, and she hadn't even on the nights it was just her in the lab and not Cain. About a month in, they started seeing other people from the class come in, and as the semester continued they steadily began seeing an increase in people from the class until the entire class was there in the last few weeks. Cain finished up a few weeks early, ran as many tests as he could. Spent the last few weeks to study for the final exams of his other classes, had all results printed out.
Heard later on from the woman that a lot of people there who were working late and fighting over access for the limited terminals and printers the lab had. Lot of raised voices, lots of fights.
They had the final exam, you turned in your program at that point. Gave the professor permission to run the executable in your account. Professor said that over half the class turned in a completely non functional simulation, it would just not start up. Most of the remaining half gave in simulators that ran but gave wrong answers. Almost every scheduling system caused that, which meant the underlying simulations were off.
The only simulations that did not have these issues and worked correctly were Cain and the woman who started early. The class moved into an uproar when they realized 2 out of 30 were going to get a decent grade. They said the project wasn't possible, they didn't have enough time. Professor pointed out enough of the class put in simulators and enough good ones that it was clearly at least possible.
Professor pointed out how important it was to your grade, and that a big chunk of the project was time management, just like in real life.
Some students went and complained to a dean, and that dean pulled in Cain and the woman and asked them about the project. Cain mentioned that the professor warned them to start early. The Dean had access to their accounts and could see when they started, and could see they weren't starting early. After confirming with Cain that the professor warned them, gave minimal homework, the Dean thanked him and Cain doesn't know what happened beyond most of those students not passing. They retook it in the second semester, Cain can guarantee they started early.
Looking back, whenever Cain saw people at work complaining about work, they were the ones that goofed off a lot. Leaving early, coming in late, spending two hours talking about a movie that they watched, take really long lunches, etc. These people would then complain when crunch inevitably happened. This wasn't everyone, but it wasn't a few people either, it was a pretty decent number in team sizes of 75-100.
Crunch is bad, but not 100% management's faults. People who entirely blame management for crunch are usually inexperienced, used to small and dedicated teams, or are coming from indie backgrounds where they have no money and have to get something out.
Yes, it usually management's fault, do not mishear Cain, and sometimes it is the publisher's fault, but it also sometimes the people on the team. Those people who cause the problem are also the same ones who avoid responsibility when the time comes. They give their excuses, Cain thinks back to that class. Everyone got the same schedule and time, some people just didn't bother.
TL;DR :Crunch usually management fault, but if someone says it always is, ask them to prove it. Some people goofed off and thought crunch could save their semester, it didn't.
(Probably no summary next two days, out again.)
This story is Cain's first serious experience with crunch. Engineering school, fourth year, Software Engineering class that all the Computer Science engineering students had to take. It was all fourth year CS students with three years of classes behind them and a lot of prerequisites, they all had roughly similar schedules. Two years in, you declared your major, afterwards your classes were pretty well defined. Cain is going to talk about a software engineering class that had a project portion. Entirely solo project, told on day one of the class, 50% of your grade. Cannot pass without it. Very large project, first thing the professor warned people to do is not to wait to get started. He said he would give very little homework, and was honest about that. Only other test was the final exam. You had two grades for that class, half your final, half of your project, both of them at the end of the semester. About 15 week long semester.
The project required you to simulate the job queue of a mainframe computer, requests would come into your simulation and they need resources. An executable needs a CPU and this much memory with an estimated runtime. A print job might need a printer to be grabbed to print out 20 pages. There may be a request to write something out to a floppy or hard drive.
Those jobs can be interrupted externally or internally. External interruption is whoever submitting the job stopping it, quitting the program. They did part of it, don't want it anymore. Internal interruptions are the CPU running out of memory, the printer running out of paper, the program crashing midway through. All of those are interruptions of the job that have to tell whoever requested the job a portion was done but they can't complete it. Some jobs have to be done continuously, if you get a print request, you need to print out the whole file before moving onto the next request. If you get five different print jobs, you can't just do page 1 of each file. Others, like CPU executables, can be swapped between. You can be running part of an executable and take that CPU use for use on another executable.
You had to get that simulation working, and it was to test different scheduling techniques for those jobs. Various scheduling techniques, such as shortest job first, which schedules the shortest total duration jobs first. Shortest remaining time is an alternative, which takes the total duration and subtracts what is already done, prioritizing what has the most progress done. Longest job first, others look for what job would take the fewest amount of resources. The professor provided all the scheduling techniques he wanted you to code and submit. When you submitted your simulation, you gave him the executable, he would run it on input data that simulated various jobs. Part of this input data would be the particular scheduling technique he wanted it to use on this run and then you would have to output it into a particular format and he would compare how well it was handled.
Cain started it in the that very week. Only worked a few hours when he started, had a few break periods between classes. Would go to the computer lab and spend two hours between classes working on the project. For the first few weeks, he saw nobody from the class there. After a few weeks, a girl Cain didn't know started showing up there (Possible she also started week one and their schedules didn't line up until then.) He asked her if she saw anyone from the class there, and she hadn't even on the nights it was just her in the lab and not Cain. About a month in, they started seeing other people from the class come in, and as the semester continued they steadily began seeing an increase in people from the class until the entire class was there in the last few weeks. Cain finished up a few weeks early, ran as many tests as he could. Spent the last few weeks to study for the final exams of his other classes, had all results printed out.
Heard later on from the woman that a lot of people there who were working late and fighting over access for the limited terminals and printers the lab had. Lot of raised voices, lots of fights.
They had the final exam, you turned in your program at that point. Gave the professor permission to run the executable in your account. Professor said that over half the class turned in a completely non functional simulation, it would just not start up. Most of the remaining half gave in simulators that ran but gave wrong answers. Almost every scheduling system caused that, which meant the underlying simulations were off.
The only simulations that did not have these issues and worked correctly were Cain and the woman who started early. The class moved into an uproar when they realized 2 out of 30 were going to get a decent grade. They said the project wasn't possible, they didn't have enough time. Professor pointed out enough of the class put in simulators and enough good ones that it was clearly at least possible.
Professor pointed out how important it was to your grade, and that a big chunk of the project was time management, just like in real life.
Some students went and complained to a dean, and that dean pulled in Cain and the woman and asked them about the project. Cain mentioned that the professor warned them to start early. The Dean had access to their accounts and could see when they started, and could see they weren't starting early. After confirming with Cain that the professor warned them, gave minimal homework, the Dean thanked him and Cain doesn't know what happened beyond most of those students not passing. They retook it in the second semester, Cain can guarantee they started early.
Looking back, whenever Cain saw people at work complaining about work, they were the ones that goofed off a lot. Leaving early, coming in late, spending two hours talking about a movie that they watched, take really long lunches, etc. These people would then complain when crunch inevitably happened. This wasn't everyone, but it wasn't a few people either, it was a pretty decent number in team sizes of 75-100.
Crunch is bad, but not 100% management's faults. People who entirely blame management for crunch are usually inexperienced, used to small and dedicated teams, or are coming from indie backgrounds where they have no money and have to get something out.
Yes, it usually management's fault, do not mishear Cain, and sometimes it is the publisher's fault, but it also sometimes the people on the team. Those people who cause the problem are also the same ones who avoid responsibility when the time comes. They give their excuses, Cain thinks back to that class. Everyone got the same schedule and time, some people just didn't bother.
TL;DR :Crunch usually management fault, but if someone says it always is, ask them to prove it. Some people goofed off and thought crunch could save their semester, it didn't.
(Probably no summary next two days, out again.)
Last edited:
