Working Modal for Development

Most developer / software house does not put time to organise their concept of development.
Especially in Malaysia, most companies try their best to tender for project which squeeze their time and budget to as minimal as possible, leading to untested and non-flexible (rapid) system.

One of the best modal to work on will be:
AMDD - Agile-Modal Driven Development

It uses modal concept to plan overview system flexibility, while implementing TDD (Test-Driven Development) to have system test unit developed before the actual development begin.
By using this concept, development can be planned from overview to tasks to-do, and allow brain storm on variety of posibilities of business processes.

Project estimation has to be planned with a range of posibilities, problem from: simple case scenario to worst case scenario (everything that could involve, and more...) .

Each client have to understand that development of software requires proper planning.
Any changes on the system could involve major changes. For example, we can refer to any building structure. We can do changes on or in the building itself, but not changing the overall structure of the base nor the pillar concept. Changes on the overall structure could lead to reconstruction of the entire project, which could lead to duplication of afford and time used.

As a professional, we who is in the software development industry should see things in a long run. We should set a border line for time and money, in order to ensure everyone have a fair treatment and time constraint. For example: standardization of petrol price. If each petrol supplier tend to fight for lowest price, quality of product will reduce. People will tend to find the cheapest cost to deliver the software.

Comparing TDD and AMDD:

• TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.

• TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.

• TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.

• TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.

• TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.

• TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).

• TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.

• TDD is non-visually oriented whereas AMDD is visually oriented.

• Both techniques are new to traditional developers and therefore may be threatening to them.

• Both techniques support evolutionary development.

Reference:
http://www.agiledata.org/essays/tdd.html

Please correct us if we did any mistake on the article above.
Feel free to drop us comment :)