How do I properly plan how my website will work before coding?

Question

I am creating a web hosting service for gaming communities (similar to GuildLaunch or GuildPortal). I am having some trouble with getting ahead of myself, and things such as:

• Coming up with better ways of doing things later, after the original idea is already implemented
• Realizing a feature won't work (but coded 90% of it) for an obscure reason that was overlooked
• etc

I know I should be planning better, but I don't know how to go about it properly. What is the best practice for planning a website of this size? Ideally, I would want to have a set-in-stone document outlining every aspect of the website, with all the kinks worked out already.

Thanks.

Answer 1

May be you should try BDD (Behavior Driven Development). Cucumber for example.

Answer 2

I like to think about all of the different things that are strictly critical for my site to work. Think first in terms of how a user would interact with the site, what kind of information she would want to store or retrieve, and how she expects that to look and work. Write out a list of all of those features, supply as much detail as you easily can.

Take that list and sort it according to how difficult any feature might be, how much it affects the rest of the site, how important that feature is.

Good job, you've just written a spec. Now you can write any code you want, according to any methodology you want (TDD or some such) but with a spec in hand, it will keep you focused on the important things. If you find you're working on something that is not in the spec, first ask yourself if it really aught to be in the spec. If it should, go ahead and add it, but if not, drop it on the floor.

Staying out of trouble, avoiding getting90% through something only to find that you've been chasing a red herring, can be tricky. The first way to avoid that is to think about the spike solution, the simplest, dumbest, possibly broken, solution that could possibly mostly do what you're talking about doing. A spike solution is usually less than 6 lines of code, sometimes it's just one. The idea is to get it working as fast as possible, so that you know what actually does work. Then you can improve the spike solution to be a complete solution by adding support for all of the corner cases you need to worry about.

Another thing you can do is to focus on rigorous automated testing, both unit testing, and functional testing. Make your tests run as automatically as possible, so that you can run them and see if you broke something. You might break something because you just found out that what you've been doing is wrong, and you need to rewrite it. If you've got good tests, you can refactor your code mercilessly, and yet you will know every last thing you have to fix, and the precise moment when you are done, because your tests tell you what still isn't working, and what is.