Tudor Gîrba

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.

Developers are developers. But, developers are also users. And like any users, they need appropriate tools that match and augment their abilities, too.

IDEs are supposed to do just that. They are supposed to bring together into one coherent interface all tools related to development. This is what “I” stands for.

But, let’s look at it: all IDEs I know have in forefront the text editor. And there are some powerful editors out there. Those editors are particularly good at creating code, but are terrible at understanding code. Why terrible? Well, imagine having to optimize the traffic in a city, and only be given a magnifier glass as a tool. The editor is exactly that: a magnifier that shows with great details every line of code. Clearly, the design of the IDE does not favor the big picture.

And that’s not all. Let’s look at search: how do you search for concrete annotations in your IDE, such as quickly finding all Java methods annotated with @Interesting(“with specifics”) that also match a name pattern? Given that annotations are more and more pervasive, should it not follow that the IDE makes it possible to quickly find them without involving regex file search? Or let’s consider inspecting objects: when you inspect a map object, why do you see a tree? Should it not be more appropriate to see a table instead? Should the IDE not make it possible to offer presentations that are better suited based on the context at hand? And why are pictures not pervasive in our world?

These are just some examples. The “I” is not that integrated. We can do better. We have to do better. We have to put the developer experience in the forefront.

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

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.

Visualization 101:

• A brief history
• Pre-attentive abilities (we understand most of the outside world through the eyes)
• Gestalt principles of visualization

How to visualize

• trees, treemaps
• graphs
• charts
• maps

What to visualize

• software structure
• software relationships
• software runtime
• software history
• software data

Interactive software visualizations

• handling interaction
• software

Visualization as data transformation

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.

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?

That is not even all. A good demo tells a story about the system. This means that you have to make the system tell that story. Not a user story full of facts. A story that makes users want to use the system. That tiny concern can change the way you build your system. Many things go well when demos come out right.

Demoing is a skill, and like any skill, it can be trained. Regardless of the subject, there always is an exciting demo lurking underneath. It just takes you to find it. And to do it.

In this session we will get to exercise that skill.