You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_Tudor Girba builds tools and techniques for improving the productivity and happiness of software teams. He currently works on the Glamorous Toolkit, a "moldable development environment" for Pharo, that developers can easily adopt to suit their needs. Tudor is a self-proclaimed "software environmentalist", sounding the alarm about how quickly we create code, and how slowly we recycle it._
Programmers spend roughly [50% of their time reading code](http://www.humane-assessment.com/guide/assessment-costs/). But, as Tudor Girba likes to ask, "When was the last time you talked about _how_ you read code?" Likely never. Isn't that curious? We talk endlessly about static vs dynamic typing, agile vs waterfall methodologies, and unit vs functional vs integrated testing, but don't spare any breath on the single activity we spend most of our time on.
14
+
15
+
Clearly we aren't reading code for pleasure. Our goal is to read the minimum necessary to understand enough to make a decision. Software engineering is primarily a decision-making business, "rather than a construction business, which we optimized for, for the last 50 years."
16
+
17
+
This bias is embedded in our tools. Where do we read our code? In an _editor_! If you are charged with solving a bug in the code, what do you do? You scroll. This is in stark contrast to how you'd approach an inconsistency in the database: you start with the query box, write a query, look at the data, refine the query, etc.
18
+
19
+
Yet code is data as much as the data in a database is data. It's highly structured and can be just as massive. But because we we use a textual notation for input and are focus on the inputting, we use a _text editor_ to understand our code. And because our text editor doesn't have a query box, we don't query. We scroll.
20
+
21
+
> We shape our tools and thereafter our tools shape us.
22
+
>
23
+
> -John Culkin / Marshall McLuhan
24
+
25
+
The irony is we don't make this mistake with the tools we build for others. We build web _browsers_, data _analyzers_, customer-relationship _managers_ (CRM), content _managers_ (CMS), media _players_, music _sequencers_, and game _simulators_. "The systems we build actively prevent end-users from ever seeing the raw data. And yet those end users make better decisions for it. So we in software know how to transform data problems into decision-making problems. That's a skill we can utilize for rethinking the way we do our business."
26
+
27
+
What would it look like to re-imagine software engineering as a decision-making?Let's start with meetings. If software is about decision making, the goal of meetings should likewise be making decisions. "Do we go this way or do we go that way?" Tudor found that as a rule of thumb, decisions should take five minutes. If they take longer, stop the discussion and go back to gather data until the argument is clear one way or the other. The sum of this work is the Humane Assessment, a methodology for making software engineering decisions. In 2009, Tudor put his method to the test:
28
+
29
+
> if this method would work, it has to work in the crappiest place that I can find or in the crappiest system that I can find. So I was actually looking around for one of those, and I picked one and then I led the development in that company for three and a half years to actually see that this thing actually works, and it did work.
30
+
31
+
This decision-making methodology is only half the battle. We still need the proper tools to gather the relevant data to support those decisions. In his consulting practice, Tudor built custom tools for each client. He assumed that eventually he'd be able to abstract over patterns and build a generalized tool. But he found no such cookie-cutter solution. He realized that "software is the most contextual thing we've ever created as the human species, and as a consequence we can't build a generic software analysis platform."
32
+
33
+
To be relevant, the tool must understand your specific context, for example the specifics of your build system or how you resolve dependencies. But there's no off-the-shelf tool for that. The only people who understand your context in all its little details is you and your teammates. You need to make your own tools to understand your system.
34
+
35
+
But who's got time for that? If the trade-off is reading code manually vs building myself a custom code-analysis tool, I'll muscle through reading line-by-line. What if we could drastically reduce the time and cost of building your own code analysis tools?
36
+
37
+
Tudor's current project is the Glamours Toolkit (GT). He calls it a "moldable development environment," because it empowers developers to quickly and easily adapt their environment to specific problems and contexts. Influenced by Smalltalk, Emacs, their IDE aims to be an environment you can tailor to understand your specific system.
38
+
39
+
They consider it a failure of their IDE any time you have to resort to drawing on the whiteboard to explain your system. The tool is designed to make it really cheap to build custom visualizers for whatever objects you want to inspect. It then saves these visualizers for you to choose from whenever it encounters another such object in the future.
40
+
41
+
For that matter, they consider it a failing any time you have to "leave the IDE," because the "I" stands for "integrated" after all. Googling for documentation, libraries and example code is suboptimal. The worst offense is copying and pasting errors and hoping for an answer on Stack Overflow. That's implicitly admitting that we don't have any chance to understand our own problems. Code is only a black box today because we don't yet have the right tools to look under the hood.
42
+
43
+
But the stakes are higher than 50% of your professional life.
44
+
45
+
Code lives for a long time. There are many companies that still run software on mainframes. The speed at which we can recycle old code is capped by the speed at which we can _understand_ old code. Currently this is linear because we read code line-by-line. At the same time, the body of software grows exponentially year over year, way outpacing our ability to recycle it.
46
+
47
+
We mass-produce programmers to mass-produce code to eat the world with software before the next startup beats you to it. From this perspective, we behave very much like the plastic industry, focusing exclusively on production without regards to what happens when our product is no longer needed. Alongside the landfills of plastic, we setting ourselves up to bequeath our children mountains of code that nobody understands. Nobody wants their legacy to be code, because [nobody likes legacy code](http://chadfowler.com/software,/development,/career/2011/03/17/leaving-a-legacy-system.html).
48
+
49
+
Clearly the answer isn't _read faster_. There's simply too much code. Just like we built tools to recycle certain kinds of plastics, we need to build tools to help us better understand and recycle our old code. We need moldable development environments.
12
50
13
51
## Transcript
14
52
15
53
_Transcript sponsored by [repl.it](https://repl.it/)_
16
54
55
+
[Corrections to this transcript](https://github.com/stevekrouse/futureofcoding.org/edit/master/{{ page.path }}) are much appreciated!
0 commit comments