Tudor Gîrba

#remote, #nomeetings, #noestimates, #nobacklog

Tuesday, 8:30 PM EST

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.

Can #remote, #nomeetings, #noestimates, #nobacklog really work? What if we employ them at the same time? If we look at the open-source space, we see that we indeed can build highly successful and innovative projects while working completely remotely, rely almost exclusively on asynchronous communication, rely on no estimates and even no real backlog.

What does that mean for the enterprise? At the very least, we should accept that these are not a fad, and we should not equate them with lack of engineering. Instead, we should look at successful examples and learn from them. In this talk, we do exactly that. We go through concrete examples and observe the implications on the way we work and on the systems we can build.

Explainable software

Wednesday, 9:00 AM EST

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.

Software appears to be hard to grasp especially for non-technical people, and it often gets treated as a black box, which leads to inefficient decisions. This must and can change.

In this talk we show how by changing our tools we can expose the inner workings of a system with custom visual representations that can be produced automatically. These representations enhance the ubiquitous language and allow non-technical people to engage actively with the running system.

We start from describing 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. We then take a step back and learn how we should emphasize decision making in software development as an explicit discipline at all layers, including the technical ones. This talk is accompanied is relevant for both technical and non-technical people.

Architecture as a business asset

Wednesday, 11:00 AM EST

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.

Often systems that have great current value are expensive to evolve. In other words, the future value of the system is highly influenced by its structure. Indeed, when I talk with technical people, they broadly agree with the idea that architecture is as important as functionality, at least in the long run.

If we truly believe this, we should act accordingly. If two things are equally important, we should treat them with the same way. Given that functionality of a system is considered a business asset, it follows that the architecture is a business asset as well. That means that we should stop perceiving the effort around architecture as a cost, and start seeing it as an investment.

Functionality receives significant testing investments through direct development effort, dedicated tools and even education. In a way, testing is like an insurance, but unlike other insurances, this one is essentially guaranteed to pay off later on. Now, do you check the architecture with the same rigor? Do you have automatic architectural checks that prevent you from deploying when they fail? Not doing so means that half of the business assets remain uninsured. Half.

How can you test architecture automatically? You need to first see the code as data. The same applies for configurations, logs and everything else around a software system. It’s all data, and data is best dealt with through dedicated tools and skills.

Steering Agile Architecture

Wednesday, 1:30 PM 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

Wednesday, 3:15 PM 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.

Storytelling in a technical world

Wednesday, 5:00 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.

Software assessment: the discipline of technical decision making

Thursday, 9:00 AM EST

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.

Assessment denotes the process of understanding a given situation about a software system to support decision making.
During software development, engineers spend as much as 50% of the overall effort on doing precisely that: they try to understand the current status of the system to know what to do next. In other words, assessing the current system accounts for half of the development budget. These are just the direct costs. The indirect costs can be seen in the quality of the decisions made as a result.

One might think that an activity that has such a large economical impact would be a topic of high debate and improvement. Instead, it is typically treated like the proverbial elephant in the room. In this talk, we argue that we need to:
• Make assessment explicit. Ignoring it won’t make it go away. By acknowledging its existence you have a chance of learning from past experiences and of optimizing your approach.
• Tailor assessment. Currently, developers try to assess the system by reading the source code. This is highly ineffective in many situations, and it simply does not scale to the size of the modern systems. You need tools, but not any tools. Your system is special and your most important problems will be special as well. That is why generic tools that produce nice looking reports won’t make a difference. You need smart tools that are tailored to your needs.
• Educate ourselves. The ability to assess is a skill. Like any skill, it needs to be educated. Enterprises need to understand that they need to allocate the budget for those custom tools, and engineers need to understand that it is within their reach to build them. It’s not rocket science. It just requires a different focus.

Software environmentalism

Thursday, 10:45 AM 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, 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

Reflective Thinking

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