Tudor Gîrba

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.

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 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.

DX: why developers should care about the tools they use

About at the same time when Conway was coining his now famous law, Marshall McLuhan warned us that “we shape our tools, and thereafter our tools shape us”.

IDEs are supposed to be the tools software engineers use. Yet, most IDEs are primarily focused on the active part of writing code, while developers actually spend most of their time understanding systems. Assessing software systems is perceived as rather secondary and mostly supported in the small. The IDE is not as integrated as it could or should be.

We have to rethink the developer experience because software is immaterial and the tools we use are the only way through which we experience software. The tools we use matter.

In this talk, we take a systematic look at how a developer experience could look like and what an environment for developers should be made of. We exemplify the message with live demos of the Glamorous Toolkit (http://gtoolkit.org), a project aiming to reinvent the IDE.