Tudor Gîrba

Solving real problems without reading code

Tuesday, 8:30 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.

Beyond Technical Debt

Tuesday, 10:30 AM EST

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

Technical debt is both brought about and solved as a result of decisions. As such, we turn our attention to how people reach decisions about a software system. Decision making is a critical software engineering activity. Developers alone spend some half of their time reading code. This means half of the budget. Even though it is the single most significant development activity, nobody really talks about how this effort is being spent.

It’s time to change this. The talk motivates the need for software assessment as an explicit discipline, it introduces the humane assessment method and outlines the implications.

Storytelling in a technical world

Tuesday, 8:30 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.

Reflective Thinking

Wednesday, 5:00 PM EST

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.

It turns out that for almost half a century the software engineering community has been working on a theory of reflection, which is defined as “the ability of a system to inspect and adapt itself”. We draw parallels between the design of software systems and the design of organizations, and learn several lessons:

Reflection must be built into the organization.
Reflection incurs a cost that must be planned for.
Inspection is easier than adaptation.
We can only reflect on what is explicit.
Reflection is a design tool that enables unanticipated evolution.
This sounds technical, but the most important observation is that reflection is an inherent human ability. It only requires training to develop it into a capability.

Steering Agile Architecture

Thursday, 9:00 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.

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 environmentalism

Thursday, 1:30 PM EST

We produce software systems at an ever increasing rate, but our ability to cleanup after older systems does not keep up with that pace. Because of the impact of our industry, we need to look at software development as a problem of environmental proportions. We must build our systems with recycling in mind. As builders of the future world, we have to take this responsibility seriously.

On the one hand, this is great. On the other hand, our ability to get rid of older systems does not keep up with that pace. Let’s take an example: a recent study showed that there are some 10’000 mainframe systems still in use containing some 200 billion lines of code. These systems are probably older than most developers. This shows that software is not that soft, and that once in use, systems produce long lasting consequences. We cannot continue to disregard how we will deal with software systems at a later time.

Engineers spend as much as half of the effort on understanding software systems and the percentage grows with the size and age of the system. In essence, software engineering is more about dealing with existing systems than it is about building them. Two decades ago, Richard Gabriel coined the idea of software habitability. Indeed, given that engineers spend a significant part of their active life inside software systems, it is desirable for that system to be suitable for humans to live there. We go further and introduce the concept of software environmentalism as a systematic discipline to pursue and achieve habitability.

We must build our systems with recycling in mind. We have to be able to understand these systems in the future and be able to reuse and evolve them as needed.

Engineers have the right to build upon assessable systems and have the responsibility of producing assessable systems. For example, even if code has often a textual shape, it is not text. Hence, reading is not the most appropriate approach to deal with code. The same applies to logs, configurations and anything else related to a software system. It’s all data, and data is best dealt with through tools. Not any tools would do either. We need custom tools that can deal with specific details. No system should get away without dedicated tools that help us take it apart and recycle it effectively.

Who should build those tools? Engineers. This implies that they have to be empowered to do it. We need to go back to the drawing board to (1) construct moldable development environments that help us drill into the context of systems effectively, (2) reinvent our underlying languages and technologies so that we can build assessable systems all the way down, and (3) reeducate our perception of what software engineering is.

Because of the spread and impact of the software industry, we need to look at software development as a problem of environmental proportions. As builders of the future world, we have to take this responsibility seriously.

Software in pictures

Thursday, 3:15 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