Product: when you get attached to your baby
We take care of a product, we help it grow, we tend to it day after day just as we care for a baby. We become attached to it, and that’s perfectly fine.
As a young developer, I swore by the greenfield approach: lacking the methodological and architectural tools to scale from codebases of 10,000 to 100,000 SLOC (Source Lines of Code), I jumped from project to project, starting each time on a better foundation but never managing to break through that order-of-magnitude barrier.
Over time, I’ve found a few of these tools. They came to me through my reading, my experiments, and discussions with my peers. I had missed these tools so much that I made them the core of my expertise: software quality. I’m still discovering them, sometimes creating my own, and constantly searching for new ones.
What are they, exactly?
-
Tools related to the target (“What is well-designed software?”): modularity, architecture, test strategies, Test-Driven Development, and, above all, the principles of clean code;
-
Tools related to the various paths leading to the target, by which I mean refactoring methods: Golden Master, Mikado Method, Strangler Fig Pattern… So little known and yet so essential.
As my skills developed, what I enjoyed changed. Little by little, I learned the quiet charm of “brownfield,” that codebase you nurture and care for like a child. You fix a bug in a product just as you care for a child; you add new features to the former just as you teach the latter; you evolve the application model just as you offer a child a worldview to help them adapt. We could take this metaphor even further.
This child, this product, we want so many things for it; we’re ambitious, perhaps even too much so at times. The product is what it is, with its strengths and weaknesses. We take care of it day after day, we fix it, we improve it, we help it grow, but above all, we accept and love it just as it is today, without waiting… While hoping, of course, that it doesn’t turn into a horrible, pimply teenager 😱
On closer inspection, this personal journey is closely tied to the rise of Agile, which shifted the focus from projects to products. A project is defined by its end: once the scope is achieved, the team is disbanded and the project moves into maintenance. Developers, for their part, are assigned to new projects, hence the “greenfield” approach.
A product, by contrast, has no predetermined end. We hope it will have a long life, guided at every moment by feedback from its users. Like a child who eventually becomes an autonomous, self-willed individual, the product slips beyond our control: we don’t know what it will become, but we love it. Yet the team responsible for developing it is there, just as parents are always there for their children. Hence the brownfield approach.
In your opinion, is it problematic to become attached to the product you’re developing?