Hi,
I am fairly new to designing and implementing real world applications (other than the ones I did at university). I would like to know from the ones more experienced than me how does one go about designing and implementing an application? What are the first steps involved?I know that there are tons of information out there with regards to what sort of methodology and patterns to use but I want to know what works and what doesn't.
It depends;
and so on.
As you probably already know, the spectrum of methodologies is from classic waterfall to agile and xp. Not only can you choose a point on this spectrum but you can produce artifacts that suit your needs, maybe documenting the data model differently, communicating requirements statically or in wiki form.
So, it depends. One size doesn't fit all.
Many might start with code and paint themselves into a corner.
Many others start with a visio diagram and bore themselves to despair.
First and most important thing that you MUST co is to know what do you want to create. If you have client you must get it all from him which is not so easy.
Then if it's relatively small team I suggest Scrum (from Agile Programming family) as methodology. I used it in a porject with ca. 20 people and it worked. I used it for a project that I was only in and it helped me too. But above 40 people or with client that likes formal work it won't work.
To check out Scrum go to Wiki and move deeper.
Quoting Linus Torvalds:
"Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will say “hey, that almost works for me”, and they’ll get involved in the project."
Basically, don't try to make the finished app all in one go. Implement just one feature, and complete that. Then start another feature, and so forth. Otherwise, you'll never get there.
I'd also add, "keep it clean" - if at any stage your code gets a little messy, refactor it before adding any more features. Don't accumulate a large development debt.
This is going to be highly dependent on the type of app you are working on, but here's my very general "5 step process" I like to use:
Gather your requirements. You'll hardly ever be able to get them all up front, but do the best you can. This is the single most important part (IMO) of any project.
Put together a set of documents describing all the things a user will be able to do with the system as well as any "interal processes" (batch calculations, etc) performed by the system. These don't have to be terribly formal, but go into as much detail as you practically can. Present these to the customer to make sure it's really what they want. Revise as appropriate.
Go through your use cases and pick out the entities in them. These are the "Who's" and "Whats" of your app - e.g. "Employee", "Company", "Order", "Customer", etc. Determine the relationships between those things. This information will serve as the basis for your applications data model and business rules.
Start mocking up the user interface based on the use cases. Use whatever tools make sense. If you are on a team, this is often done at the same time as #4. Again, keep going back to the customer to make sure you are getting it right.
You now have a UI, a set of business rules, and a data model. From here on out it's basicly just detailed design, coding, testing and making adjustments -preferably in short iterations, taking one or two use cases at a time.
As for formal programming methodologies, I'd probably recommend Scrum/Agile for small teams and something like RUP for larger teams. But all that also depends on the project, the nature of the client, how well defined the requirements are, and a host of other factors.
The very first thing to do is to think about who is going to use it and for what purpose. Then start writing down what the application needs to do to fulfill the above. (functionality wise, not internal design) You can then start to design the application itself.
Surprisingly these things tend to be inspected last.
+1 to stusmith -- btw, it has a name, it's called 'agile' ;)
that said, he is exactly correct, a big application is a bunch of little applications tied together. design, write, test (test/write?) each of the little guys than put them together. you now have a big app. also, it doesn't hurt to read about XP and Agile (as well as TDD)
one more thing, be sure it eases some PAIN. that's the way it's useful.