Eiffel windfalls and pitfalls

[Daniel Ståhl]

At the Eiffel Summit of October 2016 experienced windfalls and pitfalls of Eiffel usage were discussed. For reference, the windfalls discussed at the summit were:

• Holistic mindset among developers. Seeing is believing: seeing the entire pipeline in real time is powerful.
• Reduced coordination. System integration used to start by negotiating who to communicate and coordinate. That's largely gone.
• Marrying manual and automated test result data: conceptually they're the same, they should be treated the same.
• Deriving insights from the collected data. You can do very powerful dynamic test selection if you have this data-
• Based on test outcome clustering
• Tests you haven't executed in a long time
• Tests that recently failed
• Tests that tend to fail upon similar changes
• Tests that tend to fail upon changes by this/these particular developer
• Analyzing, understanding and tweaking R&D performance
• Lead times
• Developer behavior
• Integration times
• Integration frequencies
• Product component analysis. What does this product version consist of, what's different from other version X?
• Potential for machine learning in general, neural networks in particular.
  

Similarly, the following pitfalls were raised:

• Throwing everything and the kitchen sink into events.
• Modeling EVERYTHING using events. Don't apply Eiffel in domains where there are already existing established solutions.
• Triggering on individual events. Works for simple use cases, but for advanced use cases you end up with very complicated stateful triggers. The proposal here is to react to changes in state of higher abstraction level entities, rather than to the events themselves.
  
• Presenting a steep learning curve and a high adoption threshold.
• Timing issues between consumers and services. If one triggers on an event that event may not actually have been processed by e.g. persistence solutions where one does subsequent look-ups. This is similar to the general problem of distributed transactions in cloud environments. The solution is to try to avoid this, and is related to the problem of triggering on (multiple) individual events in the first place.
  

[Andrey Devyatkin]

More windfalls

• Possibility of delivery pipeline that goes across diverse environment which allows developers in different teams choose different tools, i.e. allow heterogeneous development environments
• Allows easy inclusion of deliveries from external suppliers to CD pipelines