Podcast: Solving problems without reading code

moose-iconTudor Girba joins us at ArchConf 2015 where he discusses the work he’s doing to change the way we deal with code and why fundamentally, code is not text but data and can be queried as such.

 
Full Transcript:

Michael Carducci:

You’re listening to the "No Fluff, Just Stuff" podcast, a JVM Conference series with dozens of dates around the country. There’ll be one near you. Check out our tour dates at NoFluffJustStuff.com.

Hey, everybody. I’m your host, Michael Carducci. Welcome to the NFJS podcast. In this episode, I had the opportunity to track down Tudor Girba. He had been speaking for about eight hours that day at ArchConf 2015. You’ll notice that he sounds a little hoarse. That’s why.

We had the opportunity to sit down and talk about some of the research and some of the work he’s doing to change the way that we deal with code at a fundamental level. That’s one of the great things about ArchConf, is that not only do we have experts talking about the latest in technology today, but we have top people who are doing research, who are changing the face of software development into the future.

If you want to be on the cutting edge, check out ArchConf 2016. We have two events. ArchConf West in San Diego is just about sold out. You can learn about both events at ArchConf.com. A-R-C-H-C-O-N-F dot com and check out some of our other events.

Our flagship event, UberConf, this summer in Denver. UberConf.com and our road show, NoFluffJustStuff.com. Let’s sit down with Tudor and hear what he has to say.

[music]

Michael:

Tudor, thank you for coming.

Tudor Girba:

Thank you for having me.

Michael:

It’s the very end of the last show of the 2015 tour. We’ve had some interesting conversations. One of the things that you said right off the bat that caught my attention is you’re working on ways to teach developers to not read code.

Tudor:

I do, yeah.

Michael:

Tell us a little more about that.

Tudor:

I ask this question often [inaudible 01:52] . I asked about a thousand people this year. I asked people, "Do you agree that developers spend most of their time reading code?"

Michael:

I would think, just coming into it from my experience over the years, that being able to read code is a skill that is lacking.

Tudor:

Sure, but there’s a little bit deeper in that. Again, I’m asking people, "Do you agree that developers spend most of their time reading code?" Most people actually do agree, the vast majority of them.

Then I ask the next question. That is, "When was the last time you heard developers talk about how they read the code?"

Michael:

I’ve never heard anybody.

Tudor:

That’s the point and nobody talks about it. What this translates to is that we are spending half of the development budget on something we never talk about. This is not a tiny detail somewhere around an error problem. It’s a huge economical issue.

First we should start talking about it, first of all. Second of all, if we would start talking about it then we figure out reading is actually the most manual way we can approach retrieving information out of code. That’s what we need.

People don’t actually want to read. They want to understand enough to make decisions. Reading is the most manual way to do approach that, to gather the information out of code. There are different ways. Now I am giving the other example. What does a developer do the first time when he approaches a database and there’s some problem in there? He writes a query, right?

What’s the developer do when there is a problem in source code? Start scrolling. There’s no conceptual difference between the two issues. The only difference is in perception. You perceive the first one as a data problem. You perceive the second one as a text problem. That’s what you do with text.

Code isn’t text. Code is data. When you look at it like that, querying, visualizing, measuring. All those things. Mining it in various ways. All these things are natural solutions. The interesting thing is that developers are paid exactly to automate somebody else’s decision making. When they have their problems, they fall back to manual labor. It doesn’t make sense because it doesn’t scale.

Michael:

I’ve never even thought of that from that direction. If the source code is data, how do you query it?

Tudor:

That’s the thing. We went through exercises today. There are simple things. For example, imagine the amount of [inaudible 04:50] every job application today has tons of annotations that people use in order to inject or in order to hook whatever the class is to be the underlying framework.

Yet the IDE doesn’t have first class support for saying, "Give me all the clauses that are annotated like this and like that." There’s no support for that. There is nothing conceptual. There is no real issue there.

Michael:

That’s a solved problem, really.

Tudor:

Yeah, it is a solved problem for a long time. It’s not a problem except that the tools are not made like this. It’s not the difficulty or the issue of how do you query code. It hasn’t been a problem since 15 years, maybe, except that we are not looking at it like that.

Michael:

Nobody’s ever thought to look at that as the problem that it is.

Tudor:

In research, this is no longer a problem. Every IDE already does that behind the scenes. It doesn’t expose it to the engineer. The engineer somehow doesn’t seem to be interested at this point to go beyond the facility the IDE provides right now.

Right now, the tools that we’re exposing engineers to, they are radically broken. We have to rethink them from scratch. There are multiple problems with the tools. By the way, why are tools important?

Michael:

They make us more effective at our job.

Tudor:

Yeah, but there’s been more than that. Everybody now hears about Conley’s Law. I was joking. I was doing a poll during the sessions. I was like, "Who does not know what Conley’s Law is?"

There’s very, very few hands up. It was in the offing, in the presenter’s kits you have to prepare yourself. You have to do this and that. You have to mention Conley’s Law in the presentation. It’s mandatory these days. Everybody should know about Conley’s Law.

The interesting thing with Conley’s Law is that you have this interaction between the organization and the system. It’s not enough to look at the system. You also have to look at your organization because it’s that intertwined, the cause and the effect. It’s not clear cut.

At the same time, while Conley was formulating his law there was this other guy called Marshall McLuhan. He studied the way television and radio was affecting culture, specifically the American culture.

At that time, what he noticed was that there is a deep effect that those little tools that we just added in our lives had on the culture. He formulated something that’s almost like this. We shape our tools and thereafter our tools shape us.

It’s fascinating if you think about software. Like I said, what does a developer do the first time he sees a database? He writes a query. Picture the screenshot of a database tool. What does it have on top?

Michael:

There’s a query editor.

Tudor:

It’s a query box. It says, "Enter query here. You get the results there." What do people do? Enter query here. Get the result there. Where’s the query box of code? There is none.

Michael:

Control-F?

Tudor:

Yeah, but it’s just a very basic…it’s not a query box. It’s just a simplistic way of looking at things. Other people are using graph but that, again, you don’t use graph on a database because you want to take advantage of the structure that you know. It’s the same thing here, it should be, with code.

Michael:

I do see that a little bit more in the JetBrains tools that you can search the entire source tree, search files. There are some really basic tools, like you said, but nothing that has the depth and the complexity of a dedicated query language.

Tudor:

Exactly. There is another thing. What do you do once you have a tool like that? What do you do once you can query your code? One thing we are talking these days is about the relationship between architecture and agility. How do you drive your architecture? How do you, especially in an agile project where everything is changing all the time?

One thing I’m, again, asking people is, "Do you agree that architecture is as important as functionality in the long run?" People do agree, especially people coming to ArchConf. I’m asking the following question. "Do you test functionality?" People say, "Yes, automatically testing for functionality. Yes."

"Do you test architecture?"

Michael:

The question there is, "How do you test architecture?"

Tudor:

Yeah. What is a test of architecture? Let’s say I want to test dependencies. This module should only call that module but not the other way around. If I have a graph, if my data is a graph and I need to check some constraints there, that’s exactly what I’m doing.

That becomes a test for my architecture. Imagine, for example, you want to migrate from one technology to another. How do you know when you’re done with the migration? One way of looking at things is find all the patterns of using the old architecture or the old technology. You get a to-do list.

If you do that automatically then you have to work through the to-do list and make sure when that to-do list is done, then that’s it.

Michael:

Historically, that’s been really difficult.

Tudor:

Yeah, but it isn’t. It’s not. It isn’t. It’s a known problem. We know how to solve it.

Michael:

Again, the compiler’s doing that. The compiler is resolving these dependencies.

Tudor:

Yes, the compiler is, and then the IDE. Every time you right click and look for references for a clause, a method, that’s what happens. That thing is traversing the graph and it gives you the results. The opposite end is this one. The other side of the graph. That’s it. That’s the basic information.

Here’s the more interesting thing. What happened when we made, for example, testing the subject of conversation? We went from babbling and not really doing much to not asking, "Should we test?" We went from asking, "Should we test?" to asking, "How do we test?" What happened when we said, "How do we deploy things?" We started to build continuous delivery as an industry.

What happened? Two years ago micro services wasn’t a topic. Now we have companies that are living by selling a micro services based solution.

Michael:

Micro services is the free in conference bingo.

Tudor:

Right.

Michael:

It’s the one right in the middle.

Tudor:

The point there is that once we make something, once we decide as an industry that something is worth discussing, something is worth debating, looking at, investigating, we find solutions. For me, the basic thing is not we shouldn’t get ourselves tied into the current set of solutions. We should first look at the problem. The problem is huge and we should approach it for the kind of problem it is.

I happen to have worked on a couple of solutions. One is this platform called Moose, so MooseTechnology.org. Our goal there is to show how analysis could look like. How you could have interactively the possibility of building tools.

Our goal there is to help or empower developers to program analysis in under 15 minutes. I say, "I take 15 minutes. In 15 minutes you should be able to extract something that is useful out of your system." That flips those costs.

We need to get those analyses incredibly cheap, as cheap as querying the database. People are writing queries of the database and then throwing the queries away.

Michael:

All the time.

Tudor:

All the time. The same thing should happen with querying code. It’s not just code per se, but it also XML is your code. Locked files are also within that system. Anything around your software system is pretty much data.

Michael:

Do you see this being implemented as its own DSL? Is this just an extension of the IDE?

Tudor:

I think it should be both. Do you know what the I in IDE stands for?

Michael:

Integrated.

Tudor:

Integrated, right? That implies that all activities of software development should be supported in that tool. You shouldn’t leave. It should be there. I do see this thing as being part of that IDE. I do also think there should be a fluid API with which you can program that IDE. We call this the moldable IDE idea.

It’s not necessarily new. Emacs has that one as its core philosophy except that it’s not incredibly visual. Eclipse can do the same but the cost of extended Eclipse is way too large. I think that those extensions must be measured in minutes, and then we really have a chance of transforming the development world.

Michael:

That’s the biggest challenge, is that you’ve got all this legacy code. How do we apply these principles to our code base that’s been developed over the last 20 years?

Tudor:

Exactly. It’s the same as with testing. Again, sometimes you have a system. It’s old. It’s still valuable. By the way, that’s what legacy is, right? Old and valuable. It might not have tests but that doesn’t preclude you from writing tests.

The same thing, functionality, we should treat the architecture exactly like we do functionality.

Michael:

The thing about tests is that, yes, there’s a cost up front to develop your tests but the wonderful thing is that cost repays itself extremely quickly. Venkat, in his pragmatic TDT talk this week, said that this is not measured in years. It’s not measured in months. It’s measured in weeks or days that you get that value back from writing these tests.

Tudor:

Exactly. This is the lesson that we have learned over the last 15 years. I always like to say, "Imagine yourself being a project manager 15 years ago." Don’t imagine. OK, anyway.

At that time, you had two kinds of people working for you. You had the one unit person then you had the two unit person. The proposition of TDT was give the work the one unit person would do. Give it to the one that costs you two units.

It didn’t make any sense and yet, we know at the end, that the cost doesn’t go higher but the quality does go higher. This is absolutely unintuitive and yet it pays off. The reason is that you are paying it anyway. You are paying that money anyway.

The same thing happens with structure. We should simply apply exactly the same kinds of principles that work their own functionality and apply them with structure because we’re paying. The budget is already allocated. We have to turn the energy the way we’re spending that money.

Michael:

How much of this is, because you’ve laid out a very clear and compelling vision of the future of interacting with code and with architecture, but how much of this is still pie in the sky, as it were? Hand wavy, conceptual stuff. How much of it is things that we can do today?

Tudor:

I know it sounds science fiction but I’ve done this for the last six years. I’m working exclusively with development teams. I’m sitting inside there and I’m only using these types of tools to solve problems. It works. I’ve validated this. I summarized these lessons that I learned in the method called humane assessment.

By the way, I call it humane because if you see a person plowing the field with his bare hands you’d say, "Wow, that’s inhumane." When I see a developer scrolling through a million lines of code I say, "That’s inhumane." We have to change that.

I created this method called humane assessment and documented how this actually works. This is absolutely not…it’s very much present. In fact, it’s past, but anyway…

Michael:

If we want to learn more, or get involved, or start looking into these ideas ourselves what are the next steps? Where can we go? Where can we find out more?

Tudor:

Contact me.

Michael:

How do we do that?

Tudor:

Send me an email at Tudor@TudorGirba.com.

Michael:

I would spell that out.

Tudor:

T-U-D-O-R at T-U-D-O-R-G-I-R-B-A dot com. We have an open source community backing up the project that we have. It’s MooseTechnology.org. Our goal there is to redefine analysis. We want to also use Moose as a platform to educate people as to how analysis could look like.

I know that Moose is a starting point. I’m pretty sure that by the end, a couple of years from now, Moose is likely not going to be the end of the conversation. That should be the goal.

Michael:

This is fascinating stuff. I want to say thank you again. Tudor@Tudor…

Tudor:

…Girba.com.

Michael:

…Girba.com and Moose…?

Tudor:

MooseTechnology.org.

Michael:

Fascinating stuff. Thank you for your time. I hope to see you again soon.

Tudor:

Thank you.

[background music]

Michael:

At No Fluff, Just Stuff we bring the best technologists to you on a road show format. Early bird discounts are available for the 2016 season. Check out the entire show lineup and tour dates at NoFluffJustStuff.com.

I’m your host Michael Carducci. Thanks for listening and stay subscribed.

Leave a Reply

Your email address will not be published. Required fields are marked *

*