Analysis Paralysis for Mythical Completeness in Software Design

- Over analyzing requirements, prolonging "Analysis and Design Process" to achieve completeness of design is an Anti pattern in Software development.

- After initial analysis and design, it's better to create a POC (of alternate approaches) and analyze Working POC rather than brainstorming on visual model or document.

- Well designed solution makes simple scenarios easy. It should not prohibit complex things. Simple things should be simple and complex things should be possible.

- Trade-Offs between non functional requirements are inevitable. But we can try to achieve best balance between Trade-offs. ( Reliability Vs Extensibility, Power Vs Simplicity).

- Design should be scenario driven. Scenarios should lead to domain model.( Domain Driven Design).

- Adopting TDD, first create usage code of API exposed by each subsystem. API exposed by each layer should be usable in best possible way( less dependencies, Self contained catering a complete activity, easy to learn etc).

- Use minimum number of concepts while designing.

- Identify which classes should be generic/ templatised and which classes should be specific. Over generalization might provide extensibility but also result in issues related to: type safety, performance issues, understandability etc.

- Don't concentrate on specific extensibility( What if system might be used in a specific different way ?). Rather concentrate on loosely coupled , self contained components. It's easy to identify what might vary ( in the problem domain space) in future ( couple of years). Separate and encapsulate what varies and allow plugging in a new component for that varying behavior.

- Don't unnecessarily increase class hierarchy depth. Clearly Identify which requires a new class, which can be an attribute/member of a class........

- The mismatches between Relaional Model( database tables) and object model ( OO) should be manageable . Design should retain benefits of both models and resolve mismatches between both models

- If you don't want to be constrained in expressing domain model irrespective of the fact that it needs to be synced with relational model( database ) , then it's better to use patterns like DTO( Data Transfer Objects) / BO( Business Objects). These BO's need to be mapped with domain objects using frameworks like Automapper.

- Maintain constant feedback loop and let design evolve.

I am presenting AGILE methodology with my understanding.
:-).