How you can prevent your products from becoming obsolete tomorrow
We live in incredibly fast-moving times. How can we ensure that today's hot product isn't completely outdated the next day? There are plenty of examples of this: tablets and 3D televisions are already on the wane again. Who knows whether VR glasses and 3D printers won't be out of fashion again tomorrow? As a developer, you can - at least to a certain extent - protect yourself from technological developments. The approach is not new, but as with many other concepts that are actually "self-evident", it is worth taking a closer look. What is meant here specifically functional thinking.
Function is often a top priority during development: It is not without reason that the focus is often on the functional requirements, while the non-functional requirements are probably often neglected. Nevertheless, the focus quickly shifts to the systems and subsystems, or directly to the components that will later implement the system.
This approach is perfectly legitimate, as it has proven its worth in the past. In order to develop a system, it must be broken down into smaller parts. Intuitively, it makes perfect sense for the system structure to be the leading structure. However, this also means that the view of the main functions of the system "further down" can be lost.
So what?
Again, you might ask yourself: What's the point? We have been successfully developing comprehensive systems for decades. This aspect becomes particularly interesting when the technologies used to implement the functions change rapidly, and that is precisely the problem we have today.
Functional thinking becomes interesting when technologies change rapidly [tweetthis]Functional thinking becomes interesting when technologies change rapidly[/tweetthis]
There are many examples of systems with a constant function whose technology has changed, sometimes dramatically, over time. One of the classic examples is image capture, which has evolved from paint and brushes (commissioned painters) to classic film and Polariod to digital photography.
The best solution for the customer
Ideally, you should approach a problem as solution-neutral as possible. In practice, of course, this is rarely the case: for a car manufacturer, it is a given that it will be a car. The developers would certainly not come up with the idea of building a train or a helicopter, even if that might be the "better" solution for a certain situation (what "better" means often depends on the non-functional requirements, by the way).
Don't be in love with your own technology
But to stay with the car: Why did Tessla have to appear on the scene to finally make the electric car socially acceptable? Porsche would actually have been in a much better position to develop an electric sports car. Perhaps the focus was not on the function ("sporty driving"), but on the technology ("high-performance combustion engine")?
There are enough other examples: Nokia should really have invented the smartphone, Microsoft the cloud business. What these examples have in common is that the actual technology was placed above the implementation of the core function for the customer.
But how?
Functionality has long been taken into account in product development. However, two things are missing: firstly, the consistency of the functions is not always taken into account. This means that when developing a subsystem, it is not always clear to which main function the subsystem contributes. This can lead to the subsystems not making their optimum contribution or containing superfluous elements.
Functional thinking in SE: Considering the continuity of functions in the system, and occasionally questioning the structure of the system [tweetthis]Functional thinking in SE: Considering the continuity of functions[/tweetthis]
Secondly, the structure of the system should be questioned regularly. This does not mean that you have to start afresh every time. But it is worth thinking about whether the justification "we've always done it this way" is really the best one.
If you would like to find out more about this topic, I recommend the book Model-Based System Architecturewhich includes a chapter on the FAS method (Functional Architectures for Systems).
