Design First Methodology Preferred

Dilip has used both Test Driven Development and Design First Development at his organization. They find the Design First method to be more effective.

Dilip Writes:

We have tried both the approaches and feel that the traditional approach of preparing a thorough architectural design first and then preparing testing environment is really helpful. This is due to following reasons:

1. A complete view of the project is in front of you.
2. The famous concept of Tom D’Marco of loosely coupled modules becomes evident and wherever there is an entanglement, it can be resolved or simplified at this stage.
3. You get an good idea of developing a robust database design with referential integrity, file groups, key definitions, data volume loads and the potential bottlenecks of complex queries which can be resolved may be by small amount of duplications of data (i.e. not going beyond 3rd normal form etc.)
4. The modules themselves get segregated into simple, less complex, most complex etc.
5. The most complex modules themselves give rise to further breaking down into functional and manageable sub-modules (which at times may ask for changes in database designs, class definitions and even front-end design).
6. The code becomes clean and is fairly independent of testing methods (because testing methods may change but the functionality of a module dose not change so easily). In fact we encourage two types of testing methods – supporting testing methods which help to test individual modules fairly independently as well as help in continuity of the application and second – the defeating testing methods whose job is not to allow the module under testing to function as it is expected to function. This second approach really identifies the security threats and helps to remove some false assumptions, helps elimination of NULLs in say primary keys. The latter helps to improve the code of the said module but still does not disturb the fundamental architecture which is essential for smooth transition into future.

In fact, we are into software development since 1975 and many of our systems are still running even though they have undergone radical changes from Dos-Novell-Windows-Web and yet because of well thought of architecture and functional modularity, the transition has been so smooth that the user have not even realized that so much water has flown from under.

Basically, both approaches are not opponents but are complementary.

At end, your application should be

1. Really useful the user.
2. Easy to maintain
3. Easy to adapt to changing environment.
4. And at all times 100% accurate in terms of results, 100% complete in terms of data, 100% reliable and 200% easy to operate.

Does your company use TDD as a primary software design technique? Especially when it comes to database systems? Why not share with the rest of us how you ended up with that decision by getting into the conversation here online, or just drop an Email to btaylor@sswug.org.

Cheers,

Ben