Monday, October 20, 2014

Before you code

A new project starts and everyone is excited. The development team is so keen to dig right in and start coding. But wait, there are few things that needs to be done at the start, to stop you from some head banging later in to the project.
Here are few that I’ve come across. Love to hear your suggestions.

  1. Servers and Developer machines
    1. Establish templates for your servers - You should be able to churn out a server with relevant software/hardware configuration in minutes during the life of your project.
    2. Make sure your developer machines have enough firepower - This may be an ideal time to get some funding for those upgrades that developers never got
    3. Development Server - In some instances, teams decide to have a common development server as an integration testing area. They may even end up working on a common database at the initial phases of the project. Although this could seem productive at the start, sooner you get off of this approach the better. This set up delays automation activities, gives false sense of velocity and could easily result in artificial delays in areas like migration.

  1. Environments
    1. A typical project can have separate environments for development/testing and productions. Each environment may consist of a combination of applications, configurations, databases etc...
    2. Team need to decide how many environments each of development and testing. Also how they wish to manage differences between each. Commissioning a new environment should again take only minutes.
    3. Another concern is how you connect your upstream and downstream applications to each of this environments. In most of the enterprise projects, data flows have to established both up and downstream from external systems in to your dev/test environments.

  1. Version Control
      1. Distributed or central. Distributed version control is more common place now and you got great and varied options. You can even rely on third party providers like github instead of setting up your own. Or may be you want to head down for a tool like TFS in light of its overall Application life cycle support.
      2. Establish your version control workflow
        1. Do you go for named branches or separate repositories?
        2. Is rebasing allowed?
        3. Tagging
        4. Logging the commits
      3. It's not just code. Version control should not limit to your code. Any artifact that makes your project what it is, needs to be version controlled. Your configurations, database, documents etc...I've found that some enterprise db developers are not very excited of using version control software. As a team you need to make sure that this is not the case and that database and configuration are treated as a first class citizen in the version control world.

  1. Knowledge Management
    1. The team should decide on a mechanism to share and build knowledge about the product/project.
    2. A preferred method is to have a project wiki. You can start dumping your initial thoughts and then easily keep updating it.
    3. If the project involves a lot of documents, a document management system might also be considered.
    4. The Wiki can be used to drive consistency across the team, be it standardization of terminology or standardization of technical entities.
      1. Common project specific terms, abbreviations and their meanings
      2. Technical standards and compliance details (data types, naming standards)
      3. Reference implementations and code samples
    5. It can also host project management information such as contact details, communication escalation paths, holiday plans and high level project plans and schedule information

  1. Project Management methodology and delivery expectations
    1. Team should decide what their delivery model is. For example, Is it going to be 2 week iterations or a continuous deployment of features in to an integration area as and when things roll out of developer hands.
    2. What sort of tool or method may be used to track the progress of the team.
    3. Seemingly simple things like consensus on  when a task will be marked 100% can go a long way in understanding the status of the project at any given moment.

I guess you do understand that none of the above should stop you from actually getting things done in the start. It’s not imperative that you have all of it before you open up your IDE. However in my experience the team should make it a point to get most of these concerns out of the way within the first couple of iterations.
Post a Comment