My question is not technical. It's more of a philosophical and really down to individual preference. I am designing and developing an application (web + desktop) and this just occurred to me and was wondering if you guys (programmers and designers) ever came across this before:
Some designers believe in making applications that will run 3-5 years down the line and any changes that come to them will be reflected on them without any need to resort to system core changes. As a programmer I know for a fact that this is never the case. Small cosmetic changes do occur but usually they die away after a year or two, as time progresses there will be changes that will require core changes and eventually you will make a new application.
Given the fast paced changes of technologies, designing an application for 5 years down the line is rather absurd, IMHO. Well I mean not designing, but the idea that this application will run for 5 years and the belief that we will not need to create a new one I think is living in a fool's paradise. I mean really, fellow programmers, most mission critical or basic small application that have a running flow usually are re-made/re-structured/re-organized/re-coded few years down the line anyway.
So my question is why keep to this attitude of having this perfect application that will run for a decade. It's stupid really, because you know for a fact that technology will change every year; new frameworks, new methods, new technologies will emerge and your client will want them. So, if you forgive my use of this phrase, WTF is the point?
I keep telling my designer that the application will be redesigned in a few years anyway, there is no point in trying to make it shoot lighting from its #ss because it just won't, ever. There is no such thing as a perfect application.
I hope you guys get my drift. Have you guys felt the same way too. BTW I have been in the software programming business for about 7 years now. If you really think about it, do you really think Facebook will remain the same 5 years down the line, for sure the design will change every year or so to remain "funky" but the core will change every couple of years. I am dead sure of that. Am I paranoid or what? Please tell me there are other programmers in the same road as I am. Anyone?
My approach is to design for change. This means writing the most maintainable code I can, keeping things loosely coupled and modular, trying to do things in as standard a way as possible so that other developers can quickly pick up on the code, etc.
I usually put a little more effort into future-proofing the database design, as changes there can be a lot more difficult than code changes in many cases.
I have worked at two different companies which had software products that were nearing 10+ years old. Although they had been extended with tons of new functionality and had been given many face-lifts, the core of the application was essentially untouched since the first stable release. This may not be typical, but if the architect is skilled enough, the system can be built to be modular and extensible enough to accommodate a surprising amount of growth.
"The biggest roadblock to a great plan, is the dream of a perfect plan."
I agree - designing the perfect system which can be elegantly resilient to every possible future change, is fruitless. Every successful project is a tradeoff: building flexibility where you're confident it will be needed (or where it's easy to do anyway); and building somewhat quick-n-dirty code where you believe flexibility/change is unlikely. If you analyze the system well and the client has a good idea of their needs/requirements (not always a given), you'll get that balance right at least most of the time.
However, the idea that the whole system will be replaced every 3-5 years by some newer technology is also a fallacy. For every client who wants the latest, newest, sexiest system, there's 5 clients that are afraid to part with (or can't afford to replace) their legacy COM/VB/MS-Access/whatever system that is a morass of spaghetti logic built-up haphazardly without regard to maintainability, flexibility, or extensibility. You don't want to be the one building that system; if you are, then you're doing your client/employer a disservice.
Personally, I would never set out designing any sort of app assuming it is going to be replaced within a few years. It is all to often those 'updates' and 'rewrites' get pushed off for quick fixes desired by customers who don't want to wait for an entire new application. Sure the requirements change, features are needed, but often they will be desired in the current iteration.
I mean, there are a lot of apps, languages, and design patterns out there that thought the same thing, and are still in use today. One that pops into my head is the y2k bug. Programmers in the 70's never thought their code would last 30 years, and surely someone would expand those year values to 4 numbers before the turn of the century. We all remember how that thinking turned out...
I beleive that if the core of the system is built on principles that haven't changed much in many many years, then the system fundamentally will not change much, most changes would be primarially aesthetically.
Some tried and tested principles that remain strong to this day are for example database normalisation, modularisation of code etc etc.
So it depends what you define as the core. For me, the core means the design of the system, which if done properly probably wont change much at all in the future.
It really depends on the environment. I find that our internal corporate applications are fully overhauled (often retired) within 18 months of launch. It isn't anyone's fault - business priorities change, requirements change, new systems come online. At the same time other system run for a very long time.
We certainly don't develop any application with the expectation that it will soon be retired but there are business needs that need immediate solutions and sometimes it is better to get the app online and in the hands of the end-users as soon as possible. We update, iterate, and determine the next best steps.
The data and data structures (often) need to be legitimately designed to last for decades. The algorithms, UI and everything else is expected to evolve rapidly.
If your data represents legal documents, financial records, you might be required to hold on to it for decades.
This, too, though can be taken to extremes. There are subsets of data that probably no one will care about in 50 years, like memory performance counters that might have been stored in the database.
I remember a quote from James Kovac I believe, in one of the .Net Rocks' podcasts where he described our industry as:
one where the only constant is change
which is why you should design for flexibility so that when changes come, and it inevitably will in most cases* you will have an easier job adapting/updating your application. That's not to say you shouldn't try to build your application on solid grounds, but just more important to have a flexible solution which you can change easily than the perfect solution the first time around.
*I know in lots of banks people are still using ancient applications because it's too risky to change them and they simply don't have the expertise to change them anymore..
Well I think the ideal design is completely orthogonal, but you just have to accept that it rarely works out the way you envisage. If you've never read The Pragmatic Programmer, it talks a lot about future-proofing your code.
Related
I client of mines do not care about elegant and well structured code. I am writing the applications from scratch with minimal 3rd party tools. I am using l2s, Recatcha, tinymce, lucene, and structure map.
I would like to quickly get the clients product to the market as fast as possible while sacrificing elegant code. Are there any tools out there that will enable me to rush the product to the market?
No client ever cares about elegant and well structured code. That's not why you write elegant and well structured code. You write it because it's shorter, simpler, it's faster to write, contains fewer bugs and it is easier to find those bugs.
ADD: I know what I wrote above sounds contradictory. When I started working, I didn't believe that either. I had to learn the hard way. So to make the point clearer: This is what typically happens when you don't try to write elegant, well structured code:
You'll introduce subtle bugs that lead to weird, unreproducible behavior and take 10 times more time to find than writing the code in the first place
You'll solve the same problem multiple times. Or, the other way round: The elegant solution would have solved a set of problems while the ugly solution will only solve one problem. Or part of one problem.
You'll repeat yourself a lot. That means more code to write, more code to maintain, more bugs.
You'll write code that you don't understand a week later. So instead of adding new features/solving bugs you'll waste your time trying to figure out why some piece of code works (or doesn't work)
You'll solve the wrong problems. This is by far the worst danger, and it happens too often if you try to save the time you need to plan the thing properly.
Good code is for you and not your client.
I don't think there exists such a magic pill.
But I would rather recommend you checkout Joel's 12 Steps to Better Code. Not all principles may apply to you (if you are not working with at least a certain number of people) but things like version control, how you deal with bugs, testing and others will help more than what you think.
Assuming that adding more team members is not an option, you can either:
work longer hours (live of coffee and pizza until either you or the project is finished)
defer some features for version 2.
sacrifice quality.
deliver late.
the choice is yours but option 2 would be my recommendation. A program with fewer features that works is better than a feature laden product that can't be relied on.
Bit of a cliché, but there are no tools that can get you the result you're looking for, only people. For that matter, there are no tools that can guarantee you robust, reliable, well-designed and appealing products that people will actually want to use – those are all problems that can only be tackled by meatware. Respectfully, I'd be careful about the whole concept of "rushing a product to market", if I were you: I'm sure you have your reasons for taking that approach, but more haste really does often make for less speed, and less desirable results.
When you don't have time to build a product to reasonable standards then it's important to know which parts you can cut corners on and which you can't.
The most important thing to get right is the interfaces between components. Make sure that they are correct and that coupling between components is as little as you can make it.
If for example you have a report generator that sometimes crashes, occasionally generates the wrong results, and has missing and broken features you can repair it later on when you do have time, or even scrap the whole module and do it properly.
If you've hacked the interface though, and it relies on other components storing their data in certain ways, or relies on the internal workings of other modules it becomes significantly harder to rip it out and replace it cleanly.
Don't skimp on the design of the high level modules and the interfaces between them. Keep asking yourself if I have to rip out this module and do it a different way, will it affect any of my other modules... The answer should as much as possible be know. it's "easy" to go and fix code, but not if it's all one big tangled mess. The small compoents don't need to be good as long as you can replace them easily later.
Obligatory comment - I'm not suggesting anyone writes bad code of course. Just that sometimes there are essential business requirements that make deadlines such that you can't do a good job of everything, and it is an important skill to know which things you can fix up later and which you can't.
So anyway to answer your question design tools such as UML drawing tools etc are probably more use than coding tools
Mostly you end up with this:
(source: scottsimmons.tv)
Another one that I heard a project manager once say about adding extra people to a team:
"It's not because you have 9 women that the time to grow a baby will only take one month."
I would recommend using a continuous integration tool such as CruiseControl.NET or hudson and writing many JUnit tests (or the C# equivalent).
This way even if you develop quickly and don't spend enough time working out all the pieces, the CI server should prevent you from producing bugs which will take you an extremely long time to find.
That said, I agree with what the others stated, you write elegant code so you (or your teammates) will understand it and not so your client is satisfied.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've just inherited a large project previously coded by about 4-5 people. The documentation consists of comments, and is not very well written. I have to get up to date on this project. How do I start? It consists of many different source files. Do you just dig in? Are there tools that can help visualize the structure/flow?
If you have a chance, I'd try and talk to the original designers and developers. Ask them about any major design issues or shortcomings of the project. Is the project in good shape and only needs maintenance or are there major components that need to be added or reworked? What are going to be the biggest roadblocks to maintaining the project? Take one or two of them to lunch (separately) if you have a budget for it as they might be more free to talk about problems outside of the office.
Talking to the users is also important for getting a feel for the current status of the project. Quite often they have a different opinion of how things stand then the developers do. Make sure, however, that they don't start giving you a list of all the things they want added or changed - you should take a few weeks to understand the project before you can start making major changes to it.
As for visualization tools, I'd start with the database design if there is a database involved. Tools like Microsoft Visio can create a diagram from an existing database. I find knowing the design of the database helps me wrap my head around what the programmers were trying to accomplish. Visio is also good for documenting program flow with some basic flowcharts though you'll have to create them yourself - it doesn't generate them automatically as far as I know.
Good luck.
I would encourage you to buy and read this book thoroughly. It provides you a LOT of information in this regard, much more than you will find here.
Brainstorming a little for you:
Step around in the application with a debugger, use a Static Code Analysis tool for which ever language you are working with...
Talk with people - both developers AND USERS to get a feel of the application.
Review the issue tracking system to see if you can see any recurring types of problem...
Are there tools that can help
visualize the structure/flow?
The latest Visual Studio 2010 allows you to generate architecture diagrams.
http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/
Try to find the starting point of the system and start digging from there. It sort of sucks to be in that situation, and chances are the comments might not be that helpful either. If the original developers didn't bother (or didn't have the chance) to document, chances are they never kept the comments up to date with code changes.
So time to bring the shovel... but don't just dig in blindly. One thing that is important is to understand what the system does from a users' perspective.
Concurrent with your code digging, you need to meet with a user (or the users' liason) and have him walk through the system, showing you how it is supposed to be used, for what purpose and what it and its subsystems are supposed to do. Moreover, attempt to understand what are the business pre-conditions and post-conditions of each major operation performed with this system.
Then map (or do a hierarchical) chart of the main functions of the system; classify them by category, purpose or module. If the system performs some sort of work flows or business transactions, attempt to chart some sort of state/transition diagram documenting each (and cross-referencing each state/transition to the subsystem or module in the system that is in charge for it.)
Once you have that, you can dig according to function. It will be best if you dig for a specific purpose, say, there is a bug fix to implement. You locate the logical module or category pertaining to that bug fix, you have the pre-conditions and post-conditions; then you can dig precisely on (or around) that bug fix.
If you just dig in without a guide (at least a high level one), you can be digging for months without getting anywhere (I'm telling you from painful experience.)
If there is no user manual, implement a draft according to your meetings with the users/users' liason. That could serve as a guide for implementing a developer's/administrator's manual for the system you just inherited (if there is ever a chance to implement one.)
If code is not on source control, put it on it. Doesn't matter what SCS you pick (could even be CVS, yuck!) What matters is to put it under source control asap.
Those developers didn't exist in a vacuum, they must have had exchanged emails. Identify other tech liasons they work with. Attempt to identify what other systems, if any, this system interfaces to (.ie. your databases, other's peoples databases, cron jobs, etc.)
But this could come at a later time. I think you should, for starters, focus on understanding how to use the system and what it is for. Let's call it understanding its business/knowledge architecture. Then dig according to that... or better yet, according to that and with the purpose of fixing a bug.
Good luck.
Use Profiler to see main functions and events in your project (the fastest way to learn framework)
Learn business logic very well to better understand the code
Documenting every new thing you learn - setup wiki (you will be surprised how quickly things are forgotten)
You can use Visio to draw Database Model Diagrams. (keep them close to you while studying the code)
These are the things that helped me when I inherited the previous project (50+ developers, 70+ GB database, 1 GB of source code and not even a single line of comments in code (maybe few :), and everything written in foreign language )
Use the debugger to walk through the application. That will let you go both deep and wide. You'll also be able to learn about how the code handles specific scenarios.
When you're ready to change something as #Jaxidian said, Working Effectively with Legacy Code is a great resource.
I was recently in a similar situation. What helped in my case was focusing on the changes I needed to perform on the project, and in the process of making those changes I learned about how the project is structured and so on. Sure, the first few tasks took a bit longer, but look on the bright side: I got stuff done and I got familiar with the project at the same time.
I'd suggest two things that may help:
Be productivity-driven. In other words, find a change that needs doing and use this to learn how that bit of the system works. Your changes may not be the most elegant without a whole-picture understanding of the software, but you will get work done within days/weeks.
Follow things from the user-interface. I.e if a change involves things a user does on a dialog, find that dialog in the code (relatively easy) and then work backwards to see what bits of the code provide data to the dialog, how the dialog interacts with the system, etc. Trying to find "where does X happen in the code" is very hard without good documentation, but finding "where is the code relating to this dialog" is quite easy and gives you an entry-point into the code.
Whenever I start a new project, I spend 2-3 days skim reading the code and making notes. I basically go through the entire solution from top to bottom and make a map in a text editor of each (significant) class in each project and what it appears to do.
The aim in doing this is not to completely understand the entire codebase, so don't worry if you feel you are not getting your head around it completely. The aim is that you end up with an index of where to go when you need to start on your first piece of work. You should also end up with a cursory picture of the solution in the back of your brain that will get filled in over the next couple of months. I always do this on the first few days as your superiors will not expect you to be productive during this time and you may never get another opportunity where you have the time to do so.
Also, do not rely on code comments for direction. Even with the best intentions they are often unmaintained and may lead to incorrect conclusions about what a class or section of code may do: a comment may lie but the code always tells the truth.
If you already have a team, you could charge each with a part of framework, and the result of their exploration should be registered somewhere, like a wiki. After that, give to each a task similar to something which is already done in the system (from the functional point of view)
For example: if a list of products is displayed in your app, you could display a list of orders (the complexity should be approximately the same), in the same manner it's done actually in the app. Than make it more interesting: try to edit it and save into DB.
Than switch the tasks and let the questions appear and than the first person who made the same task will show & explain how things are done.
Like that you'll see how the things are done pretty easy + your team will be up to date with this knowledge.
Presuming there is a database, start with the data model. Somewhere (Mythical Man-Month?) it was written "if I have your tables, I don't need to see your code."
Regarding potential tools, you may want to look into NDepend. It is a code-analysis tool, with an emphasis on highlighting the internal organization and dependencies of the code base (see this post for typical outputs), and spotting code quality issues. I have not used it personally, but Patrick Smacchia, one of the developers of the product, has a few posts where he applies NDepend to some classic apps (here is NUnit for instance) and discusses what it means, and I found them interesting.
Go and speak to the users or, read the manual and / or if one exists, go on a training course for the system (internal training departments will sometimes have put them together if there are lots of users).
If you don't know what it's meant to be doing then the chances of you being able to work out how it does it are close to zero.
What are good priciples for creating a scalable website predominantly C#? What design patterns are more common for a C# based website? Links to good books or articles are welcome.
I think these apply to all websites, not just C#
Set proper expectations
Scaling means different things at different times. Are you trying to scale up from your 1000 beta users, to 100,000 active users on launch day? Are you trying to handle constant growth without refactoring? Do you just want to make sure if there's a good old "Slashdot" effect on your site, you can handle it? These all require scalability, but some are very different than others.
Calculate the value of data
Often times people freak out about data loss. But really what people mean to freak out about is data consistency. I won't be really mad if the account I created 30 seconds ago disappears. I will be mad if the photo I uploaded of my trip to Prague is replaced by Halloween Harlots downing beer bongs. So if you are able to calculate the risk of data loss, its a fairly easy process to then calculate the impact, and make a real business decision on whether or not its ok, and if so, how much before it hurts you.
Simplicity trumps Coolness
I love block diagrams as much as anyone else, but how many times have you heard someone go "DAMN, this TV is SO WELL DESIGNED I have to buy it." More often than not they'll say things like "Sony hasn't let me down, and this TV LOOKS great, I have to have it!" Keeping things simple and modular, even if it means NOT using some really cool, ultra-abstracted infinitely scalable pattern, will allow you to scale when and where you need it.
You will not always be alone
The toughest part of your website (and any business) to scale is always people. Sure, by the time you need more engineers, you should be rolling in money so you can just hire 10 people and they'll rewrite the site to be maintainable. However, if you can just hire 2, and they don't immediately surf to the daily wtf to post your entire code base in a 7 part exposé ... you should come out ahead.
This is hard to answer without more details about your architecture.
Which version of .NET and C# are you using?
Are you using MVC or webforms?
Do you have multiple webservers connecting to one database?
When designing a website for scalability I start with having a lot of javascript that will be the controller, pulling information from the webservice, either a WCF app or .asmx service. This way the webserver serves out the pages, but after that the rendering is done by the javascript. This helps relieve stress on the webserver.
If you can have the webserver have all the static content and for any business logic have the code-behind call to another server that will do the processing, get info from the database and return back to the code-behind.
By having this separation, if you need to add more servers in one layer you can determine which part needs extra horsepower, and ensure that the webserver is only really doing one task, interfacing with the browsers.
If you could go into more detail about your architecture it would be helpful, as well as how much of a load you are planning for, then it would be easier to give a more detailed response.
Martin Fowler's Patterns of Enterprise Application Architecture (summaries on his website) are a good place to start. There's an awful, awful lot of components and technologies that can go into building a scalable website... load balancing, caching, application serving, database setup, networking, and somewhere in there is the actual code being written.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I want to design a 2D game idea with C#/XNA. Between school, project inexperience, limited resources, and other things that may cause me to bail on the project I am going to try to plan it out before I jump in:
What are some key aspects you've noticed in a successful personal project?
How did you (successfully) draw revenue the project (besides asking for donations)?
(Note: this is not the main purpose of my project but would be nice!)
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
What are some key aspects you've noticed in a successful personal project?
I suppose this largely depends on your definition of success. I consider a game project successful if:
It's fun. Enough that I want to play it after I've finished.
I learn something in the process of making it.
I actually complete the project, where complete is defined as having art, audio, and any other assets adequate for the style of game that I'm making.
It works under 'field conditions', rather than simply on my own machine/hardware configuration.
In my case, every project that I've considered successful has been one that I've done some serious planning on and committed to seeing through to completion. That's the biggest step for me to get past. A casual project that is the product of a bored weekend usually won't get finished.
How did you (successfully) draw revenue the project (besides asking for donations)? (Note: this is not the main purpose of my project but would be nice!)
Heh. Haven't managed this yet. But then, that hasn't been a concern of mine enough to do the work required to support it. Someone already mentioned the potential revenue from XBLA for XNA projects, which is a very easy avenue to success if your project is the sort of thing that translates well to the console. I've looked into it, but it isn't really appropriate for my projects so far.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Pen. And paper. I draw a lot of screenshots as guides and I'll usually have some kind of artistic theme in mind to go along with the gameplay. Rapid prototypes help here too; everything from making mockups of menus and various screens in a drawing program to making some simple interactive stuff in a throwaway project.
Write everything down. I take lots of notes and I've been known to have a laptop with notepad open on it sitting next to my development machine, to save me the trouble of alt-tabbing away from my code to type a quick note on what I'm doing. Some great ideas come out of the process of trying to make other things work and if you don't write it down, it didn't happen.
How do you bring an abstract idea of a game and making into a real product. What tools do you use in your sketching and planning?
Work iteratively as much as possible. I hate to sound cliche, but the whole agile model works really well for games. Start with that core 'fun' idea you have that inspired you to make a game in the first place and get that working in code. Maybe it's a single mechanic that you want to build puzzles/levels around or maybe it's more of a look/feel that you can capture in a single environment/level/whatever. Either way, if you can get a single example of it working right, it becomes a good check on whether the idea is actually viable and will likely give you some ideas of the different ways it can be implemented. That might seem kind of vague, but more specific advice would depend on any number of other factors (your choice of genre, audience, the specific ideas you have in mind, etc.).
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Peter Molyneux of Lionhead has said that he used to prototype all of his games with ascii art. If they were fun with that limited level of graphics, then they were worth continuing. While you might not be able to get that simple with some genres (and an ascii 3d shooter might be novel for it's own sake...), certainly worrying about finished art, audio, or other assets is something that can be saved for much later. In the end, if the game is fun to play, then getting an artist willing to work with you becomes a lot more trivial. I have, on many occasions, used copyrighted assets during my prototyping phase when I just couldn't stand to look at my own art any longer. Just be sure that you have anything like that replaced before you start distributing your project...
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Not sure exactly what you're thinking about here, but breaking barriers is what writing code is all about really. You're finding creative solutions to interesting problems. The web is a great resource for general knowledge, but in the end, it's your own time and perseverance that will create something interesting.
Best of luck.
What are some key aspects you've noticed in a successful personal project?
Don't worry about how it will turn out
Do it for fun
Don't plan it
Start small, don't think big
Actually code instead of procrastinating on so or other similar sites
If you want somebody else to use this game, make it non personal. Get somebody else who you can give demos to and get feedback from. Make the game very very simple. Build that first before moving onto something very simple. Then go for simple!
not sure :)
Plan with pen and paper sketches for window layouts and game flow. For look and feel, browse the web for slick looking sites you can take inspiration from.
Use notepad, and write the shortest list of things that need doing to make the simplest working demo. Only work on the things you wrote down otherwise you can get carried away on some detail and end up not producing anything useful.
Art is an important part of a game, and you can't have a finished product without it. How about searching the web for a collaborator who'd be interested in doing it for you.
If your stuck with something in your code, ask for help on StackOverflow! :)
Key aspects: Primarily, something that you are excited about. Make a game that REALLY gets you going, and you'll be motivated by your desire to share the finished product with others -- your end product's quality will probably be improved by your passion, as well.
Profitability: Well, since this is XNA and all, if you release a version on Xbox Live, you will earn 70% of the sales revenue that your game earns. Games can be priced for 200, 400, or 800 points (roughly $2.50-$10).
UI/Usability: For this, I typically go through a lot of playability testing...booting it up, seeing how things "feel," then tweaking things if they just don't feel right. I came across a lot of things that I never really thought about before (fade-ins/fade-outs for menus, repeat rates for keys, and so forth), and play-testing is one of the more effective ways that I've been able to identify issues like that. If you've got friends, you can ask them to give you feedback as well.
Planning Tools: Truthfully, I just make a list of the things that I want to include in the overall game concept, then slowly get more granular as I iron out more and more of the fine details. Certain ideas inevitably change after playtesting may reveal them to not be as fun as you had imagined they would be, of course. I haven't ever seen a huge need for any formal tools for this process, though, but I will give the disclaimer that all of my projects have been fairly small in scope and have not been professional-sized undertakings or anything.
Art: This may not always be an option for you, but I have a few friends online that are gifted with art skills -- I solicited interest, and got some volunteers. I presented the option to earn a cut of whatever royalties may come in, but most of them were happy with an attribution in the credits and a chance to see their work in a game that's playable by people all over the world. Regarding small things (icons, etc), stock/royalty-free art can do the job in certain cases, too, but I wouldn't recommend relying on it.
Breaking Barriers: Not sure what's quite meant by this question, but generally speaking if I've come up against some sort of unforeseen issue (technical/implementation challenge,
gameplay-related, or what-have-you), I'm able to either solve the problem or come up with a suitable work-around if I put my mind to it for long enough. Did you mean something else by this?
Some great thoughts given in these articles:
http://www.flatredball.com/frb/docs/index.php?title=Tips_for_Completing_an_Independent_Project
http://makeitbigingames.com/2006/06/five-realistic-steps-to-starting-a-game-development-company/
http://makeitbigingames.com/2006/02/five-foundational-steps-to-surviving-as-a-game-developer/
First of all - I know universities don't tend to teach this but you really must do it... get source control going. I would suggest installing TortoiseSvn from here: http://tortoisesvn.net/downloads
With TortoiseSvn (a subversion client) - you can create a repository on your USB Flash Drive and carry it around with you, so you always have a copy of your project files. More importantly you can have more confidence when you make changes - because it keeps a history of the changes you've made. So if you break something, you can revert to the most up to date version on your usb flash drive... or even an earlier version if you wish. It also provides ways of showing differences between file revisions, all from the explorer shell extension.
For a personal project the key thing is to keep motivated. You keep motivated by setting yourself attainable tasks. Aim for something attainable. Always make sure you can build your project. Concentrate on adding new functionality while keeping the old stuff still working rather than building up huge nicely designed framework that might end up going no where. If you write your code well, you can refactor and abstract later after you figured out what game it is you actually want to build.
I would advocate a todo list of some kind... something like the spreadsheet found here on Joels site: http://www.joelonsoftware.com/articles/fog0000000245.html
If you want to get fancy, I would suggest something like Trac: http://trac.edgewall.org/
Trac is a wiki, to-do / bug list and repository viewer all in one. If you get someone else working with you on a project, collaboration with source control and a shared wiki becomes more useful. It's also good to work with others... you can keep each other motivated.
The Wolf fire blog recently had some interesting design ideas and cited serval sources here: http://blog.wolfire.com/2009/02/design-principles-from-tufte/
As for getting money, others have already covered the community games thing.
Art assets - there are a few places to find these. Scout the forums at www.gamedev.net. Def look at this blog here for some excellent art (and game design ideas) http://lostgarden.com/
Others have suggested keeping tools simple - I would agree. The simplier and more accessible things are when it comes to project planning, prototyping and design - the more likely you are to use them. As long as you can communicate with yourself when you revisit something... or other people when collaborating, it's a good tool. Set yourself attainable goals, and get on with it :-)
What are some key aspects you've noticed in a successful personal project? Focus on something that actually works.
How did you (successfully) draw revenue the project (besides asking for donations)? Not directly. However, skills get you a job. Build skills.
How do you plan non-programming aspects like window layouts (UI), flow of game, and look and feel?
Build the inside -- the core data model first. If the data model works, everything else is far simpler.
Build unit tests for the model to be absolutely sure it always works.
Work out "flow" and other control issues based on that model.
Build the GUI later, once you have a solid foundation.
How do you bring an abstract idea of a game and making into a real product? What tools do you use in your sketching and planning?
I do the following.
I use Argo UML for technical UML diagrams.
I write documents with my end-state in mind. What the API will be like. How it will work. As part of writing the documents, I clarify my thinking.
I write code in pieces, with unit tests, and refactor ruthlessly.
With limited resources (artistic talent and money), how do I create some of the art resources I need (besides stock art)? Or should I not worry about that until I have a finished product?
Find an artist who wants to help.
Finally, how do you break barriers in your code (may it be knowledge, time, or perseverance)?
Build the inside -- the core data model first.
Spike elements of the technology separately from the main development. Build separate proofs of concept for each new technology. Do not try to integrate unknown technology into the final product. (Many of my customers try this and it doesn't work.)
Having had an experience with game development in my teenage years what I can suggest is the following:
Make sure you have the story ready, or at least the basic points before you start implementing. Also make sure that you do not change the genre of the game while in dev stage. (yeah, I know, this is stupid, but could happen ;-) )
We actually drew some revenue when we managed to sell the game to a software house, however because we had already spent too much in the dev process, we just broke even (i.e. to little profit). So be careful what you spend beforehand
From what you said, you're still in school, so take advantage of that. There will surely be folk out there with artistic talent, most probably friends of yours. Make a team. That's what we did and it was all the way back in 1993! At that time it was even harder. We introduced our talented friends to 3D-Studio (v3 back then) and some even to computers in general, and believe me, before you knew it they were making brilliant art out of it!
Use pen and paper to create the story boards (even better with the friends mentioned above. Decide on the development approach. I.e. what libraries will you use etc. Read a lot about game dev. Make a plan of the project. Give it your best ;-)
Unlike us back then, you have the web to help you. For whatever problems you have with your code it is easy to look it up. StackOverflow didn't exist back then!
And of course make sure you have fun in the process otherwise it will eat you alive!
What are some key aspects you've
noticed in a successful personal
project?
Just do it!
I've noticed that the majority of enterprise web apps I've worked on over the past few years have seemingly mis-used the powers of oo.
That is, what once would have been perhaps 1000 lines of HTML and script, has often now morphed into 10,000 lines of code, 50 classes, and 2000 method calls to do basically the same thing. I.e. oo and layered architecture appears to be over-used and/or ill-used, often leading to longer development times, higher-cost, and often nightmarish maintenance.
How often are other people seeing this happen?
How can oo be effectively utilized to, as the Buddha himself has said: as much as possible try not to harm...as much as possible try to help...
"The road to hell is paved with the best of intentions."
I haven't personally encountered this myself, but all the times I've heard stories it seems to be an issue of architecture astronauts (people who spend too much time thinking) or bad developers (people who spend too little time thinking).
In the earlier days of programming, you didn't see as much of this because of the limits of the hardware, languages, etc.
However, developers are now are trying to focus on writing code that's understandable by humans for loose coupling and higher maintainability by incorporating as many design patterns and OO principles as they can, but just like everything it can be over-done.
On the other hand, some developers might just not be thinking enough about the problems they're attempting to solve and writing extra code just because it gets the job done and not thinking about the bigger picture.
In either case, developers might not be malicious or even incompetent and want the best for the projects their working on, but they still over-do principles simply because they are trying too hard.
So I would say the solution is to remind developers to use OOP principles as guidelines, but just that. There comes a point when you have to find a happy medium between thinking and programming and just stop thinking and start programming.
See: Jeff wrote a good blog post about just this kind of thing: KISS and YAGNI.
I see these all the time :( Basically if people are going to do a mess they will do it trying or not to use oo design. It gets equally awful on either case.
Update 1: it is important to understand how/what will be reused (but not going crazy on it as that would hinder productivity), since we don't want to get tons of classes where every single one of them aren't reused and fulfill tons of different functions.
Basically the main issue is understanding and caring for what is being built, as you could apply oo, tdd, ddd, anything, and if the devs doesn't understand what they are doing it will end up in the same mess ... or worst :(
Bottom line, these things do help, but they aren't magic, they won't replace the developers skills to create maintainable code.
Update 2: Also note that a checklist or some bullet points won't do it. I mean I love SOLID, and plenty things going on and I think they really clear things up, but they usually make the most impact on the people that have been trying to avoid the mess.