PRESENTED BY
Tudor Gîrba
CEO/software environmentalist at feenk.com
Software systems should not remain black boxes. In this talk we show how we can complement domain-driven design with tools that match the ubiquitous language with visual representations of the system that are produced automatically. We experiences of building concrete systems, and, by means of live demos, we exemplify how changing the approach and the nature of the tools allows non-technical people to understand the inner workings of a system.
Software appears to be hard to grasp especially for non-technical people, and it often gets treated as a black box, which leads to inefficient decisions. This must and can change.
In this talk we show how by changing our tools we can expose the inner workings of a system with custom visual representations that can be produced automatically. These representations enhance the ubiquitous language and allow non-technical people to engage actively with the running system.
We start from describing experiences of building concrete systems, and, by means of live demos, we exemplify how changing the approach and the nature of the tools allows non-technical people to understand the inner workings of a system. We then take a step back and learn how we should emphasize decision making in software development as an explicit discipline at all layers, including the technical ones. This talk is accompanied is relevant for both technical and non-technical people.
Tudor Gîrba (tudorgirba.com) is a software environmentalist and co-founder of feenk.com where he works with an amazing team on the Glamorous Toolkit, a novel IDE that reshapes the Development eXperience (gtoolkit.com).
He built all sorts of projects like the Moose platform for software and data analysis (moosetechnology.org), and he authored a couple of methods like humane assessment (humane-assessment.com). In 2014, he also won the prestigious Dahl-Nygaard Junior Prize for his research (aito.org). This was a surprising prize as he is the only recipient that was not a university professor, even if he does hold a PhD from the University of Bern from a previous life.
These days he likes to talk about moldable development. If you want to see how much he likes that, just ask him if moldable development can fundamentally change how we approach software development.
Looking at what occupies most of our energy during software development, our domain is primarily a decision making business rather than construction one. As a consequence, we should invest in a systematic discipline to approach making decisions.
Our technical world is governed by facts. In this world Excel files and technical diagrams are everywhere, and too often this way of looking at the world makes us forget that the goal of our job is to produce value, not to fulfill specifications. Feedback is the central source of agile value. The most effective way to obtain feedback from stakeholders is a demo. Good demos engage. They materialize your ideas and put energies in motion. They spark the imagination and uncover hidden assumptions. They make feedback flow. But, if a demo is the means to value, shouldn’t preparing the demo be a significant concern? Should it not be part of the definition of done?
Insightful sessions, inspiring ideas, and meeting your peers — the skills and methods that take your organization to the next level.