Home //
Solving real problems without reading code
Too often, developers drill into the see of data related to a software system manually armed with only rudimentary techniques and tool support. This approach does not scale for understanding larger pieces and it should not perpetuate.
Software is not text. Software is data. Once you see it like that, you will want tools to deal with it.
Developers are data scientists. Or at least, they should be.
50% of the development time is typically spent on figuring out the system in order to figure out what to do next. In other words, software engineering is primarily a decision making business. Add to that the fact that often systems contain millions of lines of code and even more data, and you get an environment in which decisions have to be made quickly about lots of ever moving data.
Yet, too often, developers drill into the see of data manually with only rudimentary tool support. Yes, rudimentary. The syntax highlighting and basic code navigation are nice, but they only count when looking into fine details. This approach does not scale for understanding larger pieces and it should not perpetuate.
This might sound as if it is not for everyone, but consider this: when a developer sets out to figure out something in a database with million rows, she will write a query first; yet, when the same developer sets out to figure out something in a system with a million lines of code, she will start reading. Why are these similar problems approached so differently: one time tool-based and one time through manual inspection? And if reading is such a great tool, why do we even consider queries at all? The root problem does not come from the basic skills. They exist already. The main problem is the perception of what software engineering is, and of what engineering tools should be made of.
In this talk, we show live examples of how software engineering decisions can be made quickly and accurately by building custom analysis tools that enable browsing, visualizing or measuring code and data. Once this door is open you will notice how software development changes. Dramatically.
Tudor Gîrba
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.
More from Tudor
ALL SESSIONS ↗Explainable software
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.
Reflective Thinking
On the one hand, agile processes, like Scrum, promote a set of practices. On the other hand, they are based on a set of principles. While practices are important at present time, principles allow us to adapt to future situations. In this talk we look at Inspection and Adaptation and construct an underlying theory to help organizations practice these activities. Why a theory? Because, as much as we want to, simply invoking "Inspect and Adapt" will not make it happen.
Steering Agile Architecture
"Emerge your architecture" goes the agile mantra. That’s great. Developers get empowered and fluffy papers make room for real code structure. But, how do you ensure the cohesiveness of the result? In this talk, we expose how architecture is an emergent property, how it is a commons, and we introduce an approach for how it can be steered.
Storytelling in a technical world
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?
Software assessment: the discipline of technical decision making
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.
#remote, #nomeetings, #noestimates, #nobacklog
The #remote, #nomeetings, #noestimates, #nobacklog recent trends tend to disrupt the classic approach to software development. In this talk, we explore this space also based on my own experience of working with teams to build projects that rely on all these.
Architecture as a business asset
Architecture is as important as functionality, at least in the long run. As functionality is recognized as a business asset, it follows that architecture is a business asset, too. In this talk we show how we can approach architecture as an investment rather than a cost, and detail the practical implications both on the technical and on the business level.
Beyond Technical Debt
"Technical debt" is a successful metaphor that exposes software engineers to economics, and managers to a significant technical problem. It provides a language that both engineers ("technical") and managers ("debt") understand. But, "technical debt" is just a metaphor that has its limitations, too. The most important limitation is that it presents a negative proposition: The best thing that can happen to you is having no technical debt.
McLuhan's Law
Marshall McLuhan told us among other things that "We shape our tools and thereafter our tools shape us." If this is true, we should be very careful with the tools that we expose ourselves to because they will determine the way we are going to think.
Software in pictures
Software has no shape. Just because we happen to type text when coding, it does not mean that text is the most natural way to represent software. We are visual beings. As such we can benefit greatly from visual representations. We should embrace that possibility especially given that software systems are likely the most complicated creations that the human kind ever produced. Unfortunately, the current software engineering culture does not promote the use of such visualizations. And no, UML does not really count when we talk about software visualizations. As a joke goes, a picture tells a thousand words, and UML took it literally. There is a whole world of other possibilities out there and as architects we need to be aware of them. In this talk, we provide a condensed, example-driven overview of various software visualizations starting from the very basics of what visualization is.
Two and a half days with the people writing the playbook.
Insightful sessions, inspiring ideas, and meeting your peers — the skills and methods that take your organization to the next level.