1.4. How Do I Get Started?
To get started designing and building your first large-scale web application, you'll need four things. First, you'll need an idea. This is typically the hardest thing to come up with and not traditionally the role of engineers;). While the techniques and technologies in this book can be applied to small projects, they are optimal for larger projects involving multiple developers and heavy usage. If you have an application that hasn't been launched or is small and needs scaling, then you've already done the hardest part and you can start designing for the large scale. If you already have a large-scale application, it's still a good idea to work your way through the book from front to back to check that you've covered your bases.
The most important thing you need is a method of discussing and recording the development process. Detailed spec documents can be tedious overkill, but not writing anything down can be similarly catastrophic. A good pad of paper can suffice for very small teams, or a good whiteboard (which you can then photograph to keep a persistent copy of your work). If you find you can't tear yourself away from a computer long enough to grasp a pen, a Wiki can fulfill a similar role. For larger teamsa Wiki is a good way to organize development specifications and notes, allowing all your developers to add and edit and allowing them to see the work of others.
While the classic waterfall development methodology can work well for monolithic and giant web applications, web application development often benefits from a fast iterative approach. As we develop an application design, we want to avoid taking any steps that pin us in a corner. Every decision we make should be quickly reversible if we find we took a wrong turnnew features can be designed technically at a very basic level, implemented, and then iterated upon before release (or even after release). Using lightweight tools such as a Wiki for ongoing documentation allows ourselves plenty of flexibilitywe don't need to spend six months developing a spec and then a year implementing it. We can develop a spec in a day and then implement it in a couple of days, leaving months to iterate and improve on it. The sooner we get working code to play with, the sooner we find out about any problems with our design and the less time we will have wasted if we need to take a different approach. The last point is fairly importantthe less time we spend on a single unit of functionality (which tends to mean our units are small and simple), the less invested we'll be in it and the easier it will be to throw away if need be. For a lot more information about development methodologies and techniques, pick up a copy of Steve McConnell's Rapid Development (Microsoft Press).
With pens and Wiki in hand, we can start to design our application architecture and then start implementing our world-changing application.