Slashdot Mirror

Step aside Waterfall, move over Extreme Programming, there is now a software development process that is popular as it is effective. Yes, Avalanche Development Process will be sure to bring your project to a conclusion quickly and effectively. Read on to learn about this new and upcoming development methodology.

The Avalanche software development process occurs though several stages. In some ways this is similar to Waterfall, but more aggressive. Instead of a calming waterfall we want a Avalanche of productivity. Lets look at how it works.

Project Initiation Phase

In the initiation phase of a project your role as project manager is to secure the largest budget possible. Executive management will however be aiming to reduce your budget to the maximum extent possible, In fact if senior executives had their way you would probably be lucky to get some four by twos to make your own abacus.

It is therefore necessary to be creative in your justifications for the huge budgets you will require. First you must exaggerate almost beyond credibility the benefits to the business of the project. One way to establish the benefit to the business is to perform a Return On Investment Analysis, or ROI. Some project managers spend significant effort doing research and analysis for a ROI. The Avalanche Process has streamlined this process by skipping the analysis and going directly to the conclusion.

You can safely add your unsupported ROI conclusions in the form of an 'executive summary' to random pages from previous projects. No executive ever reads the detail of an ROI primarily because they already know you are a lying weasel. The senior management will then approve your project expecting open ended functionality with half the budget and half the projected schedule described in your project proposal. They do this knowing you have already accounted for this when you wrote the proposal.

Click For More

I have been through this before - with a different language, but the same principles apply. Here is some adivce, and some ideas:

1. Don't do a 'big bang' rewrite. A Big Bang rewrite is one where you totally rewrite all the code, but have no functional - or very little functional difference.

2. Do refactor or rework small portions of the code. Work on the code as you implement new functionality that the system needs. In other words don't waste time on rewriting working code unless it needs additional features or is broken.

3. Do Introduce Unit Tests and Acceptance Tests. This means you will know quickly when changes you make break code. Don't do a massive "unit test" building exercise however. Write a Unit Test for every peice of new code you do, and every peice of code that needs fixing.

4. Identify "Problem Code". Problem code is the bits which seem to take up most of the maintenance time. Identify that code, and try to work out ways to fix it.

Note : Some people think they are 'clever' by writing complex code which is hard to understand, but may perform better etc. This is the kind of code which usually ends up being a problem. As a professional programmer I try to be clear to understand - not only for the benefit of others, but for my benefit when trying to maintain it.

5. Read about how to manage projects. Extreme Programming is popular now, and I can say that it has some very good ideas. However don't become religious about it, and take a look at some of the 'classics'. I can recommend:

- The Mythical Man Month (tad dated, but a classic).
- Code Complete (also a little dated, but still good advice)
- Extreme Programming Explained

To take a look at my Open Source Resource, which has many articles around the subject of project management, take a look at:

Devcentre

The point of XP is that it is iterative, which means that you specifically don't expect your customer to provide complete or correct requirements.

By iterating through a quick iterations, much like Open Source, the application is evolved rather designed. Of course there is micro design within each iteration where developers plan how they will achieve the functionality required, but there is no longer a detailed static plan of the whole system, because we have found that such large detailed plans become outdated and corrupted over time as developers change the plan to meet the customer requirements.

XP accepts that we are unable in the quick paced business world to do long term (over one year) projects on monolithic applications that do not evolve with the needs of customers, and provides a means of programming in a flexible manner that does not comprimise quality or productivity.

For a resource on this and other related topics, take a look at here

XP is related to Open Source methodology, in that they both make use of evolutionary methods rather than design methods.

See my article on evolutionary programming here.

With both XP and OS development there are processes which act as 'mutation' and 'selection' factors that act on source code. Programmers provide 'mutation' - or new code, while the users select which versions end up actually being used.

I should point out that I am not saying that 'micro' planning does not occur by developers - just that there isn't a single Big Plan(tm) from the start like there is with a more traditional approach.

My current Open Source project is working on a few Interesting things. I intend to provide a EMail Client which handles business documents such as invoices, orders and so on.

DevCentre.Org

It will handle normal email as well, but the primary importance of the client will be that it automatically handles key exchange through key servers. Just send a message to someone and the client will look up the key servers to check if they have a public key. This means a no mess way of secure comms.

The point is that I'm not going to push encryption for encryptions sake. The idea is to push a client that can send and receive standard business documents. The client will have the ability to plug in accounting system drivers to import and export to your favorite accounting system.

The idea is to get people using the software because of the ability to send and receive business documents, not because the client encrypts/decrypts.