How to Start Coding for a Project

Posted on November 18, 2011 by Alfredo Scaini

People have different views on how to start going about coding for a project. Some jump in right away, while others want to plan everything out first. For the most part, I’m in the latter camp, and below is what I typically do.

Figure out What Needs to be Done

First thing to do before starting a project is to figure out what the FULL requirements are and when things are due. Why did I use all-caps for the word full? Because there will always be instances where you’re not told everything; not because client’s are evil, but because they haven’t thought the entire process out.

Take the time to gather all the requirements and ask, “is there anything else that you need this application to do?” When they say, “no” then you need to do the following:

Step 1: Group the Requirements Up into Modules

Requirements can generally be grouped into modules. By grouping requirements together you can start to get a sense of what you’ll be building.

For example. The following requirements state that:

• “Users must have access to A and B”
• “Certain users will have access to C”

Looking at these two requirements you realize that you will need to group them into a user module with roles-based privileges. This is the first step. The next step is to figure out what the client didn’t ask for because they may not have thought of it.

Step 2: Revisit the Requirements Gathering Process

When you’re grouping requirements together it will dawn on you that you’re building something that may involve more than what the client initially asked for. When you start to see this you need to do the following:

1. Perform an assessment on the extra functionality
   Determine the risks/benefits of building it in; and the risks/benefits of not building it in. Give each piece of new functionality a low, medium, high risk/benefit rating and provide an explanation for the rating.

2. Inform the client or your Project Manager (PM)
   Don’t just start building it in out of the goodness of your heart. Explain the situation first to your client or the PM in charge of the project. Your PM may be able to charge for this extra functionality; or, the client may not have wanted it which was why it wasn’t in the requirements.

   If the decision is to not include it (even if you feel it should be), at least you’ve provided an explanation as to why it was important and the risks of not having it. This is important because it gives people a sense that you’re on the ball and not just a drone programmer.

Step 3: Look at What Needs to be Built vs Timelines

Now that you have a sense of how things look to be falling into place, take a look at the timelines – if any were provided – and provide your PM or client with an idea of if those timelines are reasonable for what is required.

Pad your estimates to allow for some buffer – there may be unknowns that you haven’t thought of when you were figuring things out. Don’t go crazy with the padding though. No one is going to agree to pay for three weeks work when something is only going to take you three days. Be honest and realistic in your assessment. If you’re not sure, then provide a date range.

Don’t be fooled thinking clients’ will be thrilled if you only needed 4 days instead of the 15 estimated. They’ll be happy that they didn’t have to pay for 15, but concerned as to why your estimate was so wrong.

Side Note: The benefit of the buffer is to not only give you room to manoeuvre, but if you don’t need it, to also deliver a project under budget and ahead of the estimated schedule.

Step 4: Build the Wireframes, Broken up by Modules

Don’t skip this step. Now that you have an idea of the different modules that the system will need, you need to string them together into a coherent whole which flows well.

The benefit of wireframes is two-fold: one – you can put your ideas onto something tangible so that you can catch things you may not have thought of; and two – you can show the client something real and not hope that they can mind-read your ideas.

The best way for you and the client to ensure that you are both on the same level in terms of understanding what will be built lies with wireframes. It really doesn’t matter what medium you use – Visio, HTML, paper, Power Point – you just need to ensure that the client understands the process and what they’ll be getting. Be sure to break it up into sections so that it’s easy to digest.

But What if Timelines Are Tight?

This has happened to me where timelines were so tight that wireframes were not built. While some exceptional people may be able to pull off accurate applications by just “winging it”, most of us (including myself) can’t. Don’t skimp on wireframes and the planning phase in general – you will get burned later on.

Figure Out the Database

The next step is to start designing the database schema. Make sure that you organize the tables and fields in each table in a way that minimizes redundancy while at the same time maximizes efficiency.

Wow, there’s a sound bite for you.

When I say, “minimize redundancy” I mean make sure that you don’t have the same data in different tables. If you do, consider building a separate table to house this common data and pull it in via foreign keys.

At the same time though, consider efficiency. If you have a widget table and a separate sales table, and the system must always display the total number of sales per widget, it makes more sense to have a “number_of_sales” field in the widgets table that gets updated every time a new sale is made.

Thinking that you can just do this via SQL joins is dangerous because there could be millions of sales … per widget. This will slow your system down. Efficiency in this case takes precedence over minimizing redundancy.

Proceed with Building Your Objects

If you’re not using Object Oriented Programming (OOP) for medium and large projects (and in some cases smaller projects), I will pray for you. OOP is so effective in terms of saving time, reuse of code and understanding how things work from a macro scale that I can’t sing its praises enough.

OOP allows you to transform the contents your database into something that can be understood more easily by not just you, but also future developers that will be working on your code. By grouping related data into objects you create a story of characters each with their own special characteristics and different ways that they can interact with other characters. Wow … it’s like role-playing.

Continue with Building the Interactions Between Objects

Figure out how each of your objects relate to other objects. If you have an Employee and Employer class look at how you can re-jig is so that you can create a parent class called Person and have both the Empoyer and Employee class inherit from it.

This is a great way to reduce redundancy in your code which will help you when you have to add or remove common elements.

Start Coding!

Now that you have the requirements, the database structure and the objects that the system will need, you can start actually coding in all the business logic and fulfilling the requirements (remember these?). Remember to use the wireframe as a base of your build. Break your work up into modules and focus on one before moving to the other.

Don’t forget to keep your PM or client informed of your progress and to let them know if you’ve hit a snag that will affect timelines.

Happy coding!