Matthias Noback, Author of Recipes for Decoupling

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Frontmatter podcast I’ll be interviewing Matthias Noback.

Based in Zeist in the Netherlands, Matthias is an author, public speaker and a software developer, a trainer and a consultant.

You can follow him on Twitter @matthiasnoback and check out his website at matthiasnoback.nl.

Matthias is the author of a number of Leanpub books, including PHP for the Web: Learn PHP without a framework, Rector - The Power of Automated Refactoring, which he co-authord with Tomas Votruba, and most recently, Recipes for Decoupling.

In Recipes for Decoupling, Matthias discusses software design principles and practices you can use to help you future-proof your code to better endure the inevitable changes in any dependencies you rely on, and that are subject to inevitable change or obsolescence.

In this interview, we’re going to talk about Matthias’s background and career, professional interests, his [product-type], and at the end we’ll talk about his experience using Leanpub to self-publish his book.

So, thank you Matthias for being on the Leanpub Frontmatter Podcast.

Matthias: Of course, thanks for the invitation.

Len: This is a part where regular listeners will know that I normally ask someone for their origin story. But we’ve already gone over that. Nine years ago -

Matthias: Wow.

Len: - was when Matthias was first on the podcast. In 2013. Wow indeed. That episode was published in January 2014. So, it’s been a long time.

Although it’s not your entire origin story, nine years is a long time. And so, I was wondering if you could just give us a little bit of a summary of what you’ve been up to in all that time?

Matthias: It’s nice to go back to that era and think about how it went back then. Because I just had a regular job, as a programmer. I somehow felt like I wanted to do something different, and to write about what I did.

So I started blogging. And then, like in 2014, was the year that A Year With Symfony was published. The first book on Leanpub. I took the advice - well, he didn’t really personally give me the advice, but Chris Hartjes, who was also publishing on Leanpub, it was an example. It looked like he was doing a great job with that. I thought it would be a nice platform to start writing. And I just never stopped writing.

Every year or so, I feel like something else has to be written and has to be published. And so I do that. Leanpub is still, I think, a great platform for that. It has evolved in several ways. But it has also been quite true to the original idea, like being able to publish a book in a very lean way. So very easy to do, and easy to make quick updates.

So that’s what I’ve been doing ever since. It’s sometimes just like - here is something that might be interesting, and, well, next week I’ll publish something else that also is interesting. And then together, it becomes a book. So it’s a good match after all these years.

Len: It’s great to hear that it’s still a good match. Beginning with the A Year With Symfony book, you then started in this career as a public speaker and consultant, and things like that. You said that back then, you were working a sort of a normal job. But you eventually went independent. Around what time did you make that big leap?

Matthias: I think within a year after the book arrived. I really started to look for independent jobs. There was one year where I still had a job as an employee at a company. But I soon realized that I really wanted to be independent - not to stand for any business in particular. But to be in-between businesses, and help everybody where possible. Or maybe not everybody, but to do different jobs in different places, and not for a very long time. Although, I don’t want to be anywhere for too short a period of time. I just want to know what’s going on, and really invest some time and energy there, and hopefully do something useful.

This could be many things. I have done a lot of programming in the meantime. But also, indeed, the training part, the consulting part - and between jobs, doing public speaking as well.

Although, I must say, since the pandemic, a lot has changed. Not as many conferences as back then, and not as many flights through Europe. And much more mostly remote. Sometimes meetups still, but a lot less physical contact between developers and -

Len: I’d like to ask you specifically about how the pandemic affected what you do. But before we get there, I’d like to get into a little bit of the details. Because a lot of our listeners are people who - I mean, it’s partly because Leanpub is a self-publishing platform, so people who are interested in that part of what we do are interested - they typically have a little bit of an independent streak, and a desire to be a bit more autonomous maybe, than you might be under other circumstances.

And so, when you made this leap to leave a regular job - let’s say, for example, with consulting. How do you go about -? I mean, you’ve learned over the years - but how did you go about finding clients initially, and how do you go about it now? Since you’ve written and published so much, for example, do they now just come to you? Or do you have to go out fishing?

Matthias: Not very often. I rarely get any emails from recruitment or something just out of the blue, companies asking for help or offering me a job or anything. I’m always a bit surprised about that, because it seems to come with a public profile, where people just jump on you.

On the other hand, I’m quite happy. Because I wouldn’t like to answer everybody to say “no” or something. Or actually to look into every bit that’s going on, and decide if something should be done there.

But I do have - most of the time, it’s a really personal moment, where a friend or someone I already know or have worked with, comes with some new assignment, that might be something for me. I’m happy that this is the way it mostly works.

Len: And for those who don’t know, what would an example of an assignment be? Would it be that someone at this company is adopting a new framework, and, “I know this guy Matthias, who knows all about that. Should I bring him in?” Is it that the kind of thing?

Matthias: Yes. My topic is mostly about architecture, the bigger picture for applications. How to design them well, and keep things maintainable in the long run. But also, how do you work on making a new feature? And sometimes bigger projects, how do we do that? How can we work better together as a team, work together even on the same feature, which has become known as “pair programming,” or mob programming. Working with legacy code is one of my favorite topics, and making something better gradually and safely.

Len: I’d to talk to you about architecture and about legacy code and things that, for sure. On a bit of a higher level though - I’ve asked this question of a number of people on the podcast before - but I think a lot of people might be surprised to hear that with programming teams, it can be advantageous to bring in an outside consultant.

The ordinary question would be, “Well, why can’t the team handle all of that themselves? Why can’t they just learn pair programming? Or, “Why can’t they just read a book on software architecture, and then all just make a decision?” What’s the structural momentum behind the usefulness of bringing in an outside consultant for a team?

Matthias: It’s maybe hard to say, about my part in that. The way I think it usually works, is that there are some things already going on in the team. There is a need to change something. But it’s really hard within the established structure.

And sometimes even just - well, because there are forces in the company that prevent change - and sometimes it’s not on purpose, but it’s just the way it is. It can help if somebody comes in from the outside and starts fresh, in a new way, and maybe introduces things in a way that it’s less big of a change.

So, just small things you can do while you’re working on your existing work. The issues that you would normally pick up, and do it in a slightly better way.

Sometimes that’s already very helpful. Because all those little changes, they become the bigger change in the end. But I’m always there for a limited time. So, I’m not really sure what happens afterwards. But I’m lucky that most of my clients are companies that I speak with also a couple of months later, a couple of years later even.

Len: This isn’t so much in the programming world, but often in the world of consultants, I’ve heard stories, and been part of processes, where there is some resistance coming from some direction somewhere, and if you can just attribute the change to an external source, you can get away with things that you might not be able to get away with -

Matthias: That’s right.

Len: - if you just try to do them directly.

Matthias: It’s very helpful for the team that’s already working there, to be able to say, “Oh, but Matthias said it, let’s do it, he said it. Because, well - we are paying him for that.”

Although, I really don’t want to be the person that just says what to do. Usually I look for the things that everybody already knows, and already wants, and amplify that, maybe just by talking to a few different people than they are talking to already. Or by providing them with additional arguments to make that discussion work.

Len: I imagine in the olden days, when you got started in the mid-2010s, basically probably everything was in-person, right? Where you’d fly or what have you - and you’d go to meet these teams?

Matthias: Yeah. And that was a lot of fun. But recently - I think - again, the pandemic, right? It changed everything.

In the beginning, no company came to ask, “Can you come over and fly over here, and work together with us?” It was mostly already remote from the start. Just mostly the training programs were - I immediately started offering them remote programs as well, which worked really well. So, I still reached those companies. But I didn’t go there.

And, well, in part, I miss it. Because it’s always a lot of fun to be there, in a different city, and find my way there, and meet these people who are very much alike. We are all, indeed, the technical folks - we all look the same and talk about the same things. It’s just nice to be with similar people, but in a different place.

I’m also slightly worried about the environment, that’s one thing. It has become clear that all the flying might not be as good as we thought it could be. I mean, it has amazing benefits. But, I feel I wouldn’t want to do it that much anymore.

Len: It’s funny - I’d like to ask you specifically about how the pandemic affected you where you live in the Netherlands, but just to share a personal story about transportation and the pandemic - I don’t have a car, and I work from home. And at the beginning of the pandemic, I went nine months straight without getting on or in any form of conveyance. No bicycle, no skateboard, no car, no plane.

And then I went to visit a friend and his family for Canadian Thanksgiving, and within the course of two hours, I got on a sea plane, a taxi, and a ferry.

Matthias: Wow.

Len: So, land, sea and air - all within one brief moment.

As isolating and sad as so many features of it were, I think, on a certain level, everybody had an opportunity to assess how they lived their day-to-day lives, and whether they needed to live the way that they were. I’m trying to focus on some of the positive things here. So, there are a lot of people who will never buy a loaf of bread again, because they learned how to make it. And that’s nice.

And there are a lot of people who maybe realized, “I can walk to the grocery store. Get a backpack. I don’t need to necessarily drive my car everywhere to do everything all the time,” and things that.

Just on a very personal note, people finally learned the correct distance to stand apart from each other. It’s not distancing, it’s called “politeness.”

But in any case - what was it for you specifically where you live, and given the work that you do? How did it affect you at the beginning, and what’s it like now?

Matthias: Right. So, it’s very weird to get closer together, now that it’s possible. And I agree that it feels - okay, maybe it’s better not to be that close sometimes?

But on the other hand, I think that’s one of the things where it sometimes goes wrong for me personally. Is that - I basically forgot about all the options in a way. Closing everything down and staying at home, and cancelling so many things - it’s really hard sometimes to get back into the habit of going somewhere. Going to the theatre sometimes even. That feels it’s a big thing. And I wouldn’t want it to feel that. It’s just a shame. Because it can be so much fun, also to be around people and - recently I started playing the violin again in an orchestra.

Which has also been - I used to do this. But, it took a lot of effort to go back there.

Len: I know what you mean. I had a bit of a misanthropic moment the first time I got on a flight, after having not been on one. Not the sea plane one, but a proper flight. Where I was in the airport, and there was this guy who started whistling. And I’m like, “You arsehole. There’s other people around. We can’t not hear your nonsense.”

And then there was someone talking. All these mundane things. Someone talking loud on a phone. And I’m like, “Uh.”

It’s just like, “No, get over yourself”. People shouldn’t do those things, by the way. But at the same time, like, “Get over yourself, this is part of living with other people, is they’re going to fart and they’re going to be a bit nonsense - and stuff that.”

Matthias: Yeah.

Len: And it becomes strange again, and maybe it can be a little bit difficult to get re-used to it.

But in your city where you lived, was there ever a like, “You can’t leave your house,” lockdown?

Matthias: No, not really. No. I don’t feel that ever happened, and -

Len: Okay. Did people start wearing masks outside, and things that?

Matthias: that’s right. I think the worst things were - being infected, stay home. Stay really at home, and making arrangements.

But it’s funny, because within our family, half of us got infected and the other half not. So they could still do everything that would normally have been - normally, earlier in the pandemic, they would have to stay at home as well. But the rules had already changed, so they could go out.

It would be really bad, if you really had to stay home all the time. The house would be too small, I guess?

Len: And how did things change for you professionally? You mentioned it a little bit already. Did the amount of work you had go down? Or did it go up?

Matthias: I would say up, mostly because of the training requests, a lot of them remote.

It’s interesting, because before that, nothing was remote for the trainings. But it makes so much sense. Because it’s just generally very expensive to go somewhere. It takes a lot of time. We have the plane tickets and anything else that needs to be covered. Hotel nights before and after the training. And the training day itself. So it’s very inefficient for everybody. I’m really happy that it has become more of a standard way of doing this. And it has remained that.

People are still sending me emails for remote training. That still makes a lot of sense. Although I also know that being in a call - and for more than a couple of hours, it’s really heavy for everyone involved.

I’m still struggling a bit with that. Mostly limiting the time to three and a half hours, with every hour, having a break. That’s really important, to step away sometime.

The afternoon should not be spent behind the computer. So it’s a different way of doing it.

It now takes two mornings, for instance, instead of one entire day. But it used to be very efficient - fly there, do the training, fly home - and that’s it. Now it’s more easy going, and it’s really important.

Len: That’s really fascinating. I’ve interviewed a few people who have had to learn new ways of doing things. There was this one woman in particular who worked for HashiCorp. She and her co-author published a book about digital-first events.

Her job - there’s this company that’s fully remote, and always has been. They would have these big events every year, or maybe even more than one. They were truly big events, the kind where you book a big venue a couple of years in advance, and stuff that. And then - boom, COVID happened - and all their plans collapsed.

They had to learn how to do things digitally, right? And there are these things, that - you learn, like, what’s too long? You know what I mean? For people to just be in one session.

Matthias: Yeah.

Len: They learned to add little bits of entertainment here and there in-between things, which was very useful.

Realizing that standing or sitting, watching a video and listening to someone talk in front of a computer - is just very different from sitting in a conference hall or in a meeting room.

Matthias: Very different. And even though, in a physical space, you can still look at your phone, or take out your laptop or something, if you are behind your computer, it’s really hard to not just - I’ll talk to a different thing, and they look at it. And you can see it happen, of course, when everybody has a camera on. There is this gaze at some point in everybody’s eyes. That’s my cue that something needs to change. We need to do something different or have a break.

Len: When I was researching for this interview, I saw that you did a talk with , I think a meetup group called “DDD,” Domain Driven Design Africa, for example.

Matthias: Oh yeah.

Len: I think that was during the pandemic. I was just curious if that virtual meetups is something that you’ve seen an uptick in the last couple of years as well?

Matthias: That’s right. In the Netherlands, we had to - It was quite interesting. We had around ten different user groups for PHP. Every city had one. I think a lot of them have disappeared.

But on the other hand, the ones that are still there, they are now at least hybrid, doing remote and in some office somewhere. Anybody can join from anywhere in the world.

So that’s very cool, I think. Sometimes you would see a meetup being scheduled with a talk that is really interesting, but you can’t go there. And now, you can just watch.

Len: You mentioned PHP, which gave me a great opportunity to segue into the next part of the interview, where we’ll talk a little bit about the books that you’ve written in the past, and the work that you do as well.

So, you mentioned legacy code and software architecture, and we’ll talk about both those things. But a big area of focus for you has been PHP.

I was wondering, imagine someone’s listening to this, and they have no idea what that is. Can you explain for a moment what PHP is?

Matthias: Right, yeah. PHP, well, I should say, has become a very serious language that is used for many web applications. Many big ones. I don’t know the numbers, but it seems that the internet runs on PHP? Or at least we can be led to believe that. We have some great tools for that. Some very good frameworks. Also, some very good supporting tools for writing maintainable code. Static analysis tools. They have become very big recently. Or, I would say, maybe even in the last couple of years.

So, any issue that you might run into when you deploy an application, you can already figure them out, just when you’re still working on the code, and you will get all of these errors and warnings and things.

But also, and this is something I’ve been writing about as well - you mentioned the Rector book. We have automated refactoring tools. That’s a very, very powerful thing for PHP, that has become, or is still becoming more popular in the past few years.

Len: It’s interesting, these questions of popularity and PHP.

Matthias: Yeah.

Len: Or the web runs on PHP. For those who might not know, PHP is a programming language that’s used by people to make stuff you’ll interact with on your computer, on the internet, as it were. In your browser, and stuff like that. It’s been around for a long time, and one of the features of it, having been around for a long time, is that there are lots of older sites, and things that, that were made by people who maybe were just throwing things together?

Matthias: Yeah.

Len: A lot of stuff in the early days was very on-the-fly, and PHP was around during what we’ll put in quotes, “the early days.”

How have things changed in the last nine years around PHP? Maybe if you could talk a little bit about that?

Matthias: Yeah. I think that’s interesting. I also feel, okay, I have to defend myself here. Which is also a very interesting thing happening all the time, in particular with books.

I’ve had, well, two books published by more traditional publishers, Apress, which was totally open to PHP books. But I had some discussions with Manning. And they really didn’t want me to write a PHP book, because of these issues, right?

If you say, “It uses PHP and code samples.” Then it’s like, “Okay, leave it. The bigger developer community is not interested in that.”

What I think is interesting, is that, back then in 2014, there were a lot of PHP developers who were suddenly taking PHP much more seriously than had been done before. This resulted in a lot of interesting developments.

We have an excellent package manager since that year, which allows you to install, well, packages, in a very safe way, with locked versions and everything. That has opened the door for a lot of interesting developments. Some packages have been really, become very important.

It has taken a different route, than, for instance, the javascript package manager stuff, where it’s really small packages, and it just functions here and there.

But with PHP, you always get these very powerful packages and frameworks as well. I think they have taken a lot of inspiration from other languages that have come a very long way, to develop very good frameworks.

They picked some of the good stuff from these frameworks and these other languages, and put it into their own language, to the point that maybe you could say that, PHP, being the flexible language, and everything is possible, you can easily make mistakes.

But the tools are still very powerful right now. There is really no need to be defending the language choice anymore today. Just, of course, steer away from maybe the bad parts; I don’t think there are any dangerous parts at this moment. Back then, maybe? But now, everything is covered for you.

Len: Thank you very much for sharing that really great explanation, and for hinting at the controversies that can sometimes surround what type of language are you coding in. Just like in any profession, there are trends, things that are popular and things that are unpopular, and things where - people can get very emotional about styles of handwriting, if you’re in a certain world. Just imagine how much more heated it might get if a typo made a program break, or something that.

Matthias: Exactly.

Len: People can get very, very sensitive about things that.

On that note, let’s maybe move on to talk a little bit more specifically about what legacy code is. You write a lot about legacy code. What is legacy code?

Matthias: Different definitions are out there. We could talk about code that has no tests. This is Michael Feather’s definition. People might say that yesterday’s code is legacy code, in a sense that, well, we may not [use] it as much yesterday as we did when we wrote it, and was all great.

Now when we look at it again, it’s like, “Yeah, not that great anymore.” So we feel we want to improve it. And, if you multiply this, then you have - also look back longer than a day or a week or a month. Then you end up with just a big project, thousands of lines of code that are not up to your current standards.

And, what to do with that? Can you improve it somehow? Or should you re-write it entirely? Basically, throw it away and make something new. That’s really, really difficult. It’s a difficult question to answer, anyway.

I’ve been part of several projects that were just rewriting entire projects, and they were successful with that. Somewhere, it was just what it was, and this is just a reality, we have to deal with the mess. We can do little things, but not that much. Because it’s very easy to make it unstable.

Len: One definition is, “It’s just old code.” I think another definition is, “code someone else wrote.”

Matthias: Exactly.

Len: It’s funny, but sometimes that someone else can be you, from five years ago. You’re like, “I have no idea what I was thinking.”

Matthias: That’s right, yeah.

Len: There’s this decision that people can often make. One can maybe think about it from the perspective of, let’s say you’re an MBA manager. You don’t know the first thing about coding, but you understand everything else about the business. You’re sitting on top of something that’s starting to break down, that isn’t working anymore. You may be even having a difficult time recruiting, because the new programmers, they ask what they’d be working on, and they go, “Oh my God, I don’t want to work on that.”

So you’re this manager, you’ve got a budget, you’ve got things that are working. You realize at some point, “Look, just to stay where we are, in terms of functionality, we’re actually going to have to do a lot of work.” That can mean re-writing, which you mentioned. One can think of that as being just what it sounds like, starting over, basically.

Matthias: Yeah.

Len: Or you can refactor. I was wondering if you could talk a little bit about what refactoring is?

Matthias: That’s another definition. I think it’s Martin Fowler? We want to improve the structure of the code, without changing its behavior. Because structure is - indeed, it’s about mess, the code being a mess. If “This should be cleaned up,” yeah.

But we don’t want to break existing features, because people are relying on it, for it to work this. So, we can just clean up, preserving existing behavior.

That’s already a very hard thing to do, because the system may have behaviors that we don’t know about as developers. So, we make this change here to clean it up, and then we break something for a particular user that was relying on this feature to work in a particular way.

Len: That brings with it all kinds of decisions that - we’ve used the word “architecture” a couple of times already. But you can come in and go, “Okay, what are we going to do to maintain the functionality, but maybe change the architecture of the code?”

Can you give us maybe an example of what that would be? Maybe if you can think of an example of this thing in practice? Where it’s like, “I’m going to try and keep the functionality, but I’m going to make some structural changes to the code.” What would an example of that be?

Matthias: This is related to the topic of my latest book as well, trying to decouple from things that are dangerous to couple to.

If you pick a framework or a particular library that does something useful for you, but you get too intimate with it, you are using it, maybe too many parts that it offers? Even though it’s nice today, in a couple of years it’s outdated, and you no longer want that.

So, one way is to say, “I can use this framework in this part of the code base. But in this other part, I’m not letting it happen.” So there, we focus on code where we can design it in any way we like, but, it’s not coupled to a particular tool. So that’s one example.

Len: This is very interesting, actually. So, so moving onto your latest book, Recipes for Decoupling. Let me see if I can try and explain this.

Let’s say you’re developing a website. Let’s say it’s a calendar. It’s going to be a cool calendar thing that helps people deal with time zones and stuff that.

One thing this website might do that you’re building, or this app, for example, that people might be able to install on their phone or something that, is send emails. If your code that you write is using a specific email service, that’s an example of coupling, right?

Matthias: Right, yeah.

Len: Right. So if, for example, that email service that you rely on changes, because it’s got programmers working on it, it’s got things that it depends on, and stuff like that. If it changes, then all of a sudden, you might wake up one morning, and all your users are jumping up and down going, “I’m not getting my emails any more”.

Matthias: Exactly. Yeah.

Len: If you haven’t taken into account in the way you coded it, for example, if there’s something specific in your code that’s unique to the thing that you were using, then you’re screwed.

But if you coded your own thing at a level of abstraction appropriately with decoupling, right, then you could just switch to another service?

Matthias: Right. Ideally, yes. One example is that, if you send emails in ten different places in your code base, and you have this, well, a ten or twenty-line thing that you could copy all the time, every time you would want to send an email. That’s a very clear example of, well, something badly designed.

Because, indeed, if you have to do something about that email sending part, where you need to configure it in a different way, because the service changed, or it needs to go to a different web address or something - then, you have to change it in all these places.

So, of course the first step is to find a single place in the code where we can do that. Then, maybe the next part is that, if this happens, if we have to switch very quickly, we can do that. Without changing the entire code base.

Len: I gather it’s also a very important principle for testing as well? Which is something we haven’t spoken about yet. But there’s something called “test-driven development,” which Chris Hartjes has written about, who you mentioned earlier, The Grumpy Programmer.

Let’s talk a little bit about test-driven development in a moment. But, one thing you can do when you’re coding an application, is writing automated tests in there.

So that on your computer, you can just run the program, and you can test something, and you can say run the program, and then these automated tests can happen. They can flash red lights at you basically, saying, “Uh, oh, this is broken.”

But what you don’t want is, for example, with this example you were using - you don’t want to actually send a real email in order to test, right?

Matthias: Yeah.

Len: So you’d have some abstraction. This is an email. Then you’d have something set up that goes, “Oh, I can check to see that the category of email activity is working properly.”

Matthias: That’s right. But I mean, everything is related always with these topics. Because, legacy code, code that somebody else wrote 0 what is usually bad about it, is that that person knew how it was supposed to work. They probably didn’t specify that. So they just wrote the code, and clicked on something in the browser. It happened, and there were like, “Okay, this works, so it can be released.”

But years later, you want to go back and still see, what was the purpose of this code? Because you want to, again, clean it up.

For this, you can also use a test, o specify, what is the expected behavior? What you’d really like is that, back then, this person would have written the test for you, instead of you having to figure it out, and maybe write some tests after the fact.

Len: This is actually a really interesting example of how these different software principles can be interconnected, right? For example, you can imagine - so, software coding is writing, it’s a bunch of instructions that are written down, basically. If you’re going to be examining some code, you open up a text editor, and you look at some letters and numbers and spaces and newlines, and things that. You’re like, “Huh, what’s this?”

One way of doing it is to have no explanations of anything that’s going on whatsoever, and just have someone have to figure out, “Oh, I know this programming language. Let me see. Oh I see what this is.” I would look around, and I can see what this little thing I’m looking at is doing.

Another thing you could do is, have the code, the instructions, that are to send an email. You can write above them, “The following code was written in order to send emails,” right? So now if someone comes in new to the project, they can go, “Oh okay I know this is the part where it’s sending the email.” All of a sudden, this can make it a lot easier.

Another thing you can do, is actually write a test there, an automated test. The test that you write is itself a way of saying, “This next part of the code is trying to send an email,” Or, “The former part of the code is trying to send an email.” So, writing tests is a way of documenting, at the same time, about what a section of code is trying to do.

Matthias: Exactly, yeah.

Len: And that all sounds great. Well, why doesn’t everybody write these awesome tests every time they’re coding, or why don’t they just write out, “This next part of the code is to send an email?”

The reason is that keystrokes take time, basically. They can take your focus away, for example. If you’ve built up a stack in your head of sequences of steps, stepping out of it to explain what you just did, actually can break the mental house of cards.

Matthias: That’s right, yeah.

Len: So if, let’s say, for example, to break it down into an example you might face. Let’s say you’re brought in as a consultant to a team, and they’re like, “We’re thinking of moving to this test-driven development thing, where, as we develop our code, we write tests every step along the way. But our manager doesn’t want us to do that, because then he doesn’t hit the milestones that he is expecting to hit.” What do you do to convince the manager that they should switch to test-driven development?

Matthias: If I knew the trick, then yeah - it’s hard to say. If you talk about this, there are so many aspects to it.

One is the thing that you mentioned. You don’t want to send actual emails when you’re testing the email functionality. Because, that would maybe cost you money, even, or it would be very slow. And, well, where do you even send the emails to? All these questions. So you find something else to replace that, and to make it a bit faster, a bit more deterministic as well.

But if you don’t write tests, if you never write any tests, then you don’t have that feedback from the code. This is badly-designed code, because it’s hard to test. If it’s hard to test code, then you are very likely not going to do any testing any more.

Because it’s an amazing amount of work, if you want to test untestable code. It takes just a lot of time to extract parts that are testable, and then replace them with something, those replacement objects that can do the thing in the testing scenario for you.

But starting anywhere, what would work for me, is that, if a team wants to pick up an issue, the first question should always be, “How are we going to test this?” In some cases, indeed, it might end up with a quick discussion and, well, a simple answer: “We cannot test this. It would just be too hard.” But, okay, at least we defined the criteria for testing, in the issued description itself.

So we say, “How can we test this?” Or, “How can someone else verify that this works?” “Okay, go there. Click on this. And, okay, that should work.”

But very often there are more options. You don’t have to just rely on manual verification. You can actually write an automated test, even if it’s hard at first.

This is another approach that I do for legacy programing, is the Mikado Method. We always look for the simplest thing possible that we can do today to improve the situation a bit. Then, for every new issue that we pick up, we at least improve one part of it, and make our lives a bit easier. In the end, this results in much more tests, and we feel it’s easier to write tests. When it becomes easier, we are also going to do it more often.

Len: I’m looking at a blog post of yours here, on moving forward with legacy code and the Mikado Method.

Just to give people a bit of a sense, again of the training that you would do - what is the Mikado Method?

Matthias: Oh okay, also you say “MICK-ARD-OH.” I wasn’t aware. In the Netherlands, we say “MICK-AH-DOH.” So it’s,

Len: Oh well, don’t go by my pronunciation of anything.

Matthias: No, I was just interested. It’s a game. I don’t know if you have the game as well? Where you have the sticks and you drop them on the table, and you have to pick each stick one by one. Make sure that none of the other sticks move. I don’t know if that’s something?

Len: Oh that is something, but I forget the name. It’s definitely something, yeah.

Matthias: The stick game, maybe? But anyway, so this is an approach that I do. Imagine there is this big goal. For instance, we want to migrate to a different framework. Which is just a lot of work. So how can we do that?

Well, Mikado is, we do the first thing that we could try, a very big thing. Sometimes even, we just install the next framework. Then we realize it’s not going to work, because we don’t have the right language version. It should be PHP 8 if we want to use that framework. We are on 5. So, okay, there’s a lot of work there. We write it down as a pre-requisite, wo we know that before we can ever install the framework, we first have to upgrade the language. That’s something that may take some time.

And, the next time we can, we have some time to pick up, work on this issue, we do that. We just switch to a different language. We notice that, well, there are all kinds of errors that suddenly pop up. We write down all of those errors. One by one, we recognize that these are pre-requisites. If we ever want to migrate to a new version, we need to fix those errors first. Because we can already anticipate the language switch.

So, all the way down to the smallest thing that you can do to improve the situation. Finally, the switch to the framework. It’s just, commit maybe just a few lines of code, and there you go, it’s done.

But for every step in the process, you end up with a better code base anyway. Your situation is much better today, and you don’t have to wait until it’s finally done and you can do this big merge into the main branch and deploy. Because that’s a very dangerous thing, then, if you have this big bang release, you’re never sure if everything is going to work on that day.

Len: Your fingers get very sweaty when you press “enter” on that.

Matthias: Right.

Len: Or you click a button. Thanks very much for sharing that. That’s super interesting.

Actually, I wanted to move onto the next part of the interview, where we talk about your new, your latest book, specifically.

In Recipes For Decoupling, you talk about something called, “phpstan.” I was wondering if you could just tell us about what that is, and its history, and how you use it in your book?

Matthias: Well, phpstan stands for “PHP Static Analysis.” It’s a tool that you can run on your PHP code. It looks at the code, it doesn’t run the code. But it will say that, “Yeah, you’re calling a method that requires a string, but you pass an integer to it,” for instance. Just very low-level things, where it can already predict that something will go wrong when you do this. That’s very useful, because usually there is so much code in your project, you make a change, you don’t often realize all the areas that it may have an impact on. This tool can scan your entire code base and look for potential errors.

Len: How does that work? It’s not the program itself, so how can it know that something might be an error?

Matthias: It really tries to understand your code. The first step is loading each file, and then parsing it, recognizing the structure. For this, it builds on top of another library, called “PHP parser”, so it can understand the building blocks. So, this is a class, and in this class we find a number of functions. Every function has a number of arguments with their types. And, phpstan just goes by them, for each of these blocks, and interprets them.

Also, it figures out, what are the types of things that are happening here? Is it indeed a string type value, or an integer type? It really does a lot of interpretation. By doing so, it’s becoming really smart. Every day it’s becoming more smart, to the point that it’s not just possible to analyze code, but it’s even possible to modify code. That’s where Rector, another tool, builds on top of the static analysis part. It is able to transform code into different structures.

Len: I’ve got a question about that in just a moment. The book, I believe, is marked as 20% done? I just wanted to ask, who’s this book for? Who is the ideal reader for this book?

Matthias: Very good question, yeah. So it’s anyone who has experience with frameworks. I guess that many, many developers have this experience. Mostly with web MVC frameworks. So there are more than just the ones that I know, of course. There are more than just PHP frameworks.

Len: Model View Controller, right?

Matthias: Right, exactly, yeah. Most web applications have this structure, where they are trying to serve a browser request and answer with a response. All the work that happens in-between, is something that you can write some code for. But the framework tries to do a lot of things for you. To save you some time, usually.

I also know that many developers have experienced some issues with that. So, they realize that they are becoming too dependent on parts of those frameworks, and then it becomes really hard to change anything at some point.

Sometimes framework authors, they come with a new version. Developers have to catch up with those changes. You have this entire migration guide, and you have to follow that. That’s going to be just a lot of work. So, over the years, I’ve collected some things that I do, basically patterns or recipes that I apply to my code, to make sure that I’m not tightly coupled to these frameworks. This book is a collection of those, the things that I do.

Len: You mentioned that phpstan can even modify code. So, just before we move onto the final part of the interview, where we talk about your work as an author, do you think that code is going to be writing code in the future, and programmers are going to become obsolete? Just to put it in the funniest way. There’s a very serious debate out there, about, basically, are the AI’s going to be able to write code?

Matthias: I’m not really sure. But before we continue, just to get back to the phpstan part. The phpstan only analyzes the code, and Rector can actually change it.

Len: Oh.

Matthias: So it’s different too. But it builds on top. Not just -

Len: No, no, that’s an important distinction.

Matthias: Right, exactly. Yeah. But I mean, these are all possible because of each other. The tools, they amplify each other. But about writing code, and I think, Rector can show us a bit about that.

If you want to migrate to, as an example, a different framework, or a different style of programming, you can just do that. You can say, “I want this approach to programming.” Run Rector, and everything now follows the new standard. So that’s very cool.

I don’t know about AIs. I don’t have any experience with that. Although, there are some tools already available. But I feel there is still a lot of work in interpreting what is needed here. We need to talk and have lots of sessions, understanding what are the needs of the users, and how does this business concept work? So, I’m not really sure how fast that that may happen. Although I believe that, of course, this might become closer one day. I don’t know?

Len: Oh thanks, I know that was a very broad, open question. I was just selfishly taking the opportunity, to see if I could get an opinion out of you.

Just moving on then to the last part of the interview, where you talk about your work as an author. You’ve followed a very interesting arc, the arc we love to see on Leanpub, where maybe Leanpub is the first place that someone publishes a book. Then, maybe they publish another one? But then maybe they publish a book or books with some more conventional publishers?

And then, maybe they come back to Leanpub. You started out self-publishing. But then you did work with Apress and with Manning as well.

Matthias: Yeah.

Len: I was just wondering if you could compare and contrast the experience of being an entirely independent self-published author, versus working with a company that’s going to have development editors and stuff that.

Matthias: Right, exactly.

Len: What are the main compares and contrasts that you can come up with?

Matthias: Right. I think these are totally different things. I always hope that it’s clear, also for the readers, that there are different standards.

For Manning, for instance, I really enjoyed working with them. They had some very high-quality reviews going on. People really involved in the process as well. They knew what was happening with the book, and what it was about. That’s just great to be able to talk about the book with someone who is really knowledgeable on the topic. They have many people. You can just ask, “Can you review this?” They have people for that. It’s great. Everybody will just join and have very valuable feedback.

What was very useful for me was the broad range of feedback from them, looking from different languages, different experience levels. Also, learning what they had in mind for, what is a good technical book? They really spent a lot of time communicating that, which was very interesting.

And, I’ve learned a lot. Back in the beginning when I started with Leanpub, making my own book there, there wasn’t even a technical review going on for some time. Sometime later, a couple of books later, I asked some people to provide a review, because it really adds to the quality. But mostly, it really is different that way.

With the published book, say with Manning, it’s really a finished thing, it’s done. It has to be really good before it’s going out. With Leanpub, I still feel that I can change things and improve things, and just do a re-release. That’s one of the great things. Because with Manning, I was constantly annoyed, for instance, that I could not make a change, and would just propagate to the released version. That would be very helpful. I recognize something, or I change my mind about something and I want to change it, and there you go. With Leanpub, of course, that’s possible. So, I guess for the reader, it also must be a different experience. Where they get a book, and it’s maybe not even done, or never done?

Len: It’s so fascinating to think about it from both sides of the, well, I guess all three sides, right? There’s the authors, there’s the publishers, and there’s the readers, right? So from the readers - this has actually reminded me of what I took to be a hilarious profile of the CEO of Ford in the New York Times that I read recently. Where, basically, Tesla just did laps around the legacy auto industry in a number of different ways, right? One of them was the overnight software update. You can just imagine heads exploding - I mean, I’m going to be very patronizing about this. You can imagine heads exploding around a boardroom, where it’s like, “What, the computer guys are beating us at cars now?” Even after all these years and all these pressures and the humiliation of seeing Tesla work ten times as much, and some of these companies almost collapsing after 2007, the beginning of the great recession there, and stuff like that.

I’ll get to the point. This article was celebrating the CEO and the release of the F150 Lightning, their new electric truck. But even at this moment, he couldn’t help but get a jibe in at the damn computer nerds. He said, “This thing about these software updates, it really took us a lot of cultural change to get used to putting out a product that wasn’t perfect. Because in automotive engineering, we don’t put out things that need to be fixed,” right?

So, first of all, to characterize a software update as “just a fix of a problem.” He’s got to know that that’s just not true, right?

But what Tesla was doing, was also introducing new features - this is what would’ve blown their minds - for free. Because the whole legacy automotive industry is just, “Put out the new thing, but with a new gizmo attached, and say it’s the 2010 model. You need to buy that.”

The idea, also, that conventional automotive engineers would’ve never released a product with any deficiencies - it’s just absolutely ludicrous.

I bring this all up, because there is this interesting cultural gear-grinding between self-publishing and publishers. Where like, you can imagine a development editor at a conventional publishing business. All the people there saying like, “What’s with this whole Leanpub-type process? Where it’s like, you just put something out there, and change it later if there’s a problem. That’s just not serious.”

Matthias: Can’t be good, no.

Len: I totally get it, it’s a totally different way of doing things. But the other side of it is, bugs or mistakes do come through. Or, for example, one of the reasons Leanpub exists is because, if you publish a book the conventional way on an evolving technology, that technology, between the six months when you submit your final manuscript, and the book finally comes out, something in that underlying technology might’ve changed. Your book might be obsolete before it comes out.

There are these very important reasons to do things the way that conventional publishers do a lot of things. But there are also just things that that process misses, and can’t accommodate.

Len: oOe of the things it can’t accommodate, is a programmer who’s written a book, who’s accustomed to be being able to change and deploy things when they find problems, or when they want to add something. Then they’re told, “No you can’t.” That can just be very frustrating.

Matthias: Exactly. Yeah. So it’s right that Leanpub really does something here for this part. And, it’s also, I think what programmers often call “agility.” We can change directions very quickly. If it feels like we’re not doing something right here, we can abandon the entire idea sometimes even. Say, “Okay, we are going to write a different book.” Or, “I allow myself to write a different book than I started out with.”

And, well, it happened a lot of times, also with this book. In fact, I was like, “Okay, it has to be recipes.” I always start with this design statement, to say, “It should be a 150-page book. Simple, short sections. Just quick advice basically. Not too much explanations going on.”

Because, with the architecture book, it was almost a never-ending thing. Much more had to be said and written. It could never be released, in a sense; well, it is released, but, okay, it took a lot of time.

This time, I want to be a bit faster, a bit more lean as well. To get the things out there, and make sure that we don’t lose time with that. Sometimes it feels, in particular with phpstan and Rector, which are, I think, still quite new tools, that we shouldn’t wait that long until they are fully stable, or something. Although they are quite stable. But we don’t have to wait until everybody already uses it. So, I also want to push for the new things, and be sure that everybody knows about it. I wanted to be fast, in a way. So this is the right place to do that thing.

Len: That’s really interesting. That’s another reason that Leanpub exists, and one of the reasons it is the way it is, is that - we don’t really get this question like we used to - but someone might ask, “Why would I want to read a book that’s only 20% complete?” It’s like, “Well, because it’s about a new technology. And knowing 20% more than zero about it is good.”

Matthias: Very valuable, yeah.

Len: Just on that note, when we were talking before we started recording, you mentioned you’ve actually built your own tools for writing in Leanpub.

Matthias: Yeah.

Len: And you mentioned, just now, how you go around with your design principle for the book, and summaries and outlines, and stuff that. What’s the tool or tools that you’ve built to help with your book writing?

Matthias: Several things, in fact. One thing that I used to be very bothered with, or concerned about, is that a book is outdated very quickly. With the Symfony book, I had to say, like, “I’m not going to update it. It’s going to use Symfony 3, but that’s it.” They are at s6 now. So in a sense, it’s wasteful that, well the book has been written, and it has been useful for some people, but it no longer is.

So, for any new book that I’m writing, I want it to be upgradeable itself. This means that, I have to define all the dependencies that I need, any frameworks, including their versions or libraries, or the language versions themselves. When I want to migrate the book to a new language version or a new framework version, that should be a very simple thing to do. I can just change the version and regenerate the book, basically. And see if anything breaks.

That was another thing that I wanted, is that all the code samples should be working code. It’s just very easy to just write a snippet of code, and reviewers would try the code, and find out if it doesn’t work.

That no longer is necessary. The book basically verifies its own correctness. That is, I think, a very good addition, for making sure that the book is valuable, not just this year, but also in the next few years.

Eventually of course, the main manuscript itself could be outdated, because it gives wrong advice, or says things that no longer make sense, because the world changes, or something. But in the end, I think books can be more maintainable in the long run this.

Len: This is the reason we leave this for the end of the interview, and there actually are some people who skip to the end, just to hear this stuff. But it’s very in the weeds. So, does that mean that the code samples in your latest books are all in unique text files?

Matthias: Exactly, yeah.

Len: Right.

Matthias: In fact, I usually write every example in different stages. So, we start with version zero, which is just the way it would normally be written, if it would maybe be in a normal project. It would follow framework documentation.

Then, version one is a slightly improved version. Version two is - so - we iterate until I’m happy. And, sometimes, I show what I would test, and then gradually add more tests as well, so the book is actually test-driven, developed in a test-driven way. Then, every version is it’s own sub-project, installed with all of its own dependencies, and just some tests that show that the example is correct.

Len: It’s super interesting. For anyone who’s interested maybe in writing their first Leanpub book and it’s a programming book, the way this would work, is that, what you would think of as the normal book content, the paragraphs, right? This will be in say, in a text file. You write your paragraphs.

Then, after a paragraph, you might want to insert a code sample. One feature Leanpub has, is you don’t have to write it in that same text file. You can point to another file that has the code in it, because we’ve got that feature, Matthias has come up with this interesting way of - since you’ve got these separate, individual files that just have unique bits of code in them, you can actually then run tests on those files, separately from analyzing the book content text.

Matthias: Exactly. You can decide if the test should also be in the code or in the manuscript. Or, if you want to keep them out of sight. But just for your own, checking correctness of the code sample, that could work as well.

Len: That’s really fascinating.

Matthias: Yeah. Another thing that I added, is that, you want to show different versions. But for the next version, you will want to maybe exclude the part of the code that you have already explained something about. So you want to have slash, slash, dot, dot, dot, as comments. To say like, “Okay, I’m leaving this out here.”

I created something for that as well. So you can say in the manuscript, which part should be included from the script, that you want to show. But also, inside the code itself, you can say, “Skip from here, and show the code from here again.” So it’s jump in and out of the code.

That has proven really useful. Because usually if you leave out things from a code sample, it becomes incorrect. Now, it stays correct, but it doesn’t show up on the book page itself.

Len: That’s super fascinating. We always like to say, “We have the best customers.” Because so many of our authors are programmers. By “best,” I mean, they let us be a little bit lazier than we otherwise might be, or give us really good indications of things we can do, because they’re creators of the technology, not just of the books content themselves.

Matthias: Right. But I’m very, very thankful as well. Because with Markua, this is possible. There is a lot of the, I don’t know how it goes with Markua, by the way. It’s something you support?

Len: Well no, so Markua, so for those listening, yeah. So for anyone listening, so there’s this thing called Markdown, which is a way of writing web content, without having to type out all the “https blah, blah, blah”. It basically was shorthand formatting instructions that you would type in a plain text file, instead of having to type all the formatting instructions out.

So, my co-founder Peter created this thing called “Markua,” which is basically Markdown, but for books. The idea is that you can specify all of the different formatting instructions that you might need to type into a plain text file, to have a book, a properly-formatted book come out of it.

Markua is fully specified, but it is not fully implemented on Leanpub yet. We’re hoping to have it - I mean we’ve been saying this for literally years - but we’re hoping to have it fully implemented sometime soon.

But it is fully specified. It’s just beavering away, trying to get it all fully implemented. If you create a Leanpub book, it’s automatically in Markua 0.10 version right now. But hopefully we’re going to get to version 0.30, which will be, when it’s done, that’ll be the first example of the full implementation of it, where you’ll be able to do basically everything you can imagine you want to be able to do if you’re producing a book. You can write those instructions in plain text, and then Leanpub’s book generators will know what to do.

Matthias: Exactly. It’s always this discussion about, should we have yet another language to do this, right? Because there are alternatives, of course. But so far, I think, Markua is quite close to Markdown. Markdown is very familiar for most developers, I think. So it’s just a very easy thing to get into. Yet, you get all these extra things that are related to book writing.

Len: That’s really interesting. I mean, given the fact that you’ve been around for so long on Leanpub, you’ll know what I mean. But it was a bet that Peter Armstrong, my co-founder took on Markdown, right? Because there are lots of different ways of doing the same thing, for everything, right?

And it’s interesting, because programmers, of course, are familiar with Markdown, and stuff like that. But more and more people nowadays, who aren’t programmers per se, are actually getting used to writing in Markdown, partly because, if you’re getting into things like data science or something like that, these kinds of things can become more familiar. Also, writing in plain text is something that people are becoming more familiar with as well. As opposed to in Word, or something that. Of course, yeah there are other options. But ours is the best.

Matthias: Exactly.

Len: With that being said, I would venture to say that it is the best, and it’s partly the best because, I mean, if you can imagine, being able to interact with authors you, with your level of dedication and experience and technical sophistication over the course of ten years, you’re going to have a different product than you would with a different form of evolution.

But with that said, the last question we always ask on the podcast now, if the guest is a Leanpub author, is, if there was one terribly awful broken thing with Leanpub that frustrates you to no end, that we could fix for you, or if there was one magical feature we could build for you, can you think of anything you would ask us to do?

Matthias: Ah, that’s funny, yeah. Well, it has been fixed, I think. It was the problem where, for technical books, you always have these mono fonts or, I don’t know what the right word is, but code samples in the text, in a paragraph. It wouldn’t break onto the next line, or, there was some word wrapping issue there. Because it’s really hard to say where to wrap or break the word. But, last time I checked, it was really great. It was just breaking them, those words as well.

Len: Oh are you talking about how things would spill over into the margin?

Matthias: Right, yeah. I don’t know what the word for that is. But, this would happen a lot of times, where the margin would just contain a bit of code. It’s like, “Okay, that’s not -“

Len: Yeah. I don’t know the technical details, but we did, putting it in quotes, “finally” fix that a while ago.

Matthias: Yeah.

Len: So it’s much, much more rare now than it used to be. But our authors patiently lived with us for quite some time, before we solved that problem.

Matthias: It’s very cool. I mean, I always try to use all of the power features. I also have a command line too, where I can say, “publish a new version,” or “give me a preview of the book.”

Len: Oh, you’re using our API.

Matthias: Exactly.

Len: We have an API for people who don’t want to have to go onto some boring website like leanpub.com and click buttons.

Matthias: Right.

Len: Instead, you can just generate previews from your computer.

Well, Matthias, thank you very much for taking the time out of your day to talk to me. And, again, so many years later. Thanks very much for sticking around with us all this time.

Matthias: Thank you for offering this awesome platform.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you what you heard, please rate and review it wherever you found it, and if you’d to be a Leanpub author, please visit our website at leanpub.com.