Methodologies for Change-Proof Development in Agile Environment

Question

Hi,

I am wondering whether there is any methodology to design the program logic which is agile-proof.

Currently for example I am developing an application for video recording and uploading. At the beginning it was planned just to enable the user to select the stored recordings from the library and edit title or upload the selected video. Then the program had to be modified to display the title dialog aoutomatically when the user stops recording. Now the program has to display the title dialog on record stop then it has to ask user if he wants to upload video and then the flow proceeds in accordance with user's selection.

There might be some better example to describe the problem of executing the program methods with different combination of condition states. The main question however is how to "keep the logic under control" during the development cycle.

It simple to make a complex design based upon predefined functionalities and then write the code from beginning to the end but I believe such cases are rare. Currently I write on paper all known scenarios, then run the debugger and make modifications in order to fix the logic and bugs. Unfortunatelly at some point when the complexity grows it becomes really painful to work this way. If there exists any methodology to simplify the development I would definitely like to learn about it so if you know any good book or just give any suggestion about the issue I would be very thankful!

Answer 1

I don't know why you would want to "agile-proof" your methodology when agile methods seem to be the exact solution you are looking for. Agile methods anticipate (embrace, I think, is the word Kent Beck uses) change and look for ways to minimize risk in the face of inevitable change. It sounds like your project is the poster child for why we need agile methods.

I'd suggest reading one of many books on agile methods and learning about techniques such as TDD, frequent delivery, story-based development, etc. that could really help you to manage the unavoidable change that all projects experience. Jim Highsmith has a good book, Agile Software Development Ecosystems, that provides an overview of several different agile methodologies and how they address particular problems in development.

EDIT: It occurs to me that perhaps what you mean is "change-proof" your development. I sorry to say that I don't think that this is really possible. There are techniques to minimize change, but you can't eliminate it. I've found that it's better to recognize that it will happen and use a methodology that expects it and can manage it better than to try and minimize it. Processes that try to minimize change are very front-loaded with planning activity and take much longer than I am willing to spend for the types of projects that I typically work on. I find that with agile methods I'm able to complete my projects in about the amount of time that I would otherwise have spent planning for a different methodology.

As an aside I recently had a project that, because of political reasons, we had to spend a lot of time gathering requirements and doing product evaluations. It took us about a year to eventually decide what product to get. I had the installation and integration (which used my agile methods) done in about 2 months.

Answer 2

I think what you're looking for is some sort of finite state machine.

But these are typically used for internal state, not to handle arbitrary changes to the requirements. Maybe some sort of UML state machine might be useful here.

Answer 3

One agile methology is TDD.

It has one single, simple rule:

Only write Code to make you test pass... And not a single line more.

With this aproach you will keep your code quite simple. Also the MVC pattern will help you to isolate and centralie the logic of the design in your controller. If you use some mocks to mock out the view it will be quite easy to create a test that will simulate that behavior. If you keep your test fast and simple, you will find that you spend less time in the debugger, since the test is very clear on its goal.