Speeding up web development
I personally have found breaking everything up into small tasks helps.
The way I like to design web pages:
- Draw out the design, or photoshop it.
- Create the HTML - no CSS, no styling at all
- Now add in your style - basic style, like positioning, save making the menu perfect for later
- Connect to database if needed / server side code
- Now add in any javascript, ajax needed
- Tweak it to perfection
If you have all this broken into small tasks, when you get done with each, you feel more motivated to continue working.
Like I said, this is how I do it, and it seems to go quickly, especially since I only get about 1 to 2 hours a night to work.
The answer to this question depends on if you are working alone or leading a group.
If you are leading a group you will want to break apart responsibilities as the following:
Designers - These people should own the creation of graphical mockups and the creation/maintenance of CSS. They should own CSS as a responsibility so that they know not to create outrageous graphical mockups that cannot be created as a webpage without considerable code bloat.
Markup - These people should own the authoring of HTML, accessibility, semantics, RDFa requirements, and any other aspect associated with front end data structure.
UIT - These people should own JavaScript, efficiency requirements, content-management requirements, internal process and front-end tool/process governance, and generally own best practices for all client visible code.
Applications - These people should own server-side application code development, content management system creation/maintenance, and database access requirements. These people are application and services programmers and provide the interface to database and services personnel.
QA - These people test all business requirements of the final product in a certification environment. If errors are seen the bug/ticket should be updated and reassigned. The work is not finished until QA signs off as valid.
Business Owner - The business owner is the person/team responsible for writing the initial project requirements and making a final approving decision about the deployment of the project. This person should have no interface to the technology process outside the drafting of business requirements.
Project Manager - This person ensures that a project is continually moving forward and that milestones are completed in accordance with any deadlines. It is this person and not the business owner that is to interfere with the technology process to ensure things are getting done. This person must act independently of the business owner and must not serve as a tool to the business. The project manager must not own or recommend changes to the requirements to the technology personnel. If changes to the requirements must be made this is a one way process from technology through the project manager to the business owner.
The flow of development should be the following:
1) Designers create the graphic mockup and then reassign the bug/project ticket to the project business owner.
2) Upon business approval the ticket should be reassigned to Markup staff or rejected back to design with specific change requests.
3) Markup writes the HTML and content. Any application or database requirements should be specified by business before the project begins and the Markup team should write code for all possible scenarios. The structure of content should reflect the organization of content on the visual markup completely without regard for presentation. The ticket should be reassigned back to Design for CSS creation.
4) Design writes the CSS to add presentation in compliance with the graphical mockup they created. The design team must have access to the HTML markup to add class attributes as necessary, but should not be allowed to make any other changes. The ticket should be reassigned to Applications to complete all server side requirements.
5) Applications should create all necessary requirements for database access. Ticket should be reassigned to UIT if the prior requirements are satisfactory or reassigned back to Markup for changes/additions.
6) UIT should be the final step to write the JavaScript interactions necessary for user-interface and AJAX requirements. UIT also should proof the prior completed markup for standards conformance, efficiency, and best practices. UIT should quickly reject the project if the work is less the acceptable. If additional Applications work is required reassign to Applications otherwise reassign ticket to QA.
7) QA is the final technology stop. These people test the business and functional requirements of the final product. The project cannot be released to production without QA sign off. If a business requirement fails QA must not sign off. Upon QA sign off the ticket should be reassigned to the business owner.
8) The business owner reviews the project and determines if all requirements are achieved. If changes/additions are required they can be submitted at this time. Changes/additions MUST NOT be submitted earlier, because frequent changes delays all projects. It is the responsibility of the business owner to ensure their initial requirements are complete and specific. If the requirements are not reviewed for fullness it is the fault of the business owner and changes can be submitted at this point. It is because of this responsibility, and other associated business responsibilities, that the business owner deserves to get paid more for being less involved.
That is the most efficient manner to get the job done. Separation of duties is extremely important and adherence to the process is extremely important. If those two things fail the entire process fails and business incurs significantly increased development costs.
If you are acting on your own and not part of a team I would still follow a similar process and push the role business owner onto the client. If the client wants to make changes/additions premature to the project completion then they can pay more money by amending a change addendum to the original requirements contract. You do not loose pay from increased labor because a client cannot make up their damn mind. If that is upsetting then the client can pay even more money for a contract cancellation. This is not mean it is business. If your time is not a valued commodity then you should not be in business as on your own.
I've been using the .NET stack for about 5 years, the ASP.NET MVC stack for about 3 months, and old ASP for 4 about years.
The key to dealing with complexity is mitigating it. In your code, always abstract away complexity to a reasonable level. For example, say there are 10 steps to placing an order. In that case, at a higher level, you would have a method 'SubmitOrder'; under it might be 10 method calls for inserting appropriate records, dealing with inventory and so on. In each of those 'business' layers, you can just deal with these business problem, and even below those layers, you would deal with data and mechanical details. The benefit to all of these layers is that you make each layer deal with a chunk of the work, and as you go up closer to the UI, you have an 'interface' that makes sense to the UI and the way the application needs to flow.