These days many software development projects are executed using agile model.
To be efficient, agile programming requires agile design.
And fortunately OOAD by first principles is agile. Example: I can begin modeling an organization even before I know about the various divisions of the organization. I can always extend the design as I become progressively aware of the divisions.
This ability to see ’one in many’ abstraction requires a certain line of thinking, by no means, common.
Recently I was reviewing a design – the application is around a spatial assembly of a number of entities. And each entity occurred in many variations.
Neither the Requirements nor the Design made any serious attempt to seek out the commonalities across the variations of each entity – kind of flat and unfolded. The team was ready to modularly code in a very straight-forward manner every variation as and when it was encountered.
On the downside, this approach means a design sure to offend the purists, less reuse and more effort in coding, testing and fixing. On the plus side no great skills of abstraction are required and the coding is also rather simple and fast. Given the all-round shortage of skills, this approach cannot be despised altogether?
A new trick the old dog must learn? Leaves me a little unsure of what I’m standing for.