What lies Beneath the Hood?
It is the 21st century and thus it is almost a certainty that a custom application has been built for your enterprise. Do you ever wonder how the code is crafted behind the user interface you see day-to-day? Do you especially wonder this when the second party you hired to refine the application seems to be struggling to change it?
It is good to wonder what lies beneath the hood. Custom application development may be approached in numerous ways. There are industry standards for many good practices, but there are also some grey areas. The need for maintainable software is paramount however, and should be the prime consideration when weighing options for an approach. It is best not to build a mess in the name of fast turnaround and low cost which may not meet product owner expectations or be agreeable to change. Look out for two pitfalls:
Beware of the big ball of mud.
Headspring Systems employees object-oriented design and the Single Responsibility Principle ensuring that logic is divided into independent pieces so modular and diminutive that any one piece has but one reason to ever change. This keeps the code base easy to reverse-engineer and modify. In the absence of this discipline a big ball of mud forms in the code as "God classes" progressively become harder and harder to either refine or "work around" (i.e. hack.) Headspring furthermore loosely couples core business logic to that which interacts with it (the user interface, the database, web services, etc.) and guarantees that each modular, diminutive nugget functions as expected by way of unit and integration tests. These safeguards ensure that an application may be appended without breaking what already works.
Beware of waterfall.
This is an approach to custom application development in which requirements are gathered upfront and then never refined along their journey to "completion." Headspring Systems undertakes Agile development to ensure that work is broken into sprints and at the end of every sprint iterative stakeholder feedback is digested in the name of course corrections, be they minor or major. At the end of an Agile undertaking, an application will meet expectations. At the end of the waterfall process, developers can only hope they landed somewhere within the ballpark of what was desired so that the requests for rework are possible and require only mild backpedalling. Also a velocity (the speed of incremental progress) is evident early in the Agile process while turnaround time for crafting functionality is otherwise notoriously hard to estimate.
Our first focus is .NET Custom Software
We know the dos and don'ts.