Monday, June 7, 2010

Before Beginning a Project

It has been a year since I wrote my first blog here. In this long period I was working on 2 software projects and I am almost near the final functional release of my first one. There is still some more work to be done but they are all what we call the final touches including minor bug fixes and performance improvements, enhancements based on wishlist that we kept on pending etc.

Straight to the point: Now a days many of the projects are carried out in a short time span, so what are some of the important steps that need to be put in place before beginning development of a software project.

  • Technically Foolproof Statement of Work (SOW)
  • Not many gets a chance to influence the SOW of projects that they work on. I strongly believe that any one who is going to play the architect role should be given a chance to review the SOW before its signed off if non-functional aspects like scalability and availability etc are detailed in the SOW documents. Some SOW writers go into extreme level in non-functional aspects like 99.9999 percent availability, infinite horizontal scalability, 100% test coverage etc with a motive of getting the project by sitting in fictional world. These are the statements which sets wrong expectation to any customer without giving them the entire details about the effort and cost to achieve the same. How to write a foolproof statement of work will need another blog of its entirety but I wanted to scribble some interesting thoughts I have on SOWs that may fail the project before it starts.

  • Proper Requirement Analysis:
  • I have seen organizations multi-tasking the resources for various type of day to day works in software industry. This has its pros/cons. Some times moving a core engineering team member into level 2 support or application testing team for some time helps the developer to understand the necessities of his counterparts and adapt his working style to contribute to the team better, but instead if developers are dragged into the requirement capturing phase we might end up in getting semi cooked design documents instead of requirement specifications. Instead of understanding the breadth and depth of requirements, the developer always tend to concentrate more on the technical challenges in achieving the same and misses out the important point of capturing the thoughts from the business team. So its important that organizations should not multi-task resources to this extreme and instead employ the right experienced resources at the time of requirement capturing.

  • Setting Up a Source Code Repository (SCR):

  • This is the place where we keep all the essential files required to build a product. It plays an important role in the software development life cycle and the significance is very high in recent projects where we have Continous Integration (CI) in place. SCR like Subversion enable the development team to work collaboratively and simultaneously on the code / document artifacts. These tools provide this concurrent collaboration feature with the help of powerful version control mechanism and conflict resolution inbuilt.

  • Defining the Standards:
  • However strong and experienced the team we build we should not forget that the team is a set of people with diversified thoughts and its necessary to ensure that all these thoughts are stream lined to achieve the success of a project as a team. Defining standards at all levels as much as possible ensure that this is achieved. Defining the set of tools that project should use, the development environment for all the different kinds of developers etc should be defined and documented upfront. Though I would say an architect will need to refine these things on the course of the project by receiving feedback from his team.

    General Developer Guidelines: This should be the first place of reference for any developer for any project specific documentation. In some situations this document may also act as the index for the other sub-documents.
    Coding Standards & Guidelines:

    Checklist: Code review checklists,

  • Setting up Continous Integration (CI):
  • “Continuous integration is a software development practice where members of a team integrate their work frequently—usually each person integrates at least daily—leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”—Martin Fowler

    There are so many servers supporting continous integration now and most of them are open source. I have used two of them Cruise Control and Hudson and found it exremely easy to set up and very helpful in the whole duration of projects.
    Regardless of what CI server you use, the CI server obtains the latest source code from SCR, locates all required dependencies, and builds the product independently from the previous build output.
    Well none of these CI servers will write the build scripts for us. So we need to ensure that we have a solid build system. (For eg: based on maven or ivy for a JEE project). Its very important that this is setup very early, atleast before the developers are kicked into the project.

  • Setting Up Bug Tracking System:
  • JIRA or bugzilla

  • Building an application framework

  • Maintaining a talent pool:
  • After working for some startups and consulting firms I find a talent pool playing a significant role in the success of any company. Maintaining a talent pool is going to be one of the major factors in the success of any organization. We save the time for team building. Having a nice team environment is not an easy one to achieve from the day one. Yes it takes time and effort. Apart from that the developers are already proven in the organization and hence you can guarantee that unhealthy competitions are avoided. Also when we have the organizational wide frameworks in place these developers will be well versed with the usage of the same.