I have enormous issues with developing simple things.My assignment was a game, I chose to remake an existing game for my assignment.

Here's the problem, I didn't get it finished, however I did end up having over 100 classes(140 was a close estimate).This struck me strange as well because I for such a huge amount of work I didn't get much of the actual game done, this apparently seems like a common thing with me.I end up building an AI system, graphics engine, event system among other things but I didn't finish the game itself.

For one of my labs several months ago, one question was to build a networked naughts and crosses game. Simple? I mean the source that was there was only 2 files, we were told to modify it and implement a few features to it.

I built my own version of naughts and crosses into 40 classes and only after *many* revisions.Taken me about 2 weeks to do before I showed it to my lecturer.

Big question is, why am I always building everything but the game?Everything associated with the game is built, just not the game.I'm always thinking about "what if" scenarios when designing any software.Does anyone have any advice that which can help me remove myself from my self destructive behaviour?Thanks.

It applies doubly in the case of coursework assignments and the like, as:

You don't have to maintain the code into the future

You probably won't be able to reuse the generic systems you develop, as the next assignment will be on something totally different

There probably aren't any marks available for building some wondrous architecture. In fact, forcing whoever is marking the assignment to comprehend your 140+ class beast will probably result in a lower mark

I took a hard-assed, do-the-simplest-possible-thing-that-will-possibly-work approach when building this, and it's worked out pretty well. Sure, I've done some reasonably major revisions in some of the systems, but it's always been with the benefit of concrete knowledge of how those systems are actually used, and what features would make life easier.

It applies doubly in the case of coursework assignments and the like, as:

You don't have to maintain the code into the future

You probably won't be able to reuse the generic systems you develop, as the next assignment will be on something totally different

There probably aren't any marks available for building some wondrous architecture. In fact, forcing whoever is marking the assignment to comprehend your 140+ class beast will probably result in a lower mark

If this is the case in your classes, you really need to take a course with a *good* professor. Similarly, if your prof has let you whittle away your time doing unproductive over-engineering on a significant project like a game, you either need to visit his/her office hours more often, or find yourself a better advisor / professor / university.

Well, I think it has very little to do with over-engineering (from seeing lots of people go through this). I think it's just that you are learning cool stuff, and the more you learn, the more interesting stuff you discover you can do, hence you go and learn even more in addition. This tends to increase semi exponentially, feeding off itself.

Does anyone have any advice that which can help me remove myself from my self destructive behaviour?

Why are you an idiot? You're only an idiot because you didn't pass the assignments - that's foolish. You need to learn to do two things at once: the minimum you're required to do, and the exciting stuff you want to do. On thing that might help is doing the minimum first, and really working at doing it in the least *amount of time* possible, knowing that as soon as its done, you'll then go off and use that source as the basis to do a much cooler, more elegant, more powerful, more feature-rich version. That would be *smart*.

OTOH, by the time you become a proper professional programmer (if you do) - which will take at least a year until after you graduate (first year at least you're still learning tonnes of new stuff all the time), you'll find that you now know a lot compared to how much you can learn in the course of a few weeks, and this problem will fade. Although learning to do smart things like solve the problem first, THEN re-wire it - that's really useful stuff that will always be handy.

Does anyone have any advice that which can help me remove myself from my self destructive behaviour?

Learn from your mistakes.

Read up on YAGNI and keep reading up on it. If you are inclined to overengineering it is really important to be able to seperate the What Ifs that lead to good design from the What Ifs that lead you up blind alleys of eternal, unfinishable, architecture. Usually that distinction comes down more or less to designing so that you don't cut of your options if you need to revisit the code later, but not to building every possible thing you may ever need.

Even if you did build the ultimate library, you would never finish it because by the end you would have become a better programmer than you were at the start and you would probably think of better ways to do half the things you did at the start. So you go back and rework that and before you know it you've refactored everything and you're a better programmer than you were when you started refactoring...

i know exactly what ur talking about.. i havent graduated yet from university.. i started in computer science and when i was learning C++ i was reading and playing with more that what i was thought .. we learend console applications and i was already playing with opengl, glut and glut based GUI. when i started learning data structures in C++ i was more interested in what java is and how to use it, i was writing my data structures in java when my assignments r in C++ and end up not finishing my c++ project. when i did unix system programming i was more interested in how to daul install linux and windows together and how to hack and compile the kernel.. so the teacher introduce the course and i go off course to learn more stuff not covered in the course.

there is more to my story , the end is that im now senior in computer engineering and minor in computer science.. no degree yet. but im working as a software engineer, the recruiter was amazed with the stuff that i know and i passed all the interviews so i got hired.

few months ago i was going crazy about .net and mono, but when i heard that java is going GPL i went back to java , yet im trying to learn C# now. i have learned from my mistakes, first "keep it simple", then when u solve the problem u can look into how to make a better solution. but first solve the problem before anything else.

ur not an idiot, u just cant thing about one thing at a time, ur mind creates threads of thoughts that pulls u away from the main objective.

Matzon = While I don't like trying to stuff things into 4Kb, I do like the idea of how the competition can make a developer change their perspective of things. I will have another look at 4K to get a better look at the overall design constraints required to develop such a game in order to help me improve upon my thinking and development ability.

Blah^3 = I did pass the assignment and the subject(84%), but the teacher also said that if I continued working on it over the holidays he is willing to amend my marks. The reason I got a decent mark for my assignment(15/20) was because of the shear effort and work I put into it. In the real world I would have had my ass fired.

Breakfast = I need to remember what you've said in your post because that's exactly what I need to remember before I implement anything.

I keep refactoring the program I'm writing that we're just making a few small changes to. I still haven't made all the actual changes, but I've made unimportant pieces of the code much better in an aesthetic sense. I have made some of the changes, but I seem to spend more time refactoring other stuff than making these changes.

One thing about programming assignments at schools is that you need to check, re-check and re-check the REQUIREMENTS. Do not do anything less, or anything more. When you have solved the required material, you can go a head and refactor, add new things etc.

I was in a 3d game programming course this semester, and the final game project we did I simply solved everything that was outlined... and explained how it was solved, then I added some other features. I got 11 (out of 10) for that project, and only worked on it for 3 days. While another buddy of mine worked 6-7 days on it, had bunch of extra features in it and wasn't able to finish the basic outlined requirements.

A manager asked a programmer how long it would take him to finish the program on which he was working. ``It will be finished tomorrow,'' the programmer promptly replied.

``I think you are being unrealistic,'' said the manager, ``Truthfully, how long will it take?''

The programmer thought for a moment. ``I have some features that I wish to add. This will take at least two weeks,'' he finally said.

``Even that is too much to expect,'' insisted the manager, ``I will be satisfied if you simply tell me when the program is complete.''

The programmer agreed to this.

Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.

5.3

A novice programmer was once assigned to code a simple financial package.

The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.

When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''

Its in us all, because of this we look farther than we need to and walk paths we did not know existed. It a core facet of being creative.

A PLUS in school a potential MAJOR MINUS when working for a living. Try to explain why you failed to follow the simplest of requirements to a over stressed middle manager....yoicks!!

Do you have any more information on the Poltergeist antipattern? From the information you've provided and a quick google search, I have a hard time seeing it as pertinent to the discussion. "YAGNI" seems to be a better diagnosis.

I would be interested in reading a formal analysis of this pattern within Java. I frequently use small, one-use, short-lived objects in Java programs in order to implement other patterns, especially builders and adapters. This certainly seems preferable to bloating another class with functionality that does not belong there. Also, though I'm no expert on the VM, my understanding is that short-lived objects are efficiently created and destroyed.

Some programmers do great code that is neither over-enginnered os under-engineered, and are capable of spending months in well planed projects that are useful to the community, but then fail to document it or just document it partialy and force users to reverse-engineer the code in order to know how to use it. This is as much unexcusable for an engineer as not being able to follow requirements. Unless everything is fully documented without any room for ambiguity the system isn't documented. It's a failure to deliver a working system that is going to be used by others.

Unfortunatly university courses for computer science don't see things this way. And even students that fail to fullfill critical requirements can get away with a lower score in their projects. The problem starts at university and in the way students are mentalized.

Do you have any more information on the Poltergeist antipattern? From the information you've provided and a quick google search, I have a hard time seeing it as pertinent to the discussion. "YAGNI" seems to be a better diagnosis.

You appear to be right. I remembered Poltergeist a bit differently.

I've seen cases where programmer's lack of skill is the reason for the program not being finished. But in K.I.L.E.R's case it appears that he has lots of skill in programming, but not in controlling himself to produce only the most simple solution.

Maybe one way to solve this would be to plan a list of all the features, which you would like the program to have, and prioritize them. First produce only a minimal set of features which are absolute required for completing the task. Then if you have time (after testing, writing good documentation and cleaning the code), add other features one at time.

Unfortunatly university courses for computer science don't see things this way. And even students that fail to fullfill critical requirements can get away with a lower score in their projects. The problem starts at university and in the way students are mentalized.

While your statement may be true for many university courses, it's not true for all. Teaching software engineering is hard, and there are many professors who do a poor job of it. Hooray for tenure. However, there is a lot of interesting research on how to teach good software engineering practices within the traditional university system of courses and semesters; check out some of the papers in SIGCSE and CCSC conferences for examples.

Clearly, the education problem is not" solved," nor are the best practices widely adopted. I would like to know what *specifically* is it that you see as the problem, and what kinds of solutions do you propose. I'm always up for new ideas.

As for K.I.L.E.R's case, I sand by my earlier assertion: either your professor is a good one whose guidance you have not adequately sought, or your professor is a bad one whose advice should be ignored. In the former case, use office hours, email, and regular appointments, and avail yourself of time management tools and strategies such as milestones; in the latter case, find a new professor or mentor.

I would like to know what *specifically* is it that you see as the problem, and what kinds of solutions do you propose. I'm always up for new ideas.

The problem is evaluation. When someone delivers a project and passes with a minimum grade without any documentation, it's an incentive not to do it in the first place. Clearly a student working alone or in a small team of 2 or 3 doesn't need waste time creating good docs if the work is just to be delivered once and then forget about it. That's why good doc pratices should be enforced even when it is not necessary to make students pratice.

The problem is evaluation. When someone delivers a project and passes with a minimum grade without any documentation, it's an incentive not to do it in the first place. Clearly a student working alone or in a small team of 2 or 3 doesn't need waste time creating good docs if the work is just to be delivered once and then forget about it. That's why good doc pratices should be enforced even when it is not necessary to make students pratice.

Thats good for you if they enforce good documentation pratices on the place where you are learning. I'm almost finishing univ (just 4 to go, one will have to made next year). Now that i'm working on my own game engine in java I noticed how much of what i have learned from univ is basic to worthless. I'm mostly relearning everything myself and learning other things they don't teach in there or just teach so lightly it's a waste of time. One thing we can get from univ for a computer science course is bibliography, references, people with similar interests and free software, but otherwise, at least in the majority of the universities in here, we don't know enough to be a real engineer and know how to work like an engineer.

A lot of the stuff that I did at university seemed stupid at the time and I forgot about for years, but I have recently started to see the utility in it and realise that actually I was kind of being arrogant in discounting it at the time.

That doesn't go for formal methods for system specification though. I still maintain that class was a waste of everyone's time.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org