#79 - Domain-Driven Design With Functional Programming - Scott Wlaschin

[00:01:27] Episode Introduction

Henry Suryawirawan: Hello again to all of you, my friends and listeners. Welcome to a new episode of the Tech Lead Journal podcast. I’m your host, Henry Suryawirawan. Thank you for tuning in listening to this episode. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your favorite podcast app and social media on LinkedIn, Twitter and Instagram. And if you are a regular listener and enjoy listening to the episodes, subscribe as a patron at techleadjournal.dev/patron, and support my journey to continue producing great Tech Lead Journal episodes every week.

Many of us may think that implementing Domain-Driven Design means using object oriented programming and paradigms, especially when looking at some of the DDD tactical design patterns. And some of us, especially the functional programming practitioners, may wonder whether functional programming can also be used to implement Domain-Driven Design, and if so, how we can do that properly. This episode tries to provide you some answers to that particular question.

My guest for today’s episode is Scott Wlaschin. He’s the author of “Domain Modeling Made Functional” and the popular F# site fsharpforfunandprofit.com. In this episode, Scott began by sharing his view of the need for developers today to become more polyglot developers and learn multiple programming languages. As someone who learns a lot of programming languages and even being really good at five to six different languages, Scott provided some great insights on why we should try to at least learn and practice more than one language. Scott then shared about functional programming fundamentals and how functional programming differs from object oriented programming, as well as sharing some cases when one is better suited than the other.

Scott then explained how we can use functional programming when implementing Domain-Driven Design, including how to model some of the DDD tactical designs and transaction boundary. Throughout the conversation, Scott shared why F# has become his favorite and go-to programming language, and why he thinks it may be better from the other available functional programming languages. Towards the end of our conversation, Scott touch on important advice about effectiveness versus efficiency, and what leaders need to be aware of regarding doing the right thing vs doing the thing fast.

I really enjoyed my conversation with Scott, learning about functional programming, how to apply it in Domain-Driven Design and a good reminder about the importance of effectiveness rather than efficiency. And I wasn’t really aware that F# is actually now available outside of Windows platform. If you also enjoy and find this episode useful, please share it with someone you know, either your friends or your colleagues, who would also benefit from listening to this episode. Also leave a rating and review on your podcast app or share about this episode on your social media platform. It is my ultimate mission to make this podcast and the knowledge available to more people, and you can play a part towards fulfilling my mission. Before we continue to the episode, let’s hear some words from our sponsor.

[00:05:35] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m very excited to have someone with me. His name is Scott Wlaschin, and he is actually the famous author of the book, “Domain Modeling Made Functional”. So if you’re into Domain-Driven Design and also into the functional programming, I’m sure maybe you have heard about this book. He’s also the creator of popular F# website called FsharpForFunAndProfit.com. The name itself sounds really fun. So Scott, really looking forward to have you in the show today and looking forward also to learn more about functional programming, and maybe also Domain-Driven Design at the same time.

Scott Wlaschin: Well, thanks. Thanks for having me, Henry. It’s nice to be here.

[00:06:16] Episode Introduction

Henry Suryawirawan: So Scott, maybe in the beginning, I’d like to always ask my guests to introduce themselves, and also to tell us more about your highlights or turning points in your career.

Scott Wlaschin: So I’m quite old. I’ve been around since the dinosaurs. So I first started programming back in the 1980s. That’s how old I am. That’s when everything was still in black and white. The very first computer I ever used was actually a CP/M machine, before DOS even. It was a Kaypro, and it had two floppy disks and no hard drive. Very exciting. But you know, it’s amazing what you can actually learn, given how nowadays we consider these machines really old. But you can learn a lot. I mean, I learned all my programming on this machine. And the first program I actually used was dBASE II, which was the Microsoft Access of its day or the FoxPro of its day. It was like everybody used it for doing database programming. It had a programming language or scripting language built in. So I started programming database, and I actually ended up writing some really quite complicated things and it all fit on one floppy disk or two floppy disks.

And then, of course, this is pre-internet. I used to be a big subscriber of all those computer magazines, like Byte magazine, Dr. Dobb’s Journal, and my favorite one is actually called Computer Language, which is all about computer languages. You get introduced to all these interesting things that you wouldn’t know about. So I learnt Prologue, and I learned Smalltalk, and I learned a language called Icon, which is sort of a predecessor of Python. I played around with all these. You could basically get floppy disks with all these programming languages on it. In a funny sort of way, because there wasn’t any standard language, really. People would experiment. There’s a lot of experimenting. People try all sorts of stuff. And I think nowadays, people actually do less experimentation. There’s so much to learn. You could spend your whole career just doing JavaScript or Java or C#. So you’d end up not experimenting with all these different other things. So it was actually great for me because I learned all these interesting things.

So I actually got a job doing Smalltalk programming back in the early nineties. This is pre Java. So Smalltalk was actually used by banks and insurance companies and these big corporate businesses. They thought the Smalltalk was going to be the enterprise language. So for a couple of years, it was. And then the internet came along and Java came along and Smalltalk basically died. So then I switched to using Python. I did Python programming for a while, and then I switched to C#. When .NET came out 2001 or in 2002, I started using C#. Then about 2010, I started using F#. And so F#, I’ve really loved ever since. That’s been my kind of main programming language ever since. Although I still do a bit of C# and I still do Python, and if I have a contract that’s going to pay me a lot of money, then I’ll use whichever language they’re paying me to use. I would say back in the early days, there’s a lot of creativity around learning programming languages.

The other big thing I did, and this is what I would recommend to everybody, is, again, back about 10 years ago, I started doing my blog, F# for Fun and Profit. And I did that, originally, as a way of teaching myself F#. The idea is I would try to explain it to somebody else. You know, it’s this classic thing if you tried to explain it to somebody else, it forces you to learn it really well. It’s something I already knew, and so I thought I’d do that, and every weekend I would write a blog post about something in F#. And it turned out a lot of people found it really useful, not just me. And so it turned out to be really quite a popular blog. It still is quite popular blog, and so that’s nice. I would recommend anyone if you’re looking for career advice, is to do blogging or something to make you sort of stand out from the crowd. Having a blog or being an expert in something, doing conferences, these are all good career moves, as well as being fun. I really enjoyed writing the blog, and it was very good for my career as well. Right now, I’m just doing a mixture of writing books and doing contracts with people. And that’s how I make my living.

Henry Suryawirawan: Thanks for sharing your story. It seems a long time ago, even I wasn’t born that time.

Scott Wlaschin: It’s a long time ago.

Henry Suryawirawan: Yeah. It’s really interesting to hear that last time there was not even a hard disk. And you mentioned that you have learned so many different languages, right? So maybe if you can count 10, 20 languages?

Scott Wlaschin: I would probably say there’s five or six languages today I’m extremely good at including SQL. I did also act as a SQL DBA for a while. So I’m pretty understanding of how SQL and relation databases work, which I also think is a useful skill for any developer. Yeah, I would say there’s probably five or six languages I’m very competent at, and a couple of other ones I could probably do if I have to. I’m not really a JavaScript expert, but I can hack it if necessary.

First, I don’t identify myself by a language. You know, some people say I’m a Java developer, or I’m a C# developer. I think of myself as a developer. I’ve solved problems. The language that you used to solve the problem is not that important. I mean, it does actually make a difference. Different languages do make a difference in how you think about the problem. But I’m not particularly bothered by having a language debate about which is the best language, and all that stuff. It’s just kind of trivial, really.

[00:11:01] Polyglot Developer

Henry Suryawirawan: One of the topics these days that is very hot, right? Whether you should be a polyglot developer or not? So coming from your background, learning so many different languages and even expert five to six different languages that you say you can be really good at. Why do you think a developer should think about being a polyglot developer?

Scott Wlaschin: I think first of all, there’s a couple of different reasons. The first one is that the more different languages you know, it basically makes your toolkit bigger. So if you think about, if you’re a carpenter. You have a hammer, but you also have a screwdriver, and you also have a wrench, and you also have a drill, and you have all these different tools, and you use the right tool for the job. If a carpenter only ever used a hammer, and never used a screwdriver, would be a very bad carpenter. And so it’s the same thing with programming. I think different programming languages are different tools, and they have different ways of working with the tool. So if you use SQL, it’s a completely different way of thinking than if you’re using an imperative language like C# or something. It basically changes the way you think about programming. So it expands your mind. So from a personal point of view, it’s very good.

And then, just from a practical point of view, the more languages you know, the more job opportunities you have. That’s another thing. But also when you do work on a job as a contractor, you can just walk onto a job and you’re not going to be complaining that you don’t like the syntax, or you don’t like the style, or you don’t like them doing this way. Some programmers like to rewrite everything using the best way. When I come into a job, what I call a brownfield project where the code’s already written, like a legacy project, leave the code, use the same style that the people that are already using, within reason. Obviously, if it’s horrible, you can refactor it. But basically, don’t try and impose your perfect style on existing code. Just adapt to the style that’s already there. If you’ve done many different languages, you tend to be much more open to that. If you’ve had limited experience, you tend to be much more picky and you say, “Well, it has to be this way. This is the only way I know, and this is the way it has to be.” That’s not very good. As a professional, I don’t think you should work that way.

Henry Suryawirawan: Yeah. A lot of cases these days, especially developers who just came into a project, maybe they started a new career, a new company, or they’re consultant. They joined a project. So yeah, definitely one of the most common remarks made by those new joiners, of course, the code base is probably not so well done. We should refactor this. We should rewrite. And I think you brought a good point that if you have so many different paradigms, and you are familiar with them, and maybe also good at it, maybe you can adapt yourself to different code bases, right?

Scott Wlaschin: That’s right. A good example is I just did a Python contract. I’m very experienced in functional programming. I’m also very experienced in object oriented programming. But for Python, I think the right thing is just basically a classic kind of procedural programming. And so, when I was writing this code, I didn’t use a lot of weird functional stuff. I didn’t use monads and all this stuff. And I didn’t use super nested class hierarchies with lots of inheritance. Because I think Python has a certain style of working. I have seen people do JavaScript or Python and they bring in monads or they bring in some weird functional stuff. That’s not fair to the person that’s going to have to maintain it. I would say that’s not being a professional programmer. You have to think about other people. It’s not all about what you want to do. It’s what makes life easier for other people. I would never use advanced functional programming techniques in a project where people didn’t care about that stuff. That’s not the right way to do it.

Henry Suryawirawan: Yep. And also I saw one of the most popular tweets that you did. You mentioned that by being a polyglot developer, you start treating syntax as it is. It stops being a big deal that you don’t being nitpick about certain writings.

Scott Wlaschin: Yeah. A classic example is curly braces. So F# doesn’t have curly braces. Python doesn’t have curly braces. SQL doesn’t have curly braces. A lot of programming languages do not have curly braces, and yet, I have seen some developers say, well, if it doesn’t have a curly brace, I can’t understand it. And I just think that’s silly. That’s just very limiting. The curly brace does not make a big difference, and the syntax of which, what the keywords are and stuff. That’s not the important thing. It’s about expressing yourself. So, anyone who says that kind of thing, I just think they need to get out more. They need to try more different languages and learn a bit. Get out of that bubble and try some more things.

[00:14:59] Functional Programming

Henry Suryawirawan: So let’s move to the main topic of today, which is about your book, “Domain Modeling Made Functional”. These days, a lot of craze about Domain-Driven Design. Functional programming as well. A lot of people swear by it. That’s like the ultimate programming language. I, myself, come from more object-oriented programming background. So maybe in the first place, right? Maybe if you can share with us, what is functional programming? Why people should maybe try to understand it? And why is it probably much better in some aspects to OOP?

Scott Wlaschin: So first of all, there’s no official definition of functional programming. My definition is, it’s a programming style where you use functions to do everything. In object-oriented programming, the basic unit is a class. And in functional programing, the basic unit is a function. In functional programming, if you want to change the behavior of something like the strategy pattern, you pass in a function. If you want to compose a bigger set of functionality, you combine two functions together. Basically, everything you do is functions. You take these functions and you chain them together, typically, into some sort of pipeline. You might even have a function where the input is a function, and the output is a function. And so you might call that a function transformer. So you basically have some kind of function, and it doesn’t do what you want, so you run it through this function transformer, and it turns into a different kind of function, which does do what you want. So it’s just a different way of thinking about how you build software.

Another part of functional programming is also immutability. It’s typically the default behavior. Because in a classic mathematical function, things don’t change. Like when you say two plus two, the number two doesn’t change when you add something to it. You’ve got a new number back. You don’t change the original numbers. And the same thing with dates. When you add a time to a date, you don’t modify the original date. So if you apply that logic to everything, then nothing changes and you always create new things. It makes understanding the program a lot easier because you always know that the things that you’ve worked on haven’t been touched and you’ve always got new things to work on. So the combination of work using functions everywhere and having immutability, it’s a very hard thing to get your head around. When you first start learning functional programming, it’s really, it’s weird. I mean, when I first start learning F#, I was thinking, how can you write any code when everything’s immutable? That’s just not possible. And then yeah, actually turns out you can and turns out it’s not too hard. And then, how can you do things without using classes? How can you write program without using classes and methods? Well, it turns out you can. So it’s definitely another way of expanding your mind.

So why use functional programming now? Like you said, I love object-oriented programming. As I said, I used to do a lot of Smalltalk. And I love Smalltalk. But I think for modern enterprise programming, especially functional programming, because of this immutability and because the composition, there’s no inheritance. And so, everything tends to be very explicit. Every parameter is passed in explicitly. With class-based programming, there’s a lot of implicit code. I mean, you could have a method with no parameters. It returns void and has no parameters. Behind the scenes, it’s doing things because it’s using instance variables or something. But you can’t really see what it’s doing. And that’s the whole point of object-oriented programming. The whole point of object-oriented is encapsulation. You’re supposed to hide out its working. But I think functional programming is the opposite. The idea is everything’s transparent. Everything is exposed. There’s no hidden data. And you might think, well, that’s a bad thing. There’s no hidden data, but again, if everything’s immutable, exposing it tends not to be that bad because you can’t change it. Obviously, things like API is a different thing. In general, when you’re coding, if everything’s immutable, it doesn’t really matter if people can see the internals of an object because they can’t change it.

Henry Suryawirawan: And one aspect of immutability that I understand as well, right? So if everywhere is immutable, it also supports for concurrency really well. So you don’t have side effects and you don’t have to worry about multiple processes accessing the same instance.

Scott Wlaschin: Yes, exactly. Although I have to say it’s a little bit overblown. I mean, that was one of the things they hyped up about functional programming, is it did concurrency really well. It did processing really well, which it does. But even if it didn’t, I don’t think that’s the main reason to use it. I think the main reason is because the programs that you write with functional program, I think they just tend to be a lot clearer and easier to understand. Sometimes with objects, you tend to get what I called object soup, where an object is talking to another object, which is talking to another object, which is talking to the first object. All these objects are talking to each other and it’s really hard to disentangle them. If you’d ever debug something like that, it’s really painful. There’s nothing in object oriented programming that stops you doing that. There’s no pressure. It’s always easy just to add another method.

Functional programming, somehow it doesn’t quite do that because the pressure is to keep things simple. When every single parameter is passed in, it’s really hard to have a hundred parameters. There’s a natural pressure to keep things simple and make small components that are glued together. So, forget about concurrency and stuff. I just think functional program is a really nice technique. That’s not the only technique. One of the things I like about F# is it actually has an object-oriented component as well. So, you can actually choose whichever is the best paradigm. Sometimes object-oriented is actually the right paradigm for certain things. And so it’s nice to be able to have a language which supports both and you can just switch between them. But typically, would call myself a functional first programmer, which is I start by doing functional. And if that doesn’t work properly, or it doesn’t feel right, then I switched to object-oriented.

[00:19:56] Case for OOP

Henry Suryawirawan: When do you see this as the tipping point when you started as a functional first? But then what made you switch to the OOP paradigm? What do you think are some of the good problems worth to solve by OOP?

Scott Wlaschin: Well, if you’re really talking about behavior, if you really do want to encapsulate, if I have a bunch of things, and I don’t care about the data. I only care about the behavior, then that’s what OOP is really good for. If you think about agent-based systems, agents are basically OOP, just very similar model. Especially if you’re doing a user interface or something, object-oriented interface is a nice thing because, you know, the button class, and the list box class, and I think they all have basically the same behavior. You want to click on them. So the object-oriented programming is great for that. Graphical programming objects are great. For agent-based programming, they’re good. Sometimes I say where you have a kind of a plugin model, and you don’t actually care how it’s implemented. So it’s useful in those cases. I do mix and match between the same piece of code. And sometimes, you really do want it. Sometimes, it’s really nice to have inheritance, occasionally, not massive deep inheritance trees. But it’s sometimes nice to have a base class with a couple of subclasses that inherit from it. Sometimes it’s just nice to have that.

[00:21:02] DDD and FP

Henry Suryawirawan: So in Domain Driven Design, most of the literature that I read, actually, they use the OOP as maybe the sample reference. You came out with the book, “Domain Modeling Made Functional”, which is kind of unique in a sense. So what made you think that the domain modeling can also be solved by functional programming paradigm?

Scott Wlaschin: So this is very interesting because you’re quite right that Domain-Driven Design is not attached to any particular programming paradigm. It really shouldn’t be. Domain-Driven Design, the idea is that you focus on the domain instead of the technology. So you try and focus, use the words from the domain. You try and model the domain in the code, and you try not to contaminate your domain with all sorts of technical stuff which is not relevant to people. So they’ve got nothing to do with which programming paradigm you use.

But one of the nice things about functional programming is, because in object-oriented programming, it’s very easy to have a lot of extra complexity, or what people call ceremony, extra stuff like subclasses and all this stuff. And it’s quite easy to end up with code which has a lot of stuff in it, which isn’t really part of the domain. So you have a base class. Where in the real world, you don’t have base classes. You don’t have proxy classes. You don’t have manager classes. You don’t have interfaces. The real-world objects do not have that. In functional programming, it tends to be a lot simpler because functional programming doesn’t have classes. So none of that stuff happens. It basically has data, and it has actions on the data.

I think also a lot of people when they do domain modeling, they focus on the data side of things. And you often have database-driven design, where you start with the database tables, and then you work back from there. I think what’s happened is people have realized and what businesses care about, analyzing a real system, it’s the events, it’s the actions, it’s the workflows, the activities. These are the things that are actually important and the data is just a way of transferring stuff. But it’s the activities you want to model. An activity you could model is something with an input. You send me this letter and I do this action. You send me an email or you create this event and I do something. A function is exactly that. It’s an input and output. So, functions are actually very good for domain modeling.

Now there’s another thing which applies to certain functional programming languages, namely these statically typed ones. So not things like Clojure, but things like F#, or Camel, Elm. They have a type system which is very different from an object-oriented type system. In the functional programming type system, this is called an algebraic type system or a composable type system. You can actually build bigger types from smaller types in a couple of different ways. But one of the ways you can do it is you can do it as a choice. So you could say this thing as a choice between this thing or this other thing. Think of it kind of like an enum, a glorified enum. I mean, most object-oriented languages do not have this. It turns out this choice modeling is super important for most domains. If I say, I’ll send you an email or I will send you a letter. That’s a choice. I want to model that choice, and it’s actually surprisingly hard in object-oriented language. I mean, you can have two different subclasses, but it’s kind of painful. In a functional language with an algebraic type system, it’s actually really easy. So a lot of my book is actually talking about modeling things with a type system. Just modeling things as choices, and then as record types, which is very common, and then these functions with inputs and outputs. So I think it’s a very good match for a functional programming.

[00:24:10] Modeling Tactical Design in FP

Henry Suryawirawan: One aspect of the Domain-Driven Design is actually what they call tactical design. So these are things like design patterns, commonly used in DDD. Things like entity, aggregate, value objects, service, repository, and there are so many others. And normally, they kind of like being modeled as OOP. That was also the paradigm that stick with my head. So when you implement those kinds of tactical design in functional programming, maybe you can give some examples, how can you really design entity class or an aggregate class in FP?

Scott Wlaschin: So a lot of those things, I think, do apply only, they’re very object-oriented. This low level Domain-Driven Design things like entities and aggregates. Value objects in DDD is an object where if you have a different object with the same data in it, it’s the same thing. So if you have two address data structures, and they have exactly the same address data in them, they’re the same address. And what’s interesting, in functional programming, that’s the default. In object-oriented programming, that is not the default. In object-oriented programming, every object has a different reference. So if you want to make two things equal, you have to override the equals method and the get hashcode method and all this other stuff. And in functional programming languages, that’s the exact opposite. So that’s nice. And then in object-oriented programming, entities are considered to be mutable objects. In functional programming, they’re not mutable, obviously. So really, they’re just objects where there’s an ID. They have some sort of ID fields so that as you change them, they have the same identity. I don’t like having all this jargon. I think it takes away from making people understand these things, but you can totally do these same things.

Things like the concept of service, which provides a service. That’s not special to any particular programming language. One thing I should point out, though, is this repository pattern, which is used in Domain-Driven Design. It’s actually used outside of Domain-Driven Design. People almost never use that in functional programming. So it’s very common in object-oriented programming to mix up database access and code and business object. You might have an object that saves itself. You might have a save method on an object, which saves itself to the database. That’s a very common style. It’s used in C# with Entity framework and with Python, with Django and so on.

In functional programming, that would’ve been considered an anti-pattern. That would be considered a really bad thing to do. Because in functional programming, we tend to separate predictable stuff from unpredictable stuff, a deterministic code from non-deterministic code. What we call pure function is a function that always gives the same result. With the same input, it always gives the same result. So, adding two numbers together always gives the same result. Now, reading something from a database is not like that. If I read from the database again, I might get a completely different set of data. So in a functional programming, we hate that. We hate having unpredictable data.

So what we tend to do in functional programming is separate anything to do with databases or file system or network. We try and move it outside the core business logic. So we have this core business logic in the middle, and anything to do with the outside world is on the edges of the application. Take a little example. You might load up some data from the database, and then you do all this business logic, and then you save some data back to the database at the end. So the database stuff is on the outside and then the core business logic is in the middle. So it’s completely opposite from the classic N-tier architecture where you have the database layer at the bottom. In the functional programming, the database is on the outside, not on the inside.

This is not necessarily a functional programming thing. People have been talking about this in other architectures. There’s the ports and adapters architecture. There is the onion architecture, the clean architecture, the hexagonal architecture. All these things are to try and keep the domain logic in the middle, and keep the rest of the world on the outside. There’s another way of saying which is an imperative shell and a functional core that’s taught by Gary Bernhardt on that topic. So, what’s interesting is in object-oriented, people have to be encouraged to do this. But in functional programming, it happens automatically. It’s the default behavior. So you don’t really have to try and persuade people to do it. It’s because this is really the only way of doing it.

So I think one of the reasons, going back to why I think functional programming is quite nice, is that there are some languages where you can do something, but it doesn’t really encourage you to do the right thing. The language can let you get away with all sorts of terrible things. So, for example, let’s talk about C. So C, you can be very cautious with your memory management and your bounds checking stuff. But the language doesn’t work. It doesn’t really encourage you to do bounds checking. There’s nothing in it which forces you to do it. So it’s very easy to make mistakes. So I like a language where you’re really kind of forced to do the right thing. So a language which is immutable, and doesn’t let you do database stuff. It kind of forces you to keep the database stuff separate from the core business logic. And so that’s what I like about functional languages. They really encourage you to write code in a certain way. Nothing that you can’t do in object-oriented language, but somehow, it just seems easier when you’re using functional style. I don’t know why that is.

[00:28:49] Modeling Transaction

Henry Suryawirawan: So people who have wrapped their head around this paradigm, I think it makes it intuitive. Another aspect that I want to ask is because it seems very interesting topic in Domain-Driven Design is the concept of transactional boundary. In DDD, they advocate aggregate to be the scope of the transaction. So how do you actually do this in FP with, just now when you mentioned, predictable versus unpredictable, where is that layer for the transaction part?

Scott Wlaschin: Well, let me just talk about two boundaries that there are in Domain-Driven Design. The first boundary is what they call a bounded context. The idea of a bounded context is you break your program into subsystems. But each subsystem does one thing well. It’s kind of like a giant object. Everything in this subsystem uses the same terminology, works in the same way. Again, it sounds really obvious, but it’s very easy to write systems. I have seen lots of big systems where everything’s kind of tangled together, and you have pieces of codes that they all interact in a big mess, big ball of muds. And so, that’s the first thing is to have these bounded contexts. And then, within a bounded context, you want to guarantee that certain constraints or integrity are met. So if you have an order or something, you want to make sure that the price you’re charging is the sum of the prices of the items. And you want to make sure that an email address always has an @ sign or something. There’s various rules about things.

You can just enforce that with a function. And again, if you have an input and output, you can just say, well, the only way you can change this thing is through this one function. I think it’s just because it’s very common with a mutable object because you can mutate any of the fields. It’s very easy to mutate one field and then forget to mutate one of the other fields. And that might be wrong. There might be some sort of constraint that, if you do this thing, this other thing also has to happen. So if you have immutable data, you can’t have that problem. If you can’t mutate values, then once it’s correct, then it can never, ever change. A very simple example, if I have an email object. When I create this email object, I validate that it has an @ sign or whatever. Once I’ve created it, it’s immutable. I never ever have to check it ever again cause nobody can mess it up. So I don’t ever have to worry about re-validating it or double checking it or so on. Because it’s immutable, it can never, ever be changed. So it actually ends up with a lot less defensive programming. If you have immutable data, you typically validate things at the very beginning, at the edges of your program. And then once you’re inside your program, you basically trust that it’s all valid because it can’t possibly be changed.

So that even applies to bigger things. If you have a thing where if you change this field, this other field has to change at the same time. In an object-oriented thing where there’re two separate fields, that would be hard to enforce. But if the only way to change it is through this special function, and the function changes both things at the same time and spits out a new one, which is valid. And if the things aren’t correct, it returns nothing. You’ve always got a valid piece of data. So a lot of these things about integrity, constraints and stuff, it’s really easy to do. It’s not even that big a deal. It’s not something you have to make an extra effort to work on because that’s just the kind of way it works naturally.

Again, this is whether the programming paradigm encourages you to write stuff in a certain way. Okay, in object-oriented program, you can have a class where you can only set things in the constructor and none of the fields are mutable. And if you want to change any of the fields, you have to create a user factory method or something which validates everything. You can totally write code that way in OO as well. But it just kind of feels, it’s hard. It’s like you’re going against the way the language works. The language doesn’t make it easy for you to do that. It’s not specific to functional programming. But I do think it’s the way that functional programmers think about these problems maps very nicely onto this kind of issue.

[00:32:22] F#

Henry Suryawirawan: In the book, you chose F# as the main language to express your thoughts. You also create your website F# for fun and profit. Maybe you can tell us why F#? Why people should use F# instead of Clojure and all the other functional programming?

Scott Wlaschin: Well, I think F# is a very nice multi paradigm language. And again, it depends on the environment you’re working on. But I’m talking about a typical business applications or enterprise stuff. First of all, I would say, it’s nice to have a statically typed language. I mean, if you’re working by yourself, that’s fine. But I think statically typed languages are definitely the way to go if you have a team of people. So that eliminates Clojure and so on. And then, in terms of the statically typed functional languages, you have Haskell, you have OCaml, you have Elm, you have F#.

What I like about F# is it’s on a big platform. It’s on the .NET platform. For people who don’t know, .NET actually runs on Linux really well. It’s no longer a Windows only thing. And because it’s only on .NET, any kind of thing you want to interface with, there’s a .NET API for it probably, or .NET library, and you can just plug that into F# and go. So you don’t have to write your own libraries all the time. So just in terms of productivity, I just think it’s my favorite language for being productive. It’s also got extremely good tooling.

Most of the functional languages do not have as good tooling. The object-oriented languages don’t have much better tooling in general. But I would say, of the functional languages, F# probably has the best tooling in terms of refactoring, and on the editor hints and so on. There’s a very nice plugin for VS Code called Ionide. Visual Studio supports F# out of the box and JetBrains Rider supports F# out of the box. So it’s just a very nice experience. A language like Haskell is a very, very powerful language, but it really does hurt your brain. Because it’s so strict about immutability and strict about doing I/O. So if you want to learn functional programming, that’s actually a very good language to learn, because it will force you to learn this stuff. But in terms of actually being productive, I think F# is a little bit easier to be productive in.

One of the problems with languages like Haskell is some people like to get really advanced in some of the stuff they do. And Haskell sort of encourages that. A lot of people like to write weird kind of stuff in Haskell. It makes it very hard for other people to come along and maintain it because it’s just crazy. So, you can’t get too weird in F#, and some people think, well, that’s bad, but I think that’s nice. You can’t go overboard with advanced stuff. You can never get too much that way. So again, it’s very practical, very pragmatic language that way.

[00:34:43] Effective Instead of Efficient

Henry Suryawirawan: So looking at the other thing that you are big about, you mentioned about productivity just now. You mentioned that programmers need to be more effective versus being more efficient. So I think this topic is a big thing in productivity world, right? So effective versus efficient. Maybe you can give us your thought as well. What do you mean by programmers should be aspiring to be more effective versus efficient?

Scott Wlaschin: So efficient is doing something better. Like an LED light bulb is more efficient than an incandescent light bulb. It uses less power and blah, blah. Doing a task with less energy and with less money. That’s being efficient. But we do tend to focus on efficiency instead of effectiveness. Now effectiveness is doing the right thing. So it’s not about how efficiently you do it. It’s about are you even doing the right thing in the first place.

A good example is if you have someone in a really fast car, like a Ferrari, and you have someone else in a bicycle. The Ferrari is faster. But if you go in the wrong direction, the bicycle is better. If you’re trying to get to the right place, a bicycle might be better. So I see a lot of people in programming, we talk about velocities. When we’re talking about sprints and velocity and story points and all this stuff, we’re talking about how fast can we do things? And can we tick off features fast and all the stuff? And there’s nothing wrong with that. I mean, it is good to improve your processes to make them faster and more efficient is good. But sometimes people lose track of what’s even more important is doing the right thing in the first place. I’ve had a bad experience where I spent a long time building a product. We had a really good team. We had really expert programmers. We had really good processes. It’s very Agile, all this stuff. But after we finished building the product, nobody wanted it. It was a failure. Because we didn’t actually build what people wanted. We were so obsessed with our own efficiency. We didn’t actually talk to anybody. We didn’t actually talk to the end users.

Ever since then, I’ve been very concerned about doing user experience testing, getting feedback from the customer, getting feedback from other programmers. Thinking about other people and listening to other people, not just doing what you’re thinking. Again, techie people tend to be very concerned about technology. That there is a technology solution for every problem. Sometimes it isn’t a technology problem, it’s a people problem. And so, you have to improve your people skills, your listening skills, and like I said, trying to understand what is the right thing to do, not just how fast you do it.

I had a tweet, a funny tweet about this a few weeks ago, which is there’s a famous detective series in America, in the 1990s called “Murder She Wrote”. It was set in this very small town in America. Every episode, some person would get murdered. This woman, she was really good at being a detective. Every week she solved the murder. And so, she was very efficient at solving murders. So she solved hundreds and hundreds of murders. But that’s being a very efficient. But really, if you want to be effective, you should be saying, why are there so many murders in this small town? And why don’t you stop these murders from happening in the first place? That would be effective, not just being efficient. It’s very hard.

The thing about effectiveness is there’s no metrics for it. Effectiveness is very hard to judge. It’s a judgment call. Are you doing the right thing? We sometimes do the same thing. We focus on solving the problems quickly, rather than actually trying to figure out what’s the point of solving this problem if it’s not even the right problem to solve. There’s a social component, which is, if you are seen as a very efficient person, you get a lot of credit. If you solve all these murders, you are considered a great detective and everyone thinks you’re fantastic. If you stop the murders from happening in the first place, nobody cares. Because it never even happened, and therefore people don’t think you’re doing anything. So unfortunately, we don’t get rewarded for being effective. We only get rewarded for being efficient. So that’s something just to be aware of. If you’re ever in a management position, don’t just award people for being efficient and productive. Reward people for doing the right thing.

[00:38:31] Advice on Valuing Effectiveness

Henry Suryawirawan: So, yeah, I was about to say that people probably don’t associate high performance with effectiveness, unless the management has actually already realized about this. So they tend to see people who can work as many tasks as possible within a short amount of period of time. Or probably the person is just busy all the time, but always gets things done. But the people who tend to maybe perceived as lazy, but they are actually doing the right thing. They solve the problem at the root cause, probably tend to be less visible, unless they can mention about the impact and all that. So what do you think will be your advice to managers or leaders to always have this mindset to be looking at the effectiveness versus the efficiency?

Scott Wlaschin: That is a tough one. The problem is, it’s very hard. It is hard to measure. And now we’re not even in the realm of technology. The person I would recommend is a guy called Peter Drucker. He wrote books on management theory back in the 1950s and 1960s. He is the person who actually came up with this idea of the difference between effectiveness and efficiency. It’s not an easy thing to do. It’s so easy to get sucked into the whole efficiency thing.

One way is to listen to the outside world. So again, rather than working on something, and thinking that you know the right way to do it, listen to users, listen to the feedback from people and change direction. If you’re going in the wrong direction, you want to know as soon as possible. So I guess would be having feedback loops, as many feedback loops as possible so that you can change direction if you realize that people aren’t happy with what you’re doing.

Henry Suryawirawan: And it comes back again to the direction versus speed. You mentioned at the beginning, if you have a Ferrari, but if you go to the wrong direction, it’s even worse.

Scott Wlaschin: Exactly. Exactly. Yeah. And unfortunately, I’ve seen a lot of tech companies do exactly. They build a product that nobody wants. It’s nothing to do with the quality of the team. It’s just literally, you’re building the wrong thing and you haven’t actually listened to your customers. So, it’s sad.

Henry Suryawirawan: Another aspect this day, I mean, social media, I know that people also want to crave instant gratification or instant achievements. But sometimes, you also need to think about are you going into the right direction with that speed? Or actually something that matters to you? So that’s a food for thought for everyone here.

[00:40:30] 3 Tech Lead Wisdom

Henry Suryawirawan: So Scott, it’s been a pleasant conversation learning about functional programming. I, myself, get intrigued by all these niceties about functional programming, and maybe I’ll give it a try as well in my day-to-day job. But before we wrap up our conversation. I always like to ask my guest to share three technical leadership wisdom. So this is something like a message you want to share to the audience here for them to actually also reflect and maybe learn from your experience. So would you be able to share your three technical leadership wisdom with us?

Scott Wlaschin: Yeah. So the first thing I would say is to read more about non-technical things. In particular, a lot of the stuff I’ve learned has come from reading about architecture, or reading about systems thinking, or reading about other engineering books, like mechanical engineering or something. It gives you insight into your problems. Again, getting out of your bubble and getting feedback. One of my favorite books is “The Design of Everyday Things” by Don Norman. Another of my favorite books is “How Buildings Learn”, by Stewart Brand. Really excellent books and they’re not about programming at all. But you can see, they really do apply to programming.

Another piece of leadership wisdom is literally, what we were just talking about is to be careful about focusing only on efficiency, focusing on metrics. Make sure that you’re building the right thing. Another thing of getting out of the house, talking to people, listening to people, and don’t think that you know all the answers. Something which has been very useful to me in this area is actually reading about anthropology of all things. So anthropologists, their whole job is to listen to people and to learn things in a nonjudgmental way. Again, read some popular anthropology and I think it will help you be a better programmer, which is kind of interesting.

And the third one I would say is again, in the whole spirit of getting outside your bubble, is being a polyglot programmer and learning different paradigms. It’s just expanding your mind in any way possible. It’s so easy to focus on one thing and just do one thing all the time. The other reason for doing that is to stop burnout. I did have a big problem with burnout and I think other people have problems with burnout. And one way to stop burnout is to have fun. Fun is really important. It’s not all about work. And so, do things that are fun for you. And if that’s learning a new programming language, or expanding your horizons in other areas, I just think that’s a really important part. It’s the whole thing. It’s not just about your job. It’s about your whole life. So that’s my last bit of wisdom for you.

Henry Suryawirawan: Thanks for plugging in the burnout message. I think, yeah, many people probably also experienced burnout, with the insurmountable amount of work. Especially these days, internet technologies, everyone can reach everyone very easily.

So Scott, for people who want to continue the conversation with you, any place they can find you online?

Scott Wlaschin: I’m only pretty much on Twitter. I try to avoid social media. But I am on Twitter, and my Twitter handle is @ScottWlaschin. That’s another piece of advice. Stay off social media if you want to be productive. That’s actually a very good thing about effectiveness versus efficiency. They measure stuff by engagements. They want to get you angry. The more angry you get, the more clicks they get. I do think it’s very unhealthy to spend a lot of time on social media. I just don’t think it’s good. So yeah. Stay off social media and focus on the real world.

Henry Suryawirawan: Sure. Yeah. Thanks for that message. So, Scott, hope you enjoy this conversation. Thanks again for sharing your knowledge.

Scott Wlaschin: Thank you so much.

– End –