You must join the family, that huge family of story tellers
Focusing on the ending makes you forget to make the process good. And, bad processes create bad products. The product migh meet the minimum requirements, but it’s insides will be ugly.
Grand Unified Theory of Software Development
This is what Jim Weirich tried to present in 2009, I know this was 3 years old, but it’s so important to ignore it.
Basically what Jim proposed is a concept that contains software engineering practices, such as:
- SOLID
- Law of Demeter
- DRY
- Small Methods
- Design by Contract
This Unified Theory is called Connascence and derives from “What Every Programmer SHOULD KNOW ABOUT OBJECT ORIENTED DESIGN” by Meilir Page-Jones, in words of Jim Weirich
… however the third part of the book is worth the price of the entire book, and in that part he defines a term called Connascence …
What this concept tries to cover is the knowledge of some element based on the existence of a different element created (born) at the same time.
So we have several categories of Connascence:
- Name: when multiple components must agree on the name of the entity
- Type: when multiple components must agree on the type of an entity
- Meaning: when multiple components must agree on the meaning of specific values
- Position: when multiple components mus agree on the order of values
- Algorithm: when multiple components must agree on a particular agreement
- Execution: when the order of execution of multiple components is important
- Identity: when multiple components must reference the entity
Ok, I’m not going to enter in details, in fact my advise is view the presentation by Jim Weirich and check Gregory Brown’s article Connascence as a Software Design Metric, which is the one that introduce me into this concept.
All I want to write here is the understanding I have for this concept, so if any of you disagree or have better ways to explain, please comment :)
Connascence exists when the coupling between two or more entities demands a change in those entities (method name, parameters, execution, etc.) if one of the entities change its coupled property
Tech debt is code which a reasoble engineer, in the present, wishes was different
Cuando necesito probar una idea, antes siquiera de implementar la solución, me salto TDD, utilizo fragmentos de código que a veces no solo son feos, sino que a veces están incompletos. Pero la idea detrás de semejante caos es ver si la idea funciona, si en su estado más descuidado puede cumplir la función que se espera, luego puedo dedicarme a pulir el código y convertir ese código feo, en algo no solo funcional, sino estético y bien estructurado.
Uncle Bob: Why is estimating so hard?
Do you think is easy to implement any procedure, well it’s not as easy as you could think ;)