Why am I an idiot?

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’s called over-engineering.

Try to write stuff in the most simple way you can think of. If something requires some changes at some later point… well, change it then.

@K.I.L.E.R : I’m probably in the same case, you know… But the point in over-engineering is always “well, it could be useful later”… which is what I end up thinking too often.

YAGNI

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.

Thats one of the great thing with 4k games, you really can’t over-engineer :slight_smile:

If this is the case in your classes, you really need to take a course with a good professor. :wink: 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.

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.

All IMHO.

Too much planning and not enough hacking? :wink:

[quote]Does anyone have any advice that which can help me remove myself from my self destructive behaviour?
[/quote]
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.

the solution is in ur mind buddy.

good luck to you.

Thanks for the advice everyone.

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.

So you can see that your problem isn’t unique.

Keep it simple, stupid.

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.

yes, listen to appel. if there is one person that can tell you why you’re an idiot, it’s appel!

kidding, appel. you I love you. in that heterosexual way :wink:

I love you too, woogley… :stuck_out_tongue:

From the “Tao of Programming”, great read…

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!!

It might be a good idea to study some anti-patterns so as to know what not to do. Based on your description, here are some that you could be suffering from:


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.

And you’d be right. The only time it becomes a problem is if you do it thousands of times a second (game loop…)

Cas :slight_smile:

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.