Development Methodologies

Development Methodologies are known to draw strong opinions from developers and managers a like. Many things can come into play when making the decision as to what methodology your team should employ. Some of these decision factors include the core strategy of the company, skill level of the team developers, and central goal of the solution being developed.

1. Waterfall
The waterfall methodology has been around for a long time. It basically involves creating a detailed scope of work, getting the appropriate people to sign off on that scope of work, and then building the solution. The scope can not change and the product is finalized after the completion, unless an additional phase is recquisitioned.

I once worked at a web dev. shop that made its living with this methodology. Most of the projects were fixed price solutions for external customers who wanted to make sure they got their functionality for the guestimated price. The solutions were created in scheduled time frames and once a scope of work was defined and accepted by the client it was rarely changed. Any changes desired by the client would usually result in a phase II, III, or IV of the project.


2. Spiral
The spiral methodology involves taking a small amount of core requirements for a solution and going through the software development life cycle (SDLC) to implement those core requirements. The development team has every intention of going back through to implement additional requirements as they become apparent. This is currently the most used methodology because it allows for quick results, some agility in the requirements, and a team made up of developers at various skill levels. That being said, it is also prone to bugs and usually lacks up-to-date documentation.


3. Agile Development
The Agile Develoment methodology is the newest of the three methodologies discussed here. There are several variations of the methodology, but all share the following core concepts as stated in the Manifesto for Agile Software Development (http://www.agilemanifesto.org/)

- Individuals and iteractions over processes and tools
- Working software rather than comprehensive documentation
- customer collaboration over contract negotiations
- Responding to change over following a plan

This basically allows the development team to be self organized, have less emphasis on documentation (which is usually not kept up to date anyway), have direct access to customers (so that the projects get done exactly as the customer expects), and welcome changing requirements.

This can be a very good approach for teams consisting of self-starting, expert developers that are working on a select number of products for various internal and external customers. The methodology may not be the best for teams that require a large amount of documentation, have a business model that requires fixed prices, or have more junior to mid level developers than experts.

--------------------------------

I have worked at various companies which have put into practice each of these methodologies in some form or another. Each has its advantages and weaknesses and I have come to the conclusion that the best methodology is likely a mixture of three. My next blog will dive into one of the key features of the Waterfall method, the Scope Document.

The "bulletproof" deployment

Nothing can slow down a developer's rise up the corporate hierarchy faster than a botched up deployment that negatively affects customers, clients, and the internal staff.

Though it is impossible to dress your deployment in a vest that is 100% bulletproof, there are several things that can be done to ensure that the majority of your deployments will come out unscathed.

1. The first and most important thing that can be done to make the deployment go smoothly, is to bulletproof the code. One of the practices that has made this easier is called Test Driven Development (TDD). This technique involves writing your unit tests before writing the code and using those tests to ensure that the software functionality works as intended. A friend recently brought an article to my attention that shows how much of a impact this type of development can make on a project. The results show a staggering 50% reduction in bugs when using TDD. You can view the document at
http://maximilien.org/publications/papers/2003/Maximilien+Williams03.pdf.

2. Keep a list of any problems that come up during the actual deployments or in the application after the deployments. Use that list to perform last minute testing on future deployments for both the deployment environment and the software functionality. Try to put as many of these tests into automated functionality tests (Smoke Tests) as possible.

3. Keep a check list of activities that need to be performed to prepare for deployments. Some of these activities may include creating "release" builds, updating web references of dependant software solutions, and notifying any enterprise integration partners of the upcoming release.

4. Implement a code freeze with as much time as is needed to really pound on any areas of the application that have changes, as well as do an overview of all other functionality. Have as many people as possible beat on the system and document any issues that arise. Have one person in charge of determining what issues should be fixed for the release and what issues should be logged for a fix in a future release.

5. Finally, after the deployment is finished, have several people access the application and run through various high level tests, which hit the most used functionality.

Good night and happy deploying!