Skip to main content

Posts

Showing posts from November, 2013

Abstraction to a Point

Architecting and implementing software is a constant balancing act.  First the design has to work in the end but the underlying implementation can vary greatly, event during development. Re-use existing classes that almost fit, or create a new or derived hierarchy for just what is needed.  Abstract out the needs in base and helper / utility classes, but not too complex to not allow modification for the ever changing requirements.  Is the abstraction clear to others that will be maintaing the code, months or years later?  Should the abstraction only existing for the main feature / operational aspects of the application or should they extend to the smaller aspects of the operations as well. It's a constant battle of decisions during implementation. The abstraction point is not isolated to development as the cost associated with these decisions can increase the code and timeline of the implementation and even place a project at risk. During sprints for adding new features th