It's quite fun to build components during project development. There is the excitement of reusing components and seeing them react in different ways based on the use case; of course it's so much fun because it's a testament to how beautiful your "work of art" is.
A lot of times, to continue in this state of ecstasy, one tends to keep adding functionalities to a single component, making it more flexible for different use cases but ultimately making it more complex.
This might not seem to be an issue when working in a system that uses the waterfall approach to project management. In that situation, you can foresee the majority of the use cases for a component you create, which can mitigate the major issue with complex components.
However, an attempt to bring such glee driven development style to an Agile environment would most likely end up in chaos. In an agile environment, things can change swiftly. You can start a project with a process flow and by the end of the project, that flow could have been reversed, replaced or even taken out completely.
With a tightly coupled component style, you will have to constantly make changes to one component, adding and removing functionalities, leaving you confused a lot of times. The feeling of ecstasy that led to building the complex component would be tilting towards misery in no time. And many times, you would have to break down the component into the respective individual parts (as components should ideally be made).
Simplicity is the ultimate sophistication - Leonardo Da Vinci
The simpler you make components to be, the more flexible and thus, functional they can actually be. And an agile environment requires flexibility at its best, so when building components, especially in an agile environment, use "Agile Components" - simple components.
Top comments (0)