Suppose an instructor is teaching a course on a particular field in computer science. He uses a language that is popular for said field, but itself is not the topic of the course (though its use is still required). The instructor provides a code base he wrote that the students may base their course project upon. However, this code base is very buggy and does not follow many accepted "best practices" in the language's usage. You are not technically required to use this code base, but to use anything else is most likely impractical given time constraints. Is it justifiable to expect students to use a buggy code base you prepared, or is it lazy? Or neither?
The answer to this question is "Sometimes."
Given that an instructor has roughly X hours/week to devote to this course (given their other responsibilities), sometimes the best way to utilize that time may be to write a code base for students to use in some fraction of those hours (even though it will be buggy and not up to best practices) and devote the rest of those hours to other things.
Sometimes improving the code base isn't the best way to utilize instructor time - sometimes that time is better used offering more office hours to answer students' questions, or writing better lecture notes, or something else that is of greater benefit to the students' learning than making the code less buggy.
It's usually up to the instructor to make that determination of what will best serve the pedagogical goals of the course.
(I'm assuming the professor isn't intentionally trying to give students some experience working with a buggy code base. But that's also a possibility.)
As a student, I didn't think about the time and resources my professors devoted to preparing their course materials. As an instructor, I gained a very different perspective.
For example, the first course I taught as instructor of record was a course that I was only assigned about a week before class started, in a subject outside my area of expertise, and I had very limited time to prep the first few lectures and assignments. I agreed to teach it despite knowing that my teaching would be underprepared (by my own standards) for the first part of the course, because I thought it would be better for my students than the alternative (the course being cancelled because the department couldn't find any other coverage.) As a student, I would never have thought about my professors being put in situations like that.
The instructor's expecting you to use poorly written code with known bugs that you might have to work around? Sounds like he's doing a good job of preparing you for real-life programming work.
I'm only about 25% joking - while I wouldn't think he's inserted the bugs intentionally, having to work with existing buggy codebases is something that every programmer faces routinely, whether in academia or industry or elsewhere. So it's certainly not unreasonable to expect students to be able to handle it, or learn to do so.
Evidently the professor has decided that having you work with this code, although it has issues, will be a better educational experience than an alternative. That's a matter of his professional judgment, and we here on this site are in no position to second-guess it. We have no way of knowing what alternatives exist, what their pros and cons might be, and what other constraints the professor has. On the basis of what we know from your post, I think it would be irresponsible of any academic to judge someone "lazy".
If you think you can improve the code, or know of alternatives that would be better, this could be a great opportunity for you to contribute. You might be able to earn independent study credit, or money, by working on the code or helping adapt the curriculum to some alternative software. At a minimum, you can write useful bug reports for the professor, which should make it easier for him to fix them, and save some hassle for future students.
I have been that instructor.
When I was a TA in graduate school, we were trying some innovations to improve a class that I was teaching. Overall, they worked, but the reality of the situation was that the first time around there were a lot of bugs because:
- We didn't have time enough to get everything perfect before the semester began, and were in fact racing against the clock trying to improve the code for each problem set before we hit the point in the semester where it was released.
- Being academics rather than a professional software QA team, our imagination in testing was much more limited than the range of interesting problems and abuses of the codebase that the students invented, particularly those who were shaky programmers or poorly understood the course material.
The second time around, things were a lot better, thanks to the discovery of problems the first time, but there were still bugs --- either because they were low-triage issues that we hadn't been able to fix or because the students were quite inventive in finding new ways to work with our codebase.
Interestingly, this whole situation was in fact partially created by an attempt to improve away from another buggy code base, which had been created by a former instructor and which nobody teaching the course at the time could improve because it was a large and poorly documented codebase that we were all too scared to touch in case everything broke.
In short: sometimes it might be laziness, but, as @ff524 notes, other times its simply the realities and constraints of development with limited resources.
If a codebase had to be perfect before using it in a classroom was pedagogically appropriate, the number of codebases that could be used in classrooms would approach zero.
(Adding my $0.02 to the other stories: I'm teaching very basic PHP this semester. I have zero experience with PHP, and am far from a phenomenal programmer to begin with. My students are lucky anything I give them WORKS. Of course it's not ideal code.)