Best way to start off a new project?

[eluser]vmirjamali[/eluser]
Just wondering is there a simple method anyone follows when starting a new coding project?

Like for instance do you set up the views, models, controllers, templates, etc in a certain way?

Also just wondering does anyone create template systems seperate from the view system? I used just the view system for my old projects, but i heard I should create templates?

Thanks for any help creating a new project soon and would love to know.

[eluser]Udi[/eluser]
I wrote 2 blog posts that can help you with it.
Developing CMS With CodeIgniter - Part 1
Developing CMS With CodeIgniter - Part 2

I'm working on the next part,
In these 2 posts you can see how I structure my files [by modules], how I extend CI_Controller and CI_Model...

All of this info can help you understand how to begin.

[eluser]BrianDHall[/eluser]
As a general guideline I've found the best way for me is to first create a 'fake' application - a front-end that looks like the end product should look, at least with some degree of reason. Front-end first, in other words.

I've tried it the other way and it felt very frustrating. As much as Views are suppose to separate content from logic, I found that unavoidably certain front-end designs demanded changes in the code. I find it vastly easier to refactor a design than refactor or even re-write code, so I like decisions like "how the shopping cart looks" and "what the checkout flow should be" to be made before I actually have to code the logic for them.

My thinking is that you can't usability test or get meaningful customer/boss approval from backend code if they aren't coders themselves. So you end up 90% done with a project with no real way to find out how happy the customer is going to be. You might get down to the final details and its figured out "Oh, this checkout project takes too many steps, maybe it should be more like..." and now you just earned yourself an almost total rewrite of a half-dozen functions and refactoring of multiple views and controllers, or you try to hack out a solution that turns things into a big ugly mess.

I suppose most programmers just want to jump in and code, after all if you are a programmer you probably aren't a designer at heart, but I found that after the initial pleasure of setting up and starting a project fades the pain of wasted effort and rework makes it Soooo not worth it in the end.

So I find it best, so far, to go:

Discuss/think about what's wanted -> draw (pencil or on computer) paper prototype -> get a front-end design going, if not largely complete -> build 'fake' application, or "simulated prototype" (so you can click Login and it logs you in, for instance, but in reality it doesn't matter what you entered in the text boxes, etc) -> revise and rework -> once satisfactorily completely and most hidden issues uncovered, proceed with beginning of actual code and database design.

[eluser]n0xie[/eluser]

Just wondering is there a simple method anyone follows when starting a new coding project?

If it's a hobby project, just start somewhere. Build the basics first. So if you want to build a blog, make sure you can make new posts. Then make sure you can edit it. Then maybe add comments or categories or tags or whatever you think is important for your blog. The point is to work in iterations: make something work, then make it pretty. Then refactor to make it elegant.

[quote author="BrianDHall" date="1262081874"]As a general guideline I've found the best way for me is to first create a 'fake' application - a front-end that looks like the end product should look, at least with some degree of reason. Front-end first, in other words.[/quote]
If you do work for a client, I disagree.

The front-end or the part of the website that users/visitors interact with, is usually just a representation of data. How the data looks is irrelevant: it might be relevant to the client and your users/visitors, but for you, as a programmer, it's 'just a view'. So your first job, as you envision your project, is to map how your data flows through your application. Most websites are nothing more than pimped up database front-ends: data goes in, some computation happens, data goes out.

So what you need to do is get your data organised. Know how a RDBMS works. Draw out how you store the data, what the relationship will be with other data, and if possible, try to avoid duplicating data.

Once you have this in place build the code around it so you can access and manipulate the data. If you stick to some conventions you can auto generate this or use some ORM implementation to save you a lot of time.

After that you're pretty much done. Throw a design in front of it and that's it. Yes I know this is the part of the project that takes the most time, but the essence is that once you have your logic in place, the code you write should only be to build up some view and add some 'logic' to it.

They change the design? No problem. As long as the same business logic, business rules still apply, there shouldn't be a need to change any underlying code. You might have to write another function in your controller, add some exception here or there, and maybe add a custom function in your model with some special parameters, but it will most likely have minimal to no impact on your database structure, and thus the basis of your application. Note that all we do is add code to take care of exceptions/specific wishes: we are not changing any of the fundamental CRUD operations we already have in place.

I have learned that it is much easier to add a function here and there to do a specific task than to edit some logic in your database forcing you to rewrite half your application because the relationships changed.

Now if your client changes the business rules/business logic 80% in the project you do have a problem. This is were you should have your contracts and agreements in place to shield you from this. If you hire a painter to paint your house, you don't expect him to redo everything if he is 80% done, just because you decide that 'pink' would look rather dashing instead of the white you chose before.

[eluser]BrianDHall[/eluser]
[quote author="n0xie" date="1262109120"]
Now if your client changes the business rules/business logic 80% in the project you do have a problem. This is were you should have your contracts and agreements in place to shield you from this. If you hire a painter to paint your house, you don't expect him to redo everything if he is 80% done, just because you decide that 'pink' would look rather dashing instead of the white you chose before.[/quote]

This is actually where I get hit, because my big projects are not on contract, they are as a member of staff. Perhaps my advice is terrible in any other situation, but I find that the reason is precisely the logic and the relationship of data.

As an example on my last project, the system was planned and drawn up and written out to be Create Listing -> Enter Info -> Add Pictures -> Confirm/Purchase. Easy.

It ended up being Create Listing -> Create Account -> Enter Info -> Add Pictures -> Preview/Select options -> Add to Cart -> Purchase, and then a Purchase could be Active, or Paused or Stopped for various reasons, and then it became Active or Stopped, and then it just became Balance > 0 or Balance <= 0. Listings could be stopped early with partial refund...but not in actual money, just account credit.

Then came in the issue that if someone adjusted a listing's options, it might cost more and cause an account issue with other projects, so Listings needed to have their own cash balance and then there would be account credits, and it all had to be itemizable in credit card receipts we didn't control the generation of for various accounting requirements of large companies.


So I guess the problem is my job isn't to build a site, but rather to build something and then develop it through initial launch.

All these changes weren't the result of bad planning, but rather to discoveries once things could be showed to potential customers, clients, business partners, and once the owner could sit down and work through the application "pretending" to be a potential customer, plus various people's family members.

Much of that could have been done without writing nearly any business logic or even drawing up a database schema diagram.

So maybe it's just my early contact with the initial raw idea, as my job usually begins with an idea a few people have done enough fleshing out of to start paying me, but that's it.

So I guess my perspective is that while my job really is to code logic and design information flow and all these really cool engineering things that not just anyone can even understand much less do...the problem is trying to build It when what It is changes every time a new perspective is received.

The thing is, I don't really mind this, it's really just a part of the "Planning" stage I suppose before a project is really even officially started, but the problem is that I dislike building a perfectly good program only to have to rip it all up because the specifications changed. Then I'm stuck with systems I spent weeks on that were not designed for the purpose I now have for them, and I neither want to start over nor does it feel like it would take less time - but then the pains of retrofitting. Rework just isn't much fun.

It's one thing if a feature was just added, but when it breaks prior assumptions as to how data should be structured...ugh.

So my working theory is to do any work FIRST that would be the most likely to cause people to change their minds. So create a fake checkout system, and see what they say - not enough options, they feel? They want to accept offline payments now? Too many options, too many steps?

With this work done I find that a much clearer picture of the final desired app is created, and then with the What It Is clearly in mind I can do the real work - making It happen.

[eluser]Ollie Rattue[/eluser]
Hi there,

I wrote a blog post the other day about some of the technical things I do when kicking off a new project - http://toomanytabs.com/blog/145/my-web-a...practices/

As for the actual process it tends to vary depending on the project and whether it is client work or a side project.

Client work:

1. Getting real data into the sytem - Where possible I like to work with real data. So if there is a admin backend for the client, I will get this up and running first on a live box, so that the client can populating the website. An example is a restaurant review website I recently built, where the client was responsible for adding the reviews. I could of created some test data, but test data is not REAL. It isn't the data the actual website will use, and so you usually end up overlooking problems, that real data reveals. I built and handed over the admin backend to the client, and whilst they added the reviews, I built the frontent with the real data populating as I went.

2. Agile explorative frontend led development - If neither party knows what the final product will look like and how it will function, the priority is to get something up and running that is usable. It won't be finished, it won't have a nice design, but it will have forms that work, links that link, simple copy. Both sides can look at what is being developed and spot potential problems early on. This tends to lead to an organic style of growth, and often the design emerges as you go along. When a designer can see all the elements on a page, they can produce a great design. If they don't know what is going to be happening on a page their designs are just guesses. The method of designer creates a PSD and the developer makes it work, simple doesn't cut it when the specification and business requirements change so rapidly and cannnot be known at the start of a project.

If you haven't already done so I recommend reading the bible that is Getting Real by 37 Signals.

Side projects:

Often my side projects will be trying to solve a tricky problem. If it is a case of "I don't know whether this will actually work technically", I forget all of the parts that will make up the finished web app (logins, amnesia, signup, email systems etc), and focus solely on a 'proof of concept'. It is easy to start building the complete all singing dancing application, and leave the tricky stuff to the end. But this is really just burying your head in the sand. You can waste a lot of time and in the worse case scenario the project may have to be abandoned.

[eluser]CI2RULZ[/eluser]
everyone is different I suppose. for me I usually build the entire front end design, every page, all doohickeys and gadgity-rific items first... then once everyone who cares is happy about it... get all backend on its colorful arse. lol

Doesn't matter what setting I work in, I find this just works the best for me. I know the layout of where everything static will be, and everything dynamic. I know how it will work and function and why... public, private, admin, or otherwise, so adding the code necessary to make that happen is then easy... it's like paint by numbers (without the paint, or numbers, or brush .... ok... it's just coding damn it). So fellow tortured above, I'm in total concurrence with you. Sometimes I will break out the code as I go with the design, and ultimately it's just a sad sight to see someone crying on their keyboard. Revisions, revisions, revisions. I don't care how well you plan it, how long the doc was you got about the project, how many trees were killed for diagram flow charts, the client will change their mind... it never fails.

There is no right way or wrong way, just jump in and figure out what works for you, your clients, the environment, "the man", or whoever you do this for.

[eluser]John Pantoja[/eluser]
Ah the power of searching!! Just a topic I was looking for.

This is something I've never been consistent on unfortunately and I'm looking to resolve. The last few months I had the other guys on the team just turn around and say "Hey I need a web service" or "you got any code that does this.." so I've gotten use to machines as customers.

I'm in the process of converting an app I wrote a few weeks back in CI, hence the learning.

This app was merely proof of concept and was actually designed as a web service to serve as a URL shortner (yes bit.ly or tinyurl) for SharePoint internal to our network. Since I have decided to open source the project (and my key generation algorithm, thanks Mike :coolgrin I figure I should convert it.

I feel better knowing other have them same issue. Bad thing for me now is I'm working out of the house.

Ollie Rattue, I think I've ran across Getting Real before, though I did not finish reading it, might have to now.