Nice little story Ben, it was a fun read

Talking about flowcharts...there is always Diagram Designer:

http://logicnet.dk/DiagramDesigner/

Completely free, and open source to boot!

cheers,
Paul

I'm not a big fan of planning either, and I especially hate flowcharts (they use them at work for diagnosing electrical faults on the railways, but who can carry safe working, tools, safety gear, rule books and flow charts everywhere lmao).

If it's a big project you obviously need some sort of planning, miss-planning under a thousand lines of code is nothing, try 90000 lines and you didn't write it, now that is a lot of fun to fix lol.

In this matter, if you want to do professional development, I would recommend taking some software engineering courses, although you must be careful about the institution selection as there are some outdated and some new topics in this area.

In the examples you have mentioned, they all seem to correspond to Quick and Dirty approach. However, there are other philosophies available.

If you have are working alone or have small teams, I would recommend adapting some sort of agile development techniques. Also, remember not to reinvent the wheel and use design patterns, apply refactoring often and always take into account quality attributes, and non-functional attributes when designing your software.

I think calling "Applications Architecture Design" the "Planning Stage" is highly inaccurate. The planning stage usually involves specifying software requirements, after which the design phase is specified. Software Architecture is a wide topic that can be interpreted differently in different contexts. I personally would call it a high-level representation of your project that exists during entire development process.

It is a common mistake to think that making some diagrams constitutes the planning, design and/or other stages: it's actually only small part of it and sometimes even optional.

P.S. In our own game studio we use some of the practices from extreme programming approach, focusing on iterative prototype development and refinement, and we rarely use diagrams per se.

Wow, lots of feedback! Great!

@Paul: Thats quite a nice find (Thank god it works under wine, although what doesn't these days?) I'll definitely include that in the follow-up which I hope I'll get time to write soon.

@Chesso: I just thought of this example after my recent entry into networking and that it would be near perfect. I usually stick by a rule of thumb that if theres more than 2500 lines to it, it really deserves to be in its own unit Beyond that, the object browser becomes counter productive in the time it takes just to look for which type/class that function is in...

@Lifepower: I think you will find that theres' a lot of 'quick n dirty' happening at this period of the digital age, after all, when one gets down to the basis of an 'app' like you find on android/the iPhone - that is effectively a quick and dirty solution to writing a better OS that has that functionality built into it. Thats a lot of links for me to digest there, I never learnt programming philosophies - I just had something to do and tried to do it best I could with my knowledge at the time. Its only from experience I found that some approaches worked better than others (or not at all).

I just thought I might share a 'this could happen' scenario with what could be a new(er) programmer. I'll make sure I include those links in the follow-up too.

Originally Posted by code_glitch

@Lifepower: I think you will find that theres' a lot of 'quick n dirty' happening at this period of the digital age, after all, when one gets down to the basis of an 'app' like you find on android/the iPhone - that is effectively a quick and dirty solution to writing a better OS that has that functionality built into it.

I'd speculate that OS on Android and iPhone wasn't developed using quick'n'dirty approach, but who knows.

However, I think mobile operating systems such as those on BlackBerry and Android were developed quite intelligently - using minimal hardware-dependent implementation and a virtual machine with the rest of functionality made in Java, so for a new hardware you don't need to redo everything.

Originally Posted by code_glitch

Thats a lot of links for me to digest there, I never learnt programming philosophies - I just had something to do and tried to do it best I could with my knowledge at the time. Its only from experience I found that some approaches worked better than others (or not at all).

I think on game development sites, especially mainstream ones like gamedev.net there is still little information about software engineering, even though the process of game development is built around an actual software product.

My suggestion for taking courses was for everyone who wants to make the development more efficient. This is easier than learning this topic by yourself as it can get quite bulky and even boring. However, for people of all ages that don't mind putting their pride aside and learning something new, it could be a great investment. I myself am taking two courses on CUDA given by Nvidia specialists next week, even though I already had CUDA apps running and have read several books on this topic; it is still an opportunity to strengthen the knowledge and experience.

Any idea why Nvidia has decided to slave on with CUDA over OpenCl?

Well, my first guess would be that CUDA is developed by Nvidia itself, while OpenCL is an open standard. They have done it before with CG vs GLSL/HLSL. It also happens that in our game studio we have 7 Nvidia video cards, 3 Intel and only one ATI video card, so CUDA is the way to go. In any case, my interest in CUDA is mostly for research, but this is an off-topic.

Fair enough. From my brief look at CUDA it looks like a battlefield to get rolling in. Anyway, best of luck to you and your CUDA code.

(...)I have many projects, maybe even more than a dozen, that I have never completed(...)

Man, this is sooooo... familiar to me.

And yes: the only projects that I finished are those that I planned.