Tudor Gîrba

Solving real problems without reading code

Thursday, 9:00 AM EST

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.

Steering Agile Architecture

Thursday, 10:45 AM EST

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

Testing, pair programming and code reviewing are the proposed means to approach this problem. However, testing is only concerned with the functional side of a system, and thus, it is not able to capture structural contracts. Pair programming and reviewing work well in the small, but they do not scale when you need to handle the millions of details entailed in modern systems.

Another way of approaching the structure of the system is through standard checkers, such as FindBugs or Checkstyle. These are fine tools, but when they are left to only check standard idioms, the specifics of your architecture remain unverified.

The architecture of the system is important and it deserves special attention because it is too easy for it to go wrong in the long run, and it is too expensive when that happens. In this tutorial we detail a method of approaching this challenge by steering the architecture on a daily basis through:

• making architectural concerns explicit,
• crafting automated checkers,
• agreeing on findings, and
• distilling corrective actions.

One challenging aspect is that of constructing custom analysis tools during development. This process requires a new kind of infrastructure and associated skills that enable you to craft such checkers fast and cheaply. However, this is a technical detail. The critical benefit comes from making architectural decisions explicit, and from the daily actions of cleaning the state of the system.

This talk is targeted to both engineers and managers. We cover the basics of the process, and we accompany the conceptual descriptions with real life examples.

Software in pictures

Thursday, 1:30 PM EST

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

Storytelling in a technical world

Thursday, 3:15 PM EST

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.