I agree with what you say, but it was interesting to note that pretty much everyone I know hated our 2 compulsory Software Engineering modules. They're mostly hardcore computer scientists and they equated UML with "drawing pictures". Teaching us more Software Engineering might improve our skills but I'm not convinced we'd like it any more.

There was a third module building on the previous two, but I know of nobody that chose it as one of their options for this year.

That's not to say all my CS pals are just 'hackers'. A few of them really enjoyed the Formal Methods module, which could be looked at as 'software design using maths' or something like that :)

Quote:
I've long been critical of the way programming is taught in most computer science programs, at least in the US. I've had the opportunity to partake of two: UNC Greensboro, where I was enrolled for two semesters; and Stony Brook University, where I am taking my second CS course (for upper-division credits, so I can graduate this May). Both are excellent schools and excellent programs, with excellent professors and excellent facilities, so the problem clearly is not with the infrastructure. It is with the content.

Content has always been a problem in college or university courses. To much emphasis is placed on learning the language and it's facilaties and less on proper usage of the paradigms that the language exposes. This has always been the case. It is one of the things that I argue with professors about all the time. They teach bad practices because it's to "get the student off the ground." I'm sorry, but a bad practice doesn't get them off the ground, it gets them fired. Best to learn it right the first time than to have to burn out bad habbits that have formed over months or years of being taught wrong.

Quote:
The problem? An overemphasis on "subsystem reimplementation." In today's software development environment, integrating subsystems and architecting elegant larger systems are by far more important than writing yet another memory manager or windowing system or renderer or linked list or sparse matrix. Teach these kids to think about how to solve problems, show them common data structures (allow them to implement a few, ask them to reason through the rest without implementing), then set them to work building systems from standard implementations.

Implementing subsystems is one of those things that should be kept in your datastructures course, and that's about it. You should never be required to implement your own set, map, array, or other container after you've taken DS. Even before taking data structures, you should have been introduced to your languages standard library and taught how to use it. You don't need to know how it works, just when to use it. The datastructures course will tell you how it works, and hopefully information on when and where to use it.

On the topic of proglem solving: That's what we are. Anyone who enters this field thinking that we program for any other reason than just to solve a problem needs to be taught otherwise. But problem solving should involve more than just building systems from standard implementations of data structures. 90% of the problems you will encounter have a text book solution, it's the 10% we should train them for. Because that 10% is what ends up pushing deadlines. It's also the part that ends up being the buggiest.

Quote:
The most frequent and most pitiful question asked in the beginner forum, beside "Where do I start?" is "How do I put it all together?" And the truth is, we don't have enough resources on putting it all together.

I think you forgot the "I've got a great idea for an MMORPG..."

Quote:
I remember the first time I picked up 3D Game Engine Design. I was thinking, "Yes, finally! A book that talks about how to put it all together!" Boy, was I wrong! And I wasn't the only one, so much so that Eberly wrote 3D Game Engine Architecture, which I haven't yet read, when he realized that lots of us had different expectations of the title. (See our video interview with Dave Eberly and Tim Cox of Morgan Kaufmann at the GDC for more.)

Never read it. I'm a traditionalist for programming books, I got to the publishers that have never let me down, like Addison Wesley. However, I do have the first two gems books. I wasn't overly impressed with them, as I found most of the knowledge they contained to be common sense, or something that had been better covered in other books. It's a nice collection of googling material though.

Quote:
Software design remains an understated area. We vaguely say things like "be sure to design your system before you start implementing it," but we don't teach the necessary design skills or tools with anywhere near the fervor that we teach the math and coding skills. Most college CS graduates have taken precisely two courses that touch on design techniques like Software Development Cycles and tools like UML. Witness the relative unpopularity of our own Software Engineering forum.

Well...ok, now this is a subject close to my heart. Design is one of those things that takes experience to get used to. But at the same time, introducing design concepts at a beginners level is a perfect oportunity to ingrain into the fledgling programmer that little seed that will bloom into an all out design freak. Of course, you do have those people who see design as just a full set of UML diagrams, and forget that a design will evolve and grow as the system is built. You will never be able to document your entire system in UML from the start. Best to leave that to a program that can synchronize your class diagrams with your code. On the other hand, I've found that a lot of professors don't really know what design means. They see it as just "thinking about how you should solve the problem." Which isn't really correct. It involves a lot more than just the "problem" but also how this "problem" will integrate with all of the other problems that you don't have control over.

Lets face reality though, most of the young programmers that come here won't be in a team for months, if not years. They will be soloists. This does not work well in building up team based skills, of which design is one of them. It's a touchy subject really. But it's one that we, as a site should be covering. Heck, we could have a whole series on team building, team communications, and coordinating efforts over a wide area. If you think it can't be done, look at Unreal. They were spread out all over the world for most of the development time. It wasn't until the near the end that they all had to get together to coordinate their efforts and finish the engine/game.

Of course, there are the language wars that you have to deal with as well. I mean, I learned basic...god only knows how many years ago, and have been doing C++ for about 15 years now. It's been standardized for half of that. So what's my point? Simple: Look at the number of C# vs C++, or Java vs C#, or Java vs C++ threads on our boards currently, I can think of 3 off the top of my head that I have seen within one week of today.

Young programmers have been told that they should learn "a language." This inheritly limits their ability to understand or comprehend new design concepts, as they are stuck with the limitations of th

Personally, at least as far as helping the posters on Gamedev.net is concerned, I don't even think this has to go as far as software engineering. A lot of beginning programmers have no concept of what the game loop is and that knowledge alone would be very helpful. There's a bit of a gap between low level "what does this function do" sort of advice and high level "should I use the Bridge design pattern to separate the Rendering from the platform specific stuff" questions.

Personally I'm wary of up-front formal design however. I've never found it useful. Most of the design methods try to emphasis computing as an engineering discipline which I personally think is a bit of a mistake, unless your aim is to ensure that poor programmers can achieve mediocre productivity. I see programming as more of a craft where there are several well-defined techniques and tools to use but many different ways of applying them, few of which can really be considered wrong.

Quote: Comment by Neex
I agree with what you say, but it was interesting to note that pretty much everyone I know hated our 2 compulsory Software Engineering modules. They're mostly hardcore computer scientists and they equated UML with "drawing pictures". Teaching us more Software Engineering might improve our skills but I'm not convinced we'd like it any more.

Depends on how it's taught.

I think UML should be taught with a good tool, one that:

1. Generates skeletal code in multiple languages (perhaps via plugins, making it extensible);


2. Monitors and integrates changes in the source back into the diagram;


3. Integrates and synchronizes with version control;


4. Flags inconsistencies in the sources (in C++, for example, between header and implementation files) and provides diagrammatic resolution tools, or waits for textual resolution; and


5. Integrates and synchronizes with document generation tools such as ndoc and doxygen.

With this approach, a lot of the busywork and tedium of UML and other architecture representation languages can be reduced significantly, and the benefit in being able to visually analyze the connections between pieces of code or sketch out alternative approaches would be huge.

Quote: Comment by Kylotan
Personally, at least as far as helping the posters on Gamedev.net is concerned, I don't even think this has to go as far as software engineering. A lot of beginning programmers have no concept of what the game loop is and that knowledge alone would be very helpful. There's a bit of a gap between low level "what does this function do" sort of advice and high level "should I use the Bridge design pattern to separate the Rendering from the platform specific stuff" questions.

Very true. We need more resources that explain what's really going on - a code analysis series of sorts - to up the general code IQ around these parts. Understanding what a piece of code does helps understand when to apply it and what its likely impact will be. I know that my current project (school) constantly has me applying techniques that I've absorbed over the years.

I should finish that deliverable, considering that I'm already a day late...

Quote: Comment by Kylotan
Personally I'm wary of up-front formal design however. I've never found it useful. Most of the design methods try to emphasis computing as an engineering discipline which I personally think is a bit of a mistake, unless your aim is to ensure that poor programmers can achieve mediocre productivity. I see programming as more of a craft where there are several well-defined techniques and tools to use but many different ways of applying them, few of which can really be considered wrong.

I think of programming as a craft as well, but the analogy to, say, carving breaks down at some point. For large projects, even in craft - think Donatello's bronze David - there has to be an investment in a certain amount of up-front design. Donatello had to plan his statue to ensure that it could bear its weight, that it would balance... he had to fashion scaffolding to maintain the proportion and pose of the form he was attempting to render in malleable metal.

Code works the same way, to me. For small projects analogous to the whittling boat that bobs in a pond, one can simply dive in, but for large systems that incorporate multiple distinct and reusable subsystems, a lot more rigorous design is necessary. The key is not to become a slave to this design, because all craft generally encounters unexpected occurences that force a reevaluation of the design or other adaptive measure. I believe this is what Washu referred to when he spoke about the design "evolving."

And this is where I think good tools and a good workflow come in, in that the allow for dynamism and change and evolution, but they maintain the integrity of the design overall - changes in code are reflected in the formal design documentation.

Quote: Comment by Washu
On the topic of proglem solving: That's what we are. Anyone who enters this field thinking that we program for any other reason than just to solve a problem needs to be taught otherwise. But problem solving should involve more than just building systems from standard implementations of data structures. 90% of the problems you will encounter have a text book solution, it's the 10% we should train them for. Because that 10% is what ends up pushing deadlines. It's also the part that ends up being the buggiest.

All I can say is: word.

Quote: Comment by Washu
Never read [3D Game Engine Architecture]. I'm a traditionalist for programming books, I got to the publishers that have never let me down, like Addison Wesley.

Well, I'm training myself to operate as a producer, so I'm expanding my reading and focusing more on architectural issues so I can provide guidance, reference and a sounding board to whomever I hire as Lead Programmer (who should be reading these things to).

Quote: Comment by Washu
Well...ok, now this is a subject close to my heart. Design is one of those things that takes experience to get used to. But at the same time, introducing design concepts at a beginners level is a perfect oportunity to ingrain into the fledgling programmer that little seed that will bloom into an all out design freak.

I keep postponing my effort at an article titled "Software Quality through Refactoring: From Pong to Tennis" in which I quickly scratch up a Pong clone in Python+PyGame and then successively refactor and refine the code through generations until I have a fully working Tennis game. I then go a step further and investigate refactoring to optimized subsystems (such as moving certain portions of the code to C++) and refactoring for flexibility (such as being able to dynamically create and execute content). All targeted at our beginners.

Eight more weeks until I graduate. Let's just hope I don't flunk any courses this semester, what with my acute senioritis.

Quote: Comment by Washu
...I've found that a lot of professors don't really know what design means. They see it as just "thinking about how you should solve the problem." Which isn't really correct. It involves a lot more than just the "problem" but also how this "problem" will integrate with all of the other problems that you don't have control over.

And this is the real problem. Your in-class examples are always relatively trivial process situations, but your projects - and, worse, your career after school - are all about those 10% problems that require more than just "thinking about the problem."

And because of the way our educational material is structured, an attempt to approach them using better methods tends to be unprofitable because of the amount of time it takes and the lack of supporting resources. The end result of which is a "just get the grade and get out" mentality, which hurts the larger ecosystem of software development tremendously, and companies in particular because it relegates them to doing the job universities supposedly did.

Quote: Comment by Washu
Young programmers have been told that they should learn "a language." This inheritly limits their ability to understand or comprehend new design concepts, as they are stuck with the limitations of the language they have chosen.

The real tragedy is not that they have chosen a language and fixed themselves to it, but that they have chosen - because they were recommended - the wrong language. Allow me to explain.

At core, all programming languages devolve into one of three or four mathematical languages: imperative algebra, functional algebra, and declarative algebra. All programming languages are projections onto and mixtures of subsets of these languages, which makes significant numbers of them inherently interchangeable. (On a larger scale, they're all interchangeable, as all three algebraic systems can be used to evaluate and solve all problems, essentially.)

The problem we face is a social one: the fixation on productization, the fact that Doom 3 used this language/API/technology and Unreal Engine 3 uses that, arbitrary concepts like "speed" and "flexibility" and "power." And the truth is that we can't teach abstract algebraic systems, but we can illustrate how each language relates to the various systems.

Say we had a series of articles on programming languages (specifically oriented toward game development or not, it's immaterial). At the top of each language, we would indicate its "family tree" viz the three algebraic systems aforementioned. Within the body of the article, we would make reference to how a particular feature is derived from a particular system, with a link to an article/page discussing that system and illustrations from multiple languages. Over time, as this resource diffused through our community and was debated and fought over, this notion of fundamental interchangeability would permeate because it has been canonized in an article and remains unrefuted despite the proliferation of discussions about it.

Hopefully.

I think it's a social problem because I've seen other social problems resolved in much the same way. For instance, we seldom have 3D API vs wars anymore because of the conscious effort put into reinforcing the fact that the two major contenders - Direct3D and OpenGL - are functionally equivalent, and the hardware and device driver were far more important arbiters of performance. A similar committment to disabusing the community of these language fiefdoms might just be the ticket. In essence, if we were all the Nazi mods about it - ops, owners, staff, vstaff, mods, and community leaders (by which I mean intelligent, competent and well-respected members) - then I think the issue would, at least, be abated.

We've seen the same happen with a variety of issues, including the Help Wanted forum (massive reduction in flaming) and "I wanna maek MMORGP!!!one!!1!" threads.

Quote: We need more than a greater emphasis, we need the materials to back it up. We need the articles on XP, on Unit Testing, on Source Control, and team building and coordination, on content management. We need the software, to allow gamedevers to form teams around our site, manage their content from our site and distribute that content from our site. Heck, even open forum style lessons would be of use.

Quote: Comment by Oluseyi
I think of programming as a craft as well, but the analogy to, say, carving breaks down at some point. For large projects, even in craft - think Donatello's bronze David - there has to be an investment in a certain amount of up-front design. Donatello had to plan his statue to ensure that it could bear its weight, that it would balance... he had to fashion scaffolding to maintain the proportion and pose of the form he was attempting to render in malleable metal.

True. For anything I do, I tend to write something down first, to give me an idea of the scope of the project. Generally this is the analysis stage and part of the design stage to me! Often this is a short list of goals or specifications. If I draw diagrams they tend to be a cross between an entity-relationship model and a class diagram, just showing the vague relations between concepts in my system. The main purpose of this is just to ensure that I've not forgotten anything major.

However I see no purpose in sequence diagrams, or class diagrams detailing data members, or anything approaching low level design. This is because if I thought I could get the design even 99% right on paper first time, then I may as well just type it in the IDE straight away. Therefore I resrict my preliminary design to the abstract level. The only time I'd want to flesh out a sequence diagram is if I was handing it over to a lackey to implement for me!

In a lot of ways I've replaced design with education. I don't need to draw out a diagram to know instinctively that my tile-based map is going to contain a 2D array of mapsquares, each of which will contain some instance data and a reference to a terraintype object. This is just database normalisation, object-orientation, and plain old abstraction talking to me. My instincts give me the structure - documenting that is just busy-work. I like to think that I am a little bit better than the average coder, but I can't claim I got there via meticulous planning or preparation.

my, wouldn't a quote button be nice?

Quote:
Well, I'm training myself to operate as a producer, so I'm expanding my reading and focusing more on architectural issues so I can provide guidance, reference and a sounding board to whomever I hire as Lead Programmer (who should be reading these things to).

Well, I would hope that they have read more than just [3D Game Engine Architecture]. Addison Wesley, as per my example above, has many books on design as well. Although their focus is more general software development, those same ideas tend to carry over very well into the game development side.

Quote:
I keep postponing my effort at an article titled "Software Quality through Refactoring: From Pong to Tennis" in which I quickly scratch up a Pong clone in Python+PyGame and then successively refactor and refine the code through generations until I have a fully working Tennis game. I then go a step further and investigate refactoring to optimized subsystems (such as moving certain portions of the code to C++) and refactoring for flexibility (such as being able to dynamically create and execute content). All targeted at our beginners.

Do it! I would love to read and even help you edit and revise such a series. But note I said series. Spreading it out over several issues with a much more in depth look at each step in the process would probably be much more beneficial.

Quote:
Eight more weeks until I graduate. Let's just hope I don't flunk any courses this semester, what with my acute senioritis.

Hah, I remember those days...sortof.

Quote:
And this is the real problem. Your in-class examples are always relatively trivial process situations, but your projects - and, worse, your career after school - are all about those 10% problems that require more than just "thinking about the problem."

So why shouldn't the professor break the class into teams, make them build components that must eventually fit together into a single system. Of course, I realize this isn't possible really, what with people dropping out, dropping courses, and such, but it certainly would be an interesting application of the methods which you and I have discussed together before.

Quote:
And because of the way our educational material is structured, an attempt to approach them using better methods tends to be unprofitable because of the amount of time it takes and the lack of supporting resources. The end result of which is a "just get the grade and get out" mentality, which hurts the larger ecosystem of software development tremendously, and companies in particular because it relegates them to doing the job universities supposedly did.

Ahh yes, this is what it really comes down to, red tape and lazyness. Boy isn't it great how the education of the future generation comes first. [grin]

Quote:
The real tragedy is not that they have chosen a language and fixed themselves to it, but that they have chosen - because they were recommended - the wrong language. Allow me to explain.

Please do.

Quote:
At core, all programming languages devolve into one of three or four mathematical languages: imperative algebra, functional algebra, and declarative algebra. All programming languages are projections onto and mixtures of subsets of these languages, which makes significant numbers of them inherently interchangeable. (On a larger scale, they're all interchangeable, as all three algebraic systems can be used to evaluate and solve all problems, essentially.)

Indeed, of course, you can't really expose a beginning programmer to such advanced concepts as "languages are derived from mathematical bases." Or can you?

Quote:
The problem we face is a social one: the fixation on productization, the fact that Doom 3 used this language/API/technology and Unreal Engine 3 uses that, arbitrary concepts like "speed" and "flexibility" and "power." And the truth is that we can't teach abstract algebraic systems, but we can illustrate how each language relates to the various systems.

But I want to make Quake 5! Of course I must use the same language as Quake was written in! If I didn't how could I squeeze that extra billionth of a percent out of the CPU and GPU, even considering that my application will never be optimized enough for the machine to even remotely tax it.

Quote:
Say we had a series of articles on programming languages (specifically oriented toward game development or not, it's immaterial). At the top of each language, we would indicate its "family tree" viz the three algebraic systems aforementioned. Within the body of the article, we would make reference to how a particular feature is derived from a particular system, with a link to an article/page discussing that system and illustrations from multiple languages. Over time, as this resource diffused through our community and was debated and fought over, this notion of fundamental interchangeability would permeate because it has been canonized in an article and remains unrefuted despite the proliferation of discussions about it.

Nope, wouldn't happen. You will always have the core fanatics who will always spout their drivel, such as "hand written asm is faster than what the compiler produces."

Quote:
Hopefully.

I think it's a social problem because I've seen other social problems resolved in much the same way. For instance, we seldom have 3D API vs wars anymore because of the conscious effort put into reinforcing the fact that the two major contenders - Direct3D and OpenGL - are functionally equival