Engine Dev or Game Dev...Which one goes first?

[NightCabbage]

Hehe, just to put the obvious out there:

I think it's good to have a balance when you're coding.

Don't take either hard-line approach - do a bit of everything.

So before you start typing, think about what you're trying to achieve. Plan it around everything else that's in the system or going to be in the system. Don't spend too long doing this, because for all you know you're going to change your mind later But at least plan a little. This way you can save a lot of time later, and often come up with better design and better code.

[ichineko]

That applies to the most other answers here, including yours. Beginning a sentence with "The truth" doesn't change that

Everyone makes assumptions, but some assumptions are more dangerous than others.  The inexperienced believe they can think their way around that inexperience, the experienced know better.

Balanced isn't relevant, we're talking about a specific context, an inexperienced developer trying to write a game.  That's automatically unbalanced, said developer has no idea what a balanced approach is, much less the ability to take one.

Instead of believing you're smart enough to 'figure it out', it's better to admit that you're not, and *plan* for mistakes by making them as cheap as possible.  One of Erlang's strengths isn't its ability to never fail, it's the ability to minimize the impact of the failure.  It's the same idea here.

If you're writing YAGE(Yet Another Game Engine), have at it, use your prior experience to try and navigate some of the pitfalls you've seen.  Until then, admit that you suck, and work on minimizing the impact of your mistakes.

And to be clear, by inexperienced, I mean inexperienced writing that type of software.  An experienced game developer trying to implement a CMS is probably going to make a bad job of it, no matter how many years they've been developing.  Until their 2nd or 3rd CMS.  In other words, we're all inexperienced in some area's that we may have an interest or a need in.

[MorleyDev]

I'm not saying use upfront design. I think upfront design is pretty useless because code changes and evolves.

TDD is not upfront design, it's about letting the code evolve and writing it in a way that makes it easy to evolve. You can do that without TDD, I just find TDD makes this easier for me and gives me a peace of mind about refactoring without breaking anything. I wouldn't have that piece of mind otherwise, and I like that piece of mind. Also it makes it easier for me to track down and isolate bugs if I discover them.

TDD is, in fact, all about:

"I don't know what is best here, so I'm going to do the simplest thing that works and see how the usage shakes out".

It's all about expecting mistakes and making them as cheap as possible by making it easier for you to correct them as you let the code evolve.

Code evolves, you can't design it all upfront and you can't fight this. What you can do is learn to work with it, and always remember code can change. Don't resist change, and try your best to not code in a way that resists change.

Yes, you have to let the code "shape itself" as it grows, but you also have to remember that ugly code will make this difficult and can impede this growth. The trick, which you get better at with experience and nobody is ever perfect at (because nobody is ever perfect), is to write code that gets the job done and is easy to extend, debug and refactor.

I try and do that through TDD, others may want to do BDD (which I don't much like), others just throw code and see what sticks. What I was trying to convey is that keeping in mind this goal of getting the job done in a maintainable manner, I reckon, can help limit the times you code yourself into the trap of difficult-to-maintain code.

And of course, always refactor as you go. Refactor constantly whenever you see the need for it. Refactoring is possibly the most important step in coding.

A lot of the above also applies against writing an engine first, an engine typically needs something to evolve out of otherwise it's just another example of "upfront design". Things like Unity have the requests and needs of the users which can be used to drive development. But a personal project doesn't even have that...

[ichineko]

One thing I like to tell people is the following:

If you cannot couch your argument in anything but 'maintainability', it means you have a weak argument and you really need to look at the alternative.

readability, maintainability, scalability, these are all nebulous ideas that you can't really put your finger on.  As such, they're the go to for people who have no real concrete basis for their beliefs, whether that's due to inexperience, or emotional appeal (ie, they just want to do it that way).

I don't mean to pick on you, but talking to me about maintainability is like trying to speak to an Atheist about God (or your deity of choice).  I'm just flat not interested in hearing it.

I'll argue until we're both blue in the face, until the conversation turns to maintainability, readability, or scalability.  At that point I check out to go do something worthwhile.

[MorleyDev]

Isn't maintainability just a shorter way of saying "ease of making modifications and additions without a big risk of breaking the rest of the program that works, and ease of debugging when something goes wrong and the cause tracking down"?

That's what I always thought they meant, unless there's some other definition I'm not aware of regarding code? I can gladly go through and change it to be more clear if that helps.

[Nexus]

Instead of believing you're smart enough to 'figure it out', it's better to admit that you're not, and *plan* for mistakes by making them as cheap as possible. [...] Until then, admit that you suck, and work on minimizing the impact of your mistakes.

That sounds already different from "Throw your code out there [...] Don't worry about style, structure, or anything else". Have you considered that reflecting about code in advance can minimize the impact of mistakes, too?

I am not saying the beginner should write an engine first, but I'm considering it a bad idea to not spend any thoughts at all, just because of small experience. But since you have not responded to my previous argument and now write a whole post about why you don't like the (in my opinion clear) term "maintainability", I doubt more and more that this discussion will yield meaningful results...

[ichineko]

Isn't maintainability just a shorter way of saying "ease of making modifications and additions without a big risk of breaking the rest of the program that works, and ease of debugging when something goes wrong and the cause tracking down"?

So maintainability means familiarity with the codebase? 

http://www.infoq.com/presentations/Simple-Made-Easy

Really pay attention to his distinction between simple and easy, this talk is phenomenal.


Maintainability is important, but the problem is that it isn't concrete.  I could argue The One True Brace Style and use maintainability, but at the end of the day, as a developer, having the brace on the same line vs the next has no bearing on my ability to read the code (and I question anyone who claims it does).

At the end of the day you have truly beautiful code, truly awful code, and then there's this huge grey area in the middle.  Most code falls in that grey area.


Nexus,

I can't respond to every little thing, if there's something in particular you want me to respond to, let me know what it is.  Having said that, as you discovered, my position is not the extreme of 'absolutely no thought', I didn't respond to that particular point because there was nothing to respond to and I didn't want to get into a rousing discussion over whether or not it was a strawman argument (and I still don't).

[MorleyDev]

Let me put it this way, if I gave you one massive main function that did everything and asked you to add a feature or fix a bug, it would take you a lot longer to figure out what to do than if I it was neatly ordered into well named and loosely coupled classes and functions.

Going along the shades of grey, then you must admit there are things closer to the former, and things closer to the latter, and it is desirable for code to be closer to the latter than the former.

You could even quantify that in a scientific study by having "ugly" and "neat" code that accomplishes the same goals, giving it to a bunch of programmers and timing how long it took them to finish certain tasks. When looking at the time taken for these tasks, the hypothesis would be that the "neater" code should take trend towards taking less time.

Going back to code after even a couple of weeks, I find, is very similar to coming to it with new eyes. I have to reacquaint myself with it, which takes time. Not as much time, usually, as new eyes. But time.

And you could likewise quantify that in a scientific study by having a bunch of programmers write code in a variety of ways, come back in a couple of weeks and be asked to perform a task against it. When looking at the time taken to extend, the hypothesis would be that the "neater" code should trend towards taking less time to perform the tasks.

At my work, the old code has parts where it's a mess of inheritance and what we now at work consider poor practices.  Whenever the business requires us to add something to that old code, we dread it because figuring out where to make changes and what to change takes a lot of time.

The new code is a lot easier to understand, extend and debug. I can get to grips with the parts of it I've never seen before a lot faster than the old code because of this, I can see where I need to make those light-touch changes and track down where bugs are a located lot faster.

And because it's got decent tests around it, often identifying a bug is just creating a black-box test that forces the bug to manifest itself. And I can fix the bug with all the other tests still green, meaning I can have some peace of mind I haven't broken it completely and more importantly, if I have broken something I can see that immediately without waiting for it to fail QA.

The legacy code is a time sink that costs the business money because we can't work with it as quickly as we can the newer code, even when we have still never seen the newer code before (and this is a massive code-base so that's not uncommon).

Yes, most code ends in that huge grey area. Nobody is perfect and no code is perfect code. Doesn't mean we shouldn't try as hard as the needs of practicality, business and time allow.

Ultimately I think you're getting hung up on a word instead of my point of "remember you'll need to work on this code again, so don't make it too spaghetti-like in the name of 'banging it out', because you'll just slow yourself down in the future". Time is money, I find the time debt built up in implementation is paid back when I need to debug, refactor and extend.

You know, I think at first we were arguing for pretty much the same thing. I wasn't arguing against "banging it out", just saying it may be wiser to try to do so in an intelligent manner even if it's a little slower. And of course, refactor mercilessly and constantly. As soon as you finish something, look to see how that could be refactored to improve it, and then refactor. Refactoring is not a last minute thought, it's a vital step after all.

If you're going to argue it accomplishes something, you also have to argue how or the how has to be self-evident. I may have failed to do that adequately, and if so I apologise.

[FRex]

Maybe ichineko is a uni coding teacher? He has their attitude(he really does). They seem to have switched their head with their a**.

one massive main function that did everything

Sounds like the practices some C teachers at my uni endorse, just one .cpp file, everything in main().

You could even quantify that in a scientific study by having "ugly" and "neat" code that accomplishes the same goals, giving it to a bunch of programmers and timing how long it took them to finish certain tasks.

Again, figuring out what spaghetti code does(and I mean extreme spaghetti code, something that should warrant getting authors face bashed in) is the exam around here, along with writing complete game in sdl or whatever else(I'm so using sfml for that bullshit..) and then compiling it on linux, three months into C 'study'. Good luck begginers..
The 'throw it out there and make it work' attitude is somewhat strong in teachers around here.
And also the attitude of 'If I say so you must listen and I don't have to explain my decision'.

[masskiller]

The 'throw it out there and make it work' attitude is somewhat strong in teachers around here.
And also the attitude of 'If I say so you must listen and I don't have to explain my decision'.

At least here in my country there's different approaches, while some professors go for lumping everything in one place, others go for a big class structure, some say that software designers would be unnecessary if all programmers were good programmers (a bit extreme, but  I kind of see where he's going).

The pattern goes in that most older professors go for lumping while the younger ones tend to go for a structured way of doing things even if sometimes going with old practices (unnecessary inheritance and polymorphism being one or using C when they could use C++ just because they're used to it).

In my opinion I think that making things work in order to understand them and then going for a structure once you do is the right choice.

Since you can't know how to build something if you don't know what you're building it with. Of course the testing takes time, but once you know your all-around environment you can make well thought structures without taking too much time because you already know how things work.

[ichineko]

In my opinion I think that making things work in order to understand them and then going for a structure once you do is the right choice.

Since you can't know how to build something if you don't know what you're building it with. Of course the testing takes time, but once you know your all-around environment you can make well thought structures without taking too much time because you already know how things work.

Basically.  Software is emergent, it's a mistake to think you can successfully plan ahead for something you've never done.  Software developers tend to be intelligent people, but they put too much faith in that intelligence.

At my work, the old code has parts where it's a mess of inheritance and what we now at work consider poor practices.

Lots of inheritance was a 'best practice' for many years.  Who do you think wrote that kind of code?  The ones who believe you should do the simple thing and move on, or the ones who believe you should think deep thoughts and write 'maintainable' software?

What things are you doing today that the future developers are going to complain about because you architected it in such a manner as to cause them undue pain?  What best practices are you employing now that in 10 years we'll know has a tendency to lead to difficult architecture?

I don't know, and neither do you, but the difference is that one of us is moving forward as if we do.


And that's a major reason why I dismiss arguments about maintainability.  Well, that and the aforementioned nebulous nature of it that causes people with weak arguments to fall back to it constantly.

So at this point Morley, it's safe to say you've continued trying to press the maintainability argument, which means I'm finished with the conversation.  I'm just not interested in something that's neither actionable, nor concrete.

[MorleyDev]

Your issue with maintainability is you perceive vagueness in the goal, so I went out of my way to try and clarify everything without vagary. I didn't even use the word maintainability in that post, so I'm not sure how you can say I was still "pushing" it.

Heck, at this point I'm willing to say you're arguing for the sake of arguing since my entire argument has included your basic point of "just smack it out", but with a single caveat of "try and remember you'll be seeing that code again".

This is not upfront design. I have never called for upfront design, and been calling for, the entire time, doing the simple thing and moving on. Light touch changes, and try and code in such a way as to make light touch changes easy to do.

Don't write a lot before you refactor mercilessly, write a single part and refactor that mercilessly. Then write the next part, refactor mercilessly. Then the next, refactor, then the next, refactor, then the next, refactor. That way the code evolves and the constant refactoring keeps it neater.

You haven't responded to a single point in my post, simply dismissed it without showing you even read it beyond one line, which you quote mined completely out of context. Remember, I said what is now considered poor practice.

I fully allow future best practices will not be the same as current best practices, languages and tools evolve. These new practices are better. They continue to get better? That's amazing, can't wait. Until then, I fail to see the evil in trying to do the best you can with what you've got. Especially since whilst it may not help in ten years, but ten days? Ten weeks? Ten months, even?

We have refactoring and code completion tools not available those years ago, and so we can do things with ease that would have been difficult those years ago. And that has driven a lot of practice changes and will continue to do so.

And when I say a mess of inheritance, I mean things like deep inheritance structures with god parent classes that contain behaviour that depends upon their children's behaviour. That kind of mess.

[Nexus]

I can't respond to every little thing

Sure, but you can write two posts to explain your problems with the term "maintainability". I know it's easier to pick single words out of context instead of responding to arguments, but it's not the base for a discussion.

Lots of inheritance was a 'best practice' for many years.  Who do you think wrote that kind of code?  The ones who believe you should do the simple thing and move on, or the ones who believe you should think deep thoughts and write 'maintainable' software?

In C++, there are several problems. Modern C++ techniques have only come in the 2000's with authors like Meyers, Sutter, Alexandrescu. And at the moment we are only seeing the first practical implications of C++11 being more and more supported. People interested in the language experience progress first, it takes a while until the "average developer" learns new idioms.

A second problem is the vast amount of terrible literature for C++. Many books have taught an antiquated C++ style, close to the beginnings at "C with classes". The same is true for C++ libraries, it is not easy to find a well-designed API as in SFML, especially in the field of game development. Inheritance overusage was, and still is, a big problem. Not only in C++ -- take a look at the Java standard library, especially the collections. Java has fewer abstraction tools than C++ -- in C++ they often were not used, although available.

I believe that this "not-usage" is not only a result of small practical experience, as many experienced people (in terms of finished projects) still don't use modern C++. It is rather also a consequence of the difficulty to find good articles or books, which in turn is due to the complexity of C++ and the slow spread of knowledge in the community. A lot of techniques can't be learned only by programming, thus I find it important to read about them, and to try to apply them in projects, beginning with the first project.

It is a fallacy to say "look, maintainability regards led to these bloated hiearchies, therefore it is better if we do not do it". You can't just leave out all the cases where intense planning resulted in good code design.

[ichineko]

MorleyDev, a rose by any other name is still a rose.


Nexus,

that's revisionist history, inheritance/type based polymorphism had been a part of C++ for 15+ years at that point.

In general, code was not written like that because people were just starting to figure out the ramifications of the "new" C++ standard, it was written like that because as an industry that sort of architecture was a best practice.  C++ developers didn't start preferring composition over inheritance, the industry did.

Todays best practice is tomorrows mistake

It is a fallacy to say "look, maintainability regards led to these bloated hiearchies, therefore it is better if we do not do it". You can't just leave out all the cases where intense planning resulted in good code design.

You are not understanding me.


maintainability and scalability arguments are roughly the same in terms of usefulness.  Here's what I mean.


We need to do X because it's more scalable
vs
we need to make sure we can handle 10k concurrent users even though we're only estimating needing 3k concurrent users.  The business leaders tell us they expect us to double in size over the course of the first 6 months, that should give us breathing room.

One of those will lead to much better decisions than the other.


Likewise with maintainability.

We need to do X because it's more maintainable.
vs
We need to make sure this algorithm can be changed out easily since we're not sure exactly what the performance requirements are, but we know that this is going to be integral to said performance.


And look at the counter-argument

we don't need more maintainability.
vs
No, I don't think that piece is going to be the bottleneck for performance.  Why don't we stay simple, slap this algorithm in, but with the idea that we may need to abstract it later.  We'll get something up and running quickly and then test, because I think we're going to find the performance bottleneck is going to be the DB I/O, not the number crunching.


One of those leads to a more valuable discussion.

Which is why I say, if the only argument you have for doing a thing is that it's "maintainable" or "scalable", or "readable", then you have no argument.

Lets write tests because it's changeable.  vs We're writing accounting software, which can get our asses sued, so for the calculation module, we're going to Unit Test.  We're also going to implement code reviews, but only for this module because both of these things have an up front cost that isn't worth it for the rest of the application.  risk vs reward.

What tends to happen is that when people don't have the knowledge either due to inexperience or external factors (business doesn't know what's going on, the software is new, what have you), you need to be making concrete decisions based upon that lack of foreknowledge, not based upon 'maintainability', et al.

And that's the context we're speaking in, someone who is learning.  It is better to stay simple, and refactor mercilessly, than to wax poetic about how you have 90% test coverage.

It's all about making good decisions, and basing your decisions on something as nebulous as "maintainability" rarely turns out to be good.

[MorleyDev]

Well ichineko, now I'm convinced we've been arguing for pretty much the same thing xD I may have not been expressing that properly, if so I apologise, my mistake.

To repeat and I hope in a clearer way: I've been trying to push the idea of doing things as needed, and anticipating the fact you can't plan for the future. Trying to remain able to react quickly. Which is especially useful as code evolves because things will change a lot in those early stages as you learn more about solving the problems you face.

Don't make concrete decisions, and as an extension try not to let your decisions become concrete by accident. You know, expecting things to need to change so not burning your bridges behind you, so-to-speak...