Company buys some business framework that seems to match their needs in the short-term perspective. It is easy and fun to use it initially - you just need to work with some big building blocks and the framework will do the rest for you.
As the time goes, company gets to met new requirements that steer to them from the probable future that they’ve never considered (this always happens). Every encounter will be like a gamble. You’ve got 80% that you can deliver solution that meets this requirement using just the provided building blocks.
And there is 20% chance that you will just will not have LEGOs for a trivial task of simply adding a nice porch to the house (and if you keep on gambling, you will always lose, unless you control the game).
Company could start asking the LEGO manufacturer for the “porch building block” accidentally spiking the community discussion about it. It will turn out that a lot of other players also want to add the porch to their house, but with different decorations and functionality. So they will gather and try to ask for the “Flexible porch building block”.
Surprisingly enough this discussion would lead to the definition that this building block should be able to transform into different shapes to accommodate for the houses that were already built: starting from the office center in Washington and up to the small cottage down in Siberia.
And this all-transforming block has to be big on the outside (otherwise it will not plug into the existing building blocks with large connection joints) and have all the required functionality on the side.
Now, let’s have a look from the toy manufacturing company’s point of view - how much design and effort will it take to deliver this new building block that fits with the bigger ones but is required to take many different shapes.
Or they can start working on delivering and supporting ten different porch blocks (one for mountain house in Tibet, another for the flower shop in Sydney etc). And here comes another question how many other house elements can you name? These could need customization, too.
So the logical solution is to give everybody smaller building blocks to build porch as they see fit (that’s what happens to kid’s LEGOs as they grow up). However there is a side effect - the old houses are not really compatible with the new construction sets, since they have the different joint sizes. So you would either need to throw them out or buy special adapter blocks.
What are the obvious solutions in this situation, if you know that your kid is going to grow really fast up and he loves LEGO? Either get ready for the ongoing expenses or get him a set that is composed of preassembled building blocks that look like the big ones on the outside. As the time passes, he will learn that he can actually take any of these wall pieces apart and turn it into the porch.
Well, he actually might invent some really cool design and share the idea and/or his blocks with his friends.
I think that the really funny (and true!) part of this is that we (the software development community) spend a lot of time talking about how the industry needs to evolve further towards being a real engineering discipline, with more mature processes, etc. that mirror (or at least more closely resemble) real-world engineering disciplines, and yet we keep trying to build “Flexible porch building blocks” of a style that NO real-world engineering group would ever choose to pursue.
Were there a company building partially-assembled porch additions for houses, they would have a whole product line in different shapes, styles, and sizes. We instead focus on the fact that software is so flexible and end up producing “Flexible XXXXX building blocks” that are so heavy and complex that the only projects that can end up making good use of them are the ones with the maximal set of requirements.
This is one of the reasons why I love seeing projects like Autofac popping up. It isn’t trying to be THE container. It is just trying to be the container for projects where the Autofac style of container makes sense, and I hope that this approach is never discarded in favor of trying to be THE container.
Jeremy,
I agree with the extreme disparity between the development and some real-world production. Probably that’s because business value is being generated by software in some abstract space (minds of the managers and devs) and it is really hard to measure the efficiency of this process as it goes. And even after the project has been delivered, it is still hard to calculate profits and TOC (especially if you use it inside instead of selling).
If you can not measure and compare something, then you can not control it (since you do not know what is good and what is bad). This leads to total confusion in the “Best practices and guidelines” of the development.
What can one do in this situation? Probably just reinvent controlled development process for himself: capture the statistics, mind the specifics, collect and systematize the experience, make the assumptions and try to prove their validity. Then calculate profits/losses as the final performance index and try to answer the “Why?” question for every number.
About the Autofac. Yes, I share you hopes about this wonderful container. I love it and hope that it will stay itself. I depend on it))
Best regards,
Rinat Abdullin