Archive for July, 2012

Project creation, specification, and sizing

Wednesday, July 18th, 2012

There are couple things that every single developer needs to know in a project:

1. How it looks
2. How it functions

To figure out how to code something, I generally one, talk to the “client” and figure out what they want. In this process it’s very important to figure out what the client wants it to do. This is where we gather a feature list.

Then, we map out these features, figuring out what actions are necessary for users to get to the desired page. Mapping out which sections users click on, where they’re placed, and etc. This will generate a wire frame. It’s also at this stage that you break down each overall functionality of the site into the various relevant sections. The output of this stage should be one: a diagram with very generic depictions of interfaces, resulting pages from user actions, and a list of functionality and more specifically the logic for the functionality.

The wire frame will enable both the designer, and developer to work in parallel, since they both have a basic idea of how everything will flow. Hopefully, by this stage, you have a good grasp of the functionality.

The designer takes the wire frame, logic, and specifications, and generates a mock.

Development

There are 3 classification of development:
1. HTML/CSS
2. Frontend
3. Backend

1. HTML and CSS controls the way it looks.
2. Frontend development generally involve the javascript, and various controllers
3. Backend development will involve the database, business logic and etc.

Of course, this can all fall under the broad umbrella of development, but the main reason why I broke it down is due to the fact that the work can be broken down, so that multiple hands can work on it at once. That being said, the more hands on deck, the more overhead is generally involved.

So we’ve covered how to create a project, and how to specify the project. With the specifications listed, now it’s possible to come up with accurate estimates, or size the project. Everything can be estimated and delivered. The person who dreamed up the project is responsible for listing out the ideas and how it’s going to work. Together with a UI person, he can then work out and deliver the wire frames. Then the business person, and the designer can get together and design out how all the pages will look, delivering the mocks. Finally when the mocks are delivered, they can be handed off to the developers, and the developers will be able to code everything. The better a job the business person does at being specific, the less likely he’ll be pestered by developers to clarify the business logic. Essentially, having the project broken down into these sections will allow the estimates to be much more accurate. The more complex the business logic, the more complex the code, and most likely, the more man hours it’ll take to code it.