On the 20th of September 2018 I had the opportunity to attend and speak at a small event organized by CON.ECT Event Management.
The title was “Software Trends”, and to be honest, I wasn’t expecting much when I heard of it. However, I was super surprised by the quality of the talks held there. Learned a bunch of things, met some nice people and so forth. Definitely worth writing a summary on
Lego™ Serious Play™ by Lukas Zenk
This was a very well-structured talk about Lego™ Serious Play™. After Lukas fleshed out his background, he described some challenges that organizations face today. Digitalization is on the rise, and today’s world changes rapidly. Organizations require what Lukas dubbed “Organizational Resilience”. In past times a companies strategy to deal with new challenges might involve defensive or progressive measures. Companies might also choose to focus on flexibility. Today, it is not enough to focus on a single measure. Instead, strategies to deal with future challenges need to involve diverse measures. Coming up with such strategies is hard.
To survive today, companies need to be able to respond quickly to changing circumstances, which can often involves improvisation. They must focus on customers needs and be able to clearly communicate and to empathize.
Lukas then treated us to a brief outline of how Lego™ Serious Play™ came into existence. Supposedly the then-head of Lego™ became frustrated with the lack of creativity in his own managerial stuff when the company faced a crisis, which is why he commissioned some researches to come up with some method to boost innovation while involving the companies own product - Lego bricks!
The method was created with some core ideas in mind, such as that every participant should contribute ideas equally. Conventional workshops and methods often involve 20% of attendees contributing 80% of the content. The core process of Lego™ Serious Play™ is this:
- A question or problem is formulated. For example: “What is your role in this company?”
- Everyone has some time to form a metaphor that answers this question using Lego bricks. Lukas brought up an example where one participant would build a Lego elephant in response to the above question.
- Everyone gets their chance to explain their metaphor.
- The group reflect on what was said. The gained knowledge can be used in conventional planning methods such as TODOs.
Overall a very interesting talk, I recommend you check out Lukas Website.
Agile Kung-Fu by Andreas Mitter
The beginning on this talk started out quite similar to the previous one. Reasons for organizations to change such as the war of talents or time to market were brought up.
Often new developments prompt organizations to try to transform into a more agile incarnation of themselves. More often than not this results in companies just “doing” agile practices, but not much else. In order to better support companies in their agile transformation Bearing Point (who Andreas works for) have developed what they call the Agile Check. It involves four grades, which were named after Karate belts: White, Yellow, Brown and Black. Companies are graded using these grades over six dimensions: Structure, People, Corporate Processes, Technology & IT-Management, Tools & Techniques and Product & Service Development.
Andreas went into great detail here, explaining the various criteria. For example, if you still rely on a strict hierarchy, that might earn you a white belt in structure, where being able to deploy your product within seconds would maybe earn you a black belt in Product & Service Development. There was also some audience participation: Using an online poll one could vote on which grade they would give their own company in each of the six dimensions. Funnily enough, not a lot of participants considered their organization to have a black belt in any of the dimensions
DevOps Challenge: Testing Variation-Rick Systems by Rudolf Ramler
Rudolf works for the Software Competence Center Hagenberg and began his talk outlining some major Challenges DevOps faces today, among which are of course thorough testing and reducing legacy systems.
Good projects are variable rich, he explained. Often there are many command line arguments, configuration parameters and plugins. All of those are required deliver a great customer experience, but come at the expense of increased development effort and of course, difficulties during testing.
Rudolf presented a simple application that was available in various configurations. Using it a user could draw lines and rectangles, use different colours and delete what they drew. One version of the application could only draw lines, the other only rectangles and so forth. Using this application Rudolf highlighted the feature interaction problem, namely that features often interfere with each other in unexpected ways. In the case of the demonstration the user could wipe the canvas if only lines or rectangles were available, but if the feature to draw both lines and rectangles was available the wipe function would only clear rectangles and leave the lines on the canvas.
Finding bugs of that sort can be quite difficult. The number of test cases required to cover an application rises exponentially with the number of configuration parameters. This number can be reduced by using pairwise combination: Testing not all individual configurations, but instead testing all possible combinations of two configuration parameters. Research has shown that this is quite effective, and can reveal up to 80% of the bugs caused by feature/configuration interaction in an application. That number goes up if you use 3-way combination of features, but so does the number of test cases.
Overall Rudolf delivered a nice talk that was heavily grounded in research, which I really enjoyed.
Refactoring and Testing Legacy Applications by Ardit Ymeri and Myself
Jop, I’m gonna include this for completeness. This is the talk I held with my colleague Ardit. It was about how you can approach refactoring legacy applications. We are pretty happy with how it turned out. You can find the slides right here.
The Journey to the Cloud by Gregor Wolf
In his talk Gregor detailed how his company made the transition from producing standard software (CMS) to selling a framework for customers to create their own CMS. Basically a personal experience account. Gregor highlighted some problems with standard software, after which he gave the following definition of a framework:
- Every component in a framework can be replaced
- Components can be added and enhanced
- The design of a framework is API first.
- A framework is customizable.
He explained that creating frameworks instead of standard software creates not only technological challenges, but also leads to a significant target group shift. The software is no longer built only for end users, who expect to buy and then simply use the software, but for developers - who incidentally tend to be more picky.
Gregor stressed that because of this, community is key for the success of a framework. You require top-notch documentation and tutorials. “If a feature is not documented, it’s not there” were the words he chose I think. He also highlighted how his company struggled because parts of the infrastructure their framework relied on did not consist of true micro services. This caused many problems down they road, as they found that they could not scale properly because of hidden dependencies. Still, Gregor said that the decision to rely on micro services was the right decision.
The event hosted some additional talks:
- KI: Was lernen wir daraus? by Thomas Zibermayr
- Digitalisierung in der IT = Prozesse + Tools + Mensch by Michael Amann-Langeder
- Azure DevOps by Gerwald Oberleitner
Unfortunately, it was getting late in the afternoon, I was pretty tired, and my notes on those talks are incomplete. I don’t feel that summarizing them here would not do them any justice, so I recommend you check out the follow-up release on the event here to get more details. As soon as its released, that is. That’s all folks.