Start Small (Coding Strategy)

 With regard to the intuition I've developed with my experiences, feedback from my seniors in my past experiences and articles which I've read, I thought of following a strategy which would help my develop activities to be more predictable , easy and fast.

• Start small, don't aim for technical sophistication (using all the language idioms , patterns and principles) on the first go. 

• Complete business functionality before making code beautiful. Working business code should be priority  before anything else.

• We cannot anticipate all future requirements while coming up with architecture of the system, but definitely attempt to create a loosely coupled, layered organization of sub systems so that in future system can be extended without much cost.  

• After complete understanding the scope of the system and realization of sub-features, try building the In-Memory Business Object Model (Using domain driven design concepts) first in a simple reusable dynamic library or static library or in a unit testing container. Based on the non-functional requirements, based on distribution strategy and based on type of UI (Browser, RAID, Single Page etc) these reusable business logic dlls can be wrapped in appropriate frameworks for communication like COM, COM+, Remoting or Unified framework like WCF for BLL Facade . Data Facade/Gateways can be developed to cater data requirements of BLL.

• While requirements will be fulfilled by the Design of Domain Model, Architecture ensures the Quality of Services provided by the application.

• Architectural choices are driven by the following Quality Of Service(QOS) parameters: Performance, Reliability, Availability, Scalability, Security, Flexibility and extensibility.
• Coming up with architecture of Software system is similar to creating a plan for a house. Architecture guidelines contain rigid rules regarding decomposition of system into sub-systems and communication between them. These rules are driven by non-functional and functional requirements & forces like team size , time to market etc.

• Building framework for a software application is similar to constructing the overall structure/skeleton (Foundation, Pillars & Columns) for a building. We can change the internal layout of walls, partitions and interior decoration but changing the framework of building would result in lot of rework.

• Once Architectural guidelines are laid for Software, we need to live with it through out the development. It would be a testing nightmare , if we change the structure/architecture for each build drop.

• Layering , well established contract between the layers and each layer being cohesive and decoupled improves maintainability, adds orthogonality, allows concurrent development, allows internal evolution(Object model) of each layer without changing the contract.

• Identify which parts of application are likely to change in future and identify pattern that will help you change it without the rest of application. Shield the rest of the system(core framework) from change.

• Once architectural guidelines are established and object model of all sub systems and clear responsibilities are realized, start fulfilling the main purpose of each function in classes. 

• Try developing plain objects with single responsibilities and then use them in frameworks like COM or WCF or MVC. This separation of framework code from actual functionality helps improved testability and  leverages swapping of these frameworks or moving to a new framework later.

• Use TDD and other development practices which give continuous feedback loops and refactor periodically to cater the non-functional requirements.  

• API or Frameworks should be developed keeping consumers of that API in mind.
• TDD process contains the loop :- Code => Test => Fix => Test => Refactor.

• During refactoring start making small improvement to Code.

• Objective of each refactoring session is just to make the code better than before. Even changing the function name to an intention revealing name can also be considered as substantial improvement.

• While refactoring try applying practices like KISS(Keep it Simple Stupid), DRY(Don't Repeat Yourself), YAGNI ( You An't Gonna Need It) , SOC(Separation of Concerns), SOLID etc.

• Keep the code simple but not simplistic. Simple doesn't mean compromising with functionality. Code should be clear easy to understand should be like well written prose. Should be simple and direct and should be easy to maintain.  

• For maintainability refactor to simplify the code.

• Cyclomatic complexity measures the number of unique paths that exist in a method, class or application. Higher cyclomatic complexity number, higher the degree of complexity in the Code.

• Don't over use frameworks like Dependency Injection Containers that automates and hides the actual dependencies.

• First establish the dependency contract between different components in a Sub-System and between different sub systems. Then try using Dependency Injection/IOC Containers.

• During refactoring, ensure each function does one and only one thing.

• Try explaining most of your intent in code (meaning full names, nicely organized small cohesive, self contained methods with single responsiblity).

• Apply Law of Demeter. A module should not know about the innards of the objects it manipulates.

• During refactoring apply DRY principle (Don't repeat Yourself). Abstract the common code and move it to a single location. Ensure one representation for every piece of knowledge in a system.

• While refactoring, apply "Tell, Dont Ask" principle. Decompose classes in such a way that the consumer of a class tells to object what actions consumer want them to perform rather than asking questions about the state of object and making a decision yourself on what action you want to perform.

• While refactoring, apply "You Ain't Gonna Need It". Include functionality that is necessary for application. Put off the temptation to add other features that you may think you need.

• While refactoring, apply SOC(Separation of Concerns). Dissect software into distinct features that encapsulate unique behavior and data that can be used by other classes. 
• While refactoring , apply SOLID principles. Apply Single Responsibility Principle. Each method or class should have one and only one reason to change.