5 ms·

I think the problem is you really need to feel the pain of a few badly organized projects to understand why we need things that seem like extra time sinks. It's

I think the problem is you really need to feel the pain of a few badly organized projects to understand why we need things that seem like extra time sinks. It's hard to design a course that deliberately goes about building a project the wrong way without seeming contrived, and yet it's easy to just start writing something that ends up being a big ball of spaghetti.

zabardasth 6y ago
Yeah, I was surprised there is no mention of drift and technical debt. These are the things that make software engineering hard. Someone new will always suggest a rewrite, which is tempting but is almost always a trap and massive timesink.
AnimalMuppet 6y ago
I think you can do this. You take an existing badly done code base, and ask the students to make significant changes and/or additions. After they've felt that pain for a semester or two, you discuss what causes the pain, and what choices led to that point.
bcrosby95 6y ago
You could have them build a project one requirement at a time. That's how projects usually get out of hand in the real world. But I'm not sure if a semester is long enough.
- mcguire 6y ago
  I had a class in grad school called Database Implementation. We wrote a simple SQL database from the ground up, with a SQL parser as the first assignment. I had worked in industry for a few years, so it was fun seeing that "I have painted myself into a corner" look in some people's eyes. And the "I have to rewrite everything" scramble. :-) That was also when I learned you could deadlock AIX 3.2.5's NFS filesystem using mmap. (I was also working as one of the dept's sysadmins, so putting 2 and 2 together was easy.)
rstuart4133 6y ago
> I think the problem is you really need to feel the pain of a few badly organized projects I'd go further than that. I've come across a few programmers who had _only_ built new systems, or maintained systems they had built. You could cajole them about coding standards, documentation, unit tests, clear naming until you were blue in the face. It is pointless. So you force them to maintain someone else's code base. Be prepared about the rants about how bad code base is, whinging about having to learn all the unfamiliar libraries, the total lack of comments, yada yada. But somehow the connection between how that programmer worked and how they worked is never made. Then 6 months later, after a some of the intimate knowledge of their own code they were using to make maintain it tractable is gone, you move them back. Then, finally, it hits home. They improve steadily thereafter.

zabardasth 6y ago

Yeah, I was surprised there is no mention of drift and technical debt. These are the things that make software engineering hard. Someone new will always suggest a rewrite, which is tempting but is almost always a trap and massive timesink.

AnimalMuppet 6y ago

I think you can do this. You take an existing badly done code base, and ask the students to make significant changes and/or additions. After they've felt that pain for a semester or two, you discuss what causes the pain, and what choices led to that point.

bcrosby95 6y ago

You could have them build a project one requirement at a time. That's how projects usually get out of hand in the real world. But I'm not sure if a semester is long enough.

mcguire 6y ago
I had a class in grad school called Database Implementation. We wrote a simple SQL database from the ground up, with a SQL parser as the first assignment. I had worked in industry for a few years, so it was fun seeing that "I have painted myself into a corner" look in some people's eyes. And the "I have to rewrite everything" scramble. :-) That was also when I learned you could deadlock AIX 3.2.5's NFS filesystem using mmap. (I was also working as one of the dept's sysadmins, so putting 2 and 2 together was easy.)

rstuart4133 6y ago

> I think the problem is you really need to feel the pain of a few badly organized projects I'd go further than that. I've come across a few programmers who had _only_ built new systems, or maintained systems they had built. You could cajole them about coding standards, documentation, unit tests, clear naming until you were blue in the face. It is pointless. So you force them to maintain someone else's code base. Be prepared about the rants about how bad code base is, whinging about having to learn all the unfamiliar libraries, the total lack of comments, yada yada. But somehow the connection between how that programmer worked and how they worked is never made. Then 6 months later, after a some of the intimate knowledge of their own code they were using to make maintain it tractable is gone, you move them back. Then, finally, it hits home. They improve steadily thereafter.