A theory (aka model) is a symbolic description of contexts and concerns. A practice is a set of activities performed in actual contexts. While the latter may be governed by the former and the former developed from the latter, each should stand on its own merits whatever its debt to the other.
Good practices hold sway without showing off theoretical subtext (Demetre Chiparus)
With regard to Software Engineering, theory and practice are often lumped together to be marketed as snake oil, with the unfortunate consequence of ruining their respective sways.
Software Engineering: from Requirements heads to Programs tails
While computer science deals with the automated processing of symbolic representations, software engineering uses it to develop applications that will support actual business processes; that may explain why software engineering is long on methods but rather short on theory.
Yet, since there is a requirements head (for business…
A theory (aka model) is a symbolic description of contexts and concerns. A practice is a set of activities performed in actual contexts. While the latter may be governed by the former and the former developed from the latter, each should stand on its own merits whatever its debt to the other.
Good practices hold sway without showing off theoretical subtext (Demetre Chiparus)
With regard to Software Engineering, theory and practice are often lumped together to be marketed as snake oil, with the unfortunate consequence of ruining their respective sways.
Software Engineering: from Requirements heads to Programs tails
While computer science deals with the automated processing of symbolic representations, software engineering uses it to develop applications that will support actual business processes; that may explain why software engineering is long on methods but rather short on theory.
Yet, since there is a requirements head (for business processes) to the programming tail (for automated processing), it would help to think about some rationale in between. Schools of thought can be summarily characterized as formal or procedural.
How to make program tails from requirements heads
Formal approaches try to extend the scope of computing theories to functional specifications; while they should be the option of choice, their scope is curtailed by the lack of structure and formalism when requirements are expressed in natural languages.
Procedural approaches deal with the difficulty of capturing users requirements by replacing theoretical assumptions about software artifacts with guidelines and best practices for modus operandi. The fault here is that the absence of standardized artifacts makes the outcomes unyielding and difficult to reuse.
Procedural (p), formal (f), and agile (a) approaches to software development.
Pros and cons of those approaches point to what should be looked for in software engineering:
As illustrated by Relational theory and State machines, formal specifications can support development practice providing requirements can be directly aligned with computing.
As illustrated by the ill-famed Waterfall, development practices should not be coerced into one-fits-all procedures if they are to accommodate contexts and tasks diversity.
Agile answers to that conundrum have been to focus on development practices without making theoretical assumptions about specifications. That left those development models halfway, making room for theoretical complements. That situation can be clarified using Scott Ambler’s 14 best practices of AMDD:
Active Stakeholder Participation / How to define a stakeholder ?
Architecture Envisioning / What concepts should be used to describe architectures and how to differentiate architecture levels ?
Document Continuously / What kind of documents should be produced and how should they relate to life-cycle ?
Document Late / How to time the production of documents with regard to life-cycle ?
That would bring the best of two world, with practices inducing questions about the definition of development artifacts and activities, and theoretical answers being used to refine, assess and improve the practices.
Takes Two To Tango
Debates about the respective benefits of theory and practice are meaningless because theory and practice are the two faces of engineering: on one hand the effectiveness of practices depends on development models (aka theories), on the other hand development models are pointless if not validated by actual practices. Hence the benefits of thinking about agile practices.
Along that reasoning, some theoretical considerations appear to be of particular importance for good practice:
Enterprise architecture: how to define stakes and circumscribe organizational responsibilities.
Systems architecture: how to factor out shared architecture functionalities.
Products: how to distinguish between models and code.
Metrics: how to compare users’ value with development charge.
Release: how to arbitrage between quality and timing.
Such questionings have received some scrutiny from different horizons that may eventually point to a comprehensive and consistent understanding of software engineering artifacts.
