Thinking about Practices

A few preliminary words

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.

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.

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:

1. Active Stakeholder Participation / How to define a stakeholder ?
2. Architecture Envisioning / What concepts should be used to describe architectures and how to differentiate architecture levels ?
3. Document Continuously / What kind of documents should be produced and how should they relate to life-cycle ?
4. Document Late / How to time the production of documents with regard to life-cycle ?
5. Executable Specifications / What kind of requirements taxonomy should be used ?
6. Iteration Modeling / What kind of modeling paradigm should be used ?
7. Just Barely Good Enough (JBGE) artifacts /  How to assess the granularity of specifications ?
8. Look Ahead Modeling / How to assess requirements complexity.
9. Model Storming / How to decide the depth of granularity to be explored and how to take architectural constraints into account ?
10. Multiple Models / Even within a single modeling paradigm, how to assess model effectiveness ?
11. Prioritized Requirements / How to translate users’ value into functional complexity when there is no one-to-one mapping ?
12. Requirements Envisioning / How to reformulate a lump of requirements into structured ones ?
13. Single Source Information / How to deal with features shared by multiple users’ stories ?
14. Test-Driven Design (TDD) / How to differentiate between business-facing and technology-facing tests ?

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.

Further Reading

• Agile between Space & Time
• The Scope of Agile Principles
• Agile vs Waterfall: Right vs Left Brain ?
• From Stories to Models
• Agile & Models
• Agile Falls
• Thinking about Practices
• Spaces, Paths, Paces (Part 1)
• Spaces, Paths, Paces (Part 2)
• Tests in Driving seats
• Projects as non-zero sum games
• Iterative Processes

External Links

• Agile Modeling Best Practices
• Scaled Agile