Ready to Jump to the Software Feature Factory Alternative?
I first started working on software building features on demand in the late 1990’s. I know what it means to build them. There is promise and a sense of productivity in building them. Before we go further, let’s define what, at least, I believe a Feature Factory is.
Feature Factory: A culture of software development where new features are requested, built and debugged in conveyor-belt like fashion for a long time with little regard for the overall design of the system. Stories and bugs fill a backlog. Product Owners sort them. Developers work them. All this works until one day the system is deemed “Legacy”.
How does this system of development build a legacy system undetected? One day, someone runs into a persistent issue. And then another. And then the pile builds up where nothing of significance that the business is asking for can be applied to the system. The software is now termed “legacy” and everyone is scrambling to either fix or replace the whole system.
As humans, we tend to suffer the conditions of the boiling frog. I won’t describe the gruesome details. What is worse, knowing nothing else, we jump into the next pot of cold water. We don’t even talk about that last pot of water, what happened, or how to avoid it. If you have been in and around custom software construction, either as Subject Matter Expert, Product Manager/Owner, Architect or Developer for at least 3 years, you likely know this story.
Then a smarter frog comes along and tells you a story where there is a pond that never boils. You don’t believe them. Then you never see them again.
When I was in that cold water one day after having been boiled a few times, a smarter frog came along. I decided to investigate. That was in 2010. What was eerie was this notion that a couple of systems I designed, one in 2001 and 2007, were modeled after the business they were serving. I had intuitively, without knowing it, due to a desire to not build hard to manage software, spent time building something we now call Adaptive Systems.
The smarter frog showed me Domain-Driven Design (DDD). And at that moment, I was given a definition for an ethereal concept I already had but could not explain. To be fair DDD by Eric Evans was far more developed and advanced than my rudimentary thinking. This made a new learning curve out of systems development for me. It has taken some time to unlearn a lot of bad habits. Yet, the spirit of DDD was the same as my better system design thinking. Essentially, I wanted to position and organize the assets of these systems such that they map to the real need and are easier to change over time.
Now, if we go to the new pond, can we drift back to the cold water that eventually gets the heat turned on? Sure. There is work involved in not going back to our old ways. But the opportunity is right in front of us to build and remodel systems with an eye toward domain alignment. We can have adaptive systems if we want it. We just must want it more than staying with the familiar.
If I can do it, so can you.
