views:

451

answers:

5

Hi guys! I'm looking to start working on a web application and I'm almost done with the functional specification:

Where do I go now?

  • Do I begin work on creating the html and css?
  • Do I begin creating the backend body of code? (setting up serverside email validation and database data-entry functions)
  • Do I begin working on the client side scripting? (javascript/jquery)
  • Do I begin working on the database structure?

Is there a best-practice order to these things?

Thanks!

+4  A: 

Okay, you've created a great spec. Now it's time to expand that "description" into functional user interface mockups.

Why?

A spec says what an app "should" do. It can even be very detailed about it. But complete user interfaces say exactly what an app "really does". After all, do users really care what is under the hood?

In our experience, we find that projects that have the user interface designed and refined (valid html for example) BEFORE the functionality is applied go together several times faster and more efficient than the others.

  • A spec can only contain a small percentage of the actual details that you run into when implementing an application.
  • A functional User Interface can cover nearly all of the actual details that you run into when implementaing an application, at a fraction of the time of actually making it work.

Once the client/stakeholder is pleased with the UI, then it is a quick route to plugging in the functionality.

And a functional UI is not a small job. Maybe even 20-40% of the work could be spend doing that.

--

All that being said, don't waste time making everything pretty -- just focus on highly usable interfaces. A graphics person can come by later and make it pretty while you are busy making it work.

gahooa
+1 for focusing on the UI through mockups/storyboards with the stakeholder to ensure that the application you create clearly provides the benefit to the end user.
arrocharGeek
A: 

Two of the more popular choices are Domain Driven Development and Test Driven Development. Loosely speaking...

In Domain Driven Development you would start by mapping out the logical organization of the development endeavor into a model that can be used to program against.

In Test Driven Development you would start by writing unit tests that align to specific use cases. You then incrementally add functionality as use cases overlap, eventually satisfying all requirements. TDD enthusiasts like this approach because their mentality is to only code what is necessary to accomplish the current goal and you will ultimately have a better code base.

Hopefully this gives you two different paths to look at, good luck.

blu
+3  A: 

The answer is It Depends.

It Depends on whether or not you need your customer to sign off on the look and feel before you start working; it depends on whether or not mockups were part of that look and feel. It depends on how soon you need to get a prototype in front of your client to test.

No matter what you start working on, It Depends on what your specific situation.

If you're a proponent of Domain Driven Design, then you'd have a specific starting point. If you're a proponent of Test Driven Development, then you also have a specific starting point. In fact, no matter your software religion, you probably have a starting point.

Here's my answer: Start where you can get the most bang for your buck. If it's data heavy, I start there, as everything depends on that.

George Stocker
+1 for customer look and feel approval
blu
A: 

Hi,

If you worry about presentation layer (html, css, javascript, MVC frameworks), you can left other more importants concerns away. Once you model your use cases, you SHOULD WRITE TESTS that pass it. Then you model your database structure to adapt to your model - you could use a ORM framework at this step. By the end, you desing your presentation layer.

Regards,

Arthur Ronald F D Garcia (Java programmer)

Natal/RN (Brazil)

Arthur Ronald F D Garcia
+2  A: 

The answer is: all of the above. (e.g. HTML/CSS, server-side, database, client-side scripting, etc.)

However, only the smallest possible amount of each of those required to get the simplest single feature actually working.

Based on your question, it appears you've never done a web application before. That's OK, and your question is a good one, as I recall finding my first web app quite daunting.

To get started using this best practice I recommend short/tight iterations, where each iteration yields finished working code.

Here's a simple description of this process, per my experience:

  • Stop working on your functional spec - set it aside, and keep it - it is important work.
  • Choose 1 feature...make it the absolute simplest feature in your spec as it is right now.
    • my guess would be: to display the simplest possible version of your home page
  • Start working on everything it takes to make your super-simple homepage really work.
  • To make this 1 page work, you are going to have to learn a little about every part of your stack - except perhaps the database, that's OK, you can take that on in a later iteration.
  • Choose the tools in your stack...
    • development machine/environment (e.g. linux/apache/php, or windows/iis,asp.net, etc.)
    • if you don't know your stack, ask your friends or colleagues to recommend one.
    • find a tutorial on development language (php, asp.net, javascript/jquery) - there are plenty of tutorials online - just google for them
  • Following the tutorials and/or asking specific questions on SO and/or SF, get your tools/platform installed, and get a tutorial example to work.
  • Once you have confidence, start clean, and develop your super simple homepage.
  • Now...return to your functional spec, and choose the next simplest feature - perhaps one that involves the database.
  • Repeat the steps above, selecting your tools and learning how to use them with a tutorial, then move on to implementing your actual simple feature.
  • After you've done a few simple features, let's say 3 for example, review your functional spec and see if it needs updating based on what you've learned doing the first 3 features.
  • Review your code from your first 3 features, did you learn anything since you began? Is there perhaps any reason to refactor or clean up? If so, do 1 pass at clean up/refactoring.
  • Once you're happy with your 3 simple features, go back to your spec and choose another feature and/or add more sophistication to an existing feature.

Each cycle described above is an iteration, keep them short and always finish with working code that you could potentially ship, if your app required only that small feature.

I didn't invent the process above, it's called Scrum. Although you don't really need to know anything more than what I have described above to get started, you can read more about it (in your spare time, or perhaps not until you've completed 5 simple features) here:

wikipedia entry on scrum

Note that each iteration will likely require you to learn a little bit and create a little bit of each of the component parts you describe above: HTML/CSS, server-side code, database, etc.

Thus, what you will do "first" is implement the simplest possible feature, using the least amount of coding required to get that feature working.

Good luck.

arrocharGeek