Pragmatic 25: Software Entropy

Welcome to Pragmatic. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is sponsored by Wetfrog Studios. Visit wetfrogstudios.com/pragmatic to get in touch and take advantage of a special offer for the app icon and logo design service exclusively for Pragmatic listeners. I'm Jon Chidjie and my guest host tonight, I've been a long fan of his work and his career in programming spans nearly two decades. He's worked for strategy first Ubisoft, Ubisoft, I'm sorry if I'm mispronouncing that, Rogamiba, and three years ago teamed up up with Chris Parrish to form Agent Distilled, released a Mac application called Napkin. He has an awesome podcast that I love called Debug and occasionally, apparently he also kicks bears for some reason, I don't understand. But anyway, so welcome to the show, Guy English. How are you doing? I'm very good. Thank you. So kicking bear, I'm sorry, really quickly. You don't actually kick bears though, do you? I try not to. It's probably a bad idea. Sorry, that's the name of the website. I apologize. But anyway, I guess I should, I sometimes cop questions for Tech Distortion, what the hell is that about? And that's fine. I mean, I have a story for Kicking Bars, just not a very good one. I'll, hey, I'll take it. Go for it. I had been reading an excellent book. So I was in anthropology at the time. And a book that I'd been reading was called Bury My Heart, It Wounded Me by a fellow called Dee Brown, is about the end of the Indian Wars, of the Native American decline in America, basically. And for whatever reason, I think I was trying to... At the same time, I was trying to get registered website, and Kickenberry, he was a Native American guy, interesting guy. And I just plugged his name into the DNS thing and I got it just because I thought it was cool. And you know, Crazy Horse was obviously taken by Neil Young. But I got kick in the bear. Nice. Fair enough. That's cool. It's a far more legitimate story than tech distortion, that's for sure. But anyway, that's okay. Cool. Well, thank you for that. Yes. Now I know. I don't think I've explained that publicly ever. No, I've listened to a lot of podcasts that you've done and I can't remember if you've actually explained that before. I don't think you have. So thank you for that. There you go. You're welcome. Always wondered. Okay, cool. So, before we get stuck into this episode, I just want to quickly cover a few new features that I've added to the website for those that don't read Tech Distortion. Real quickly, it's now possible if you use the player on Tech Distortion of the episodes, It's now possible for you to create a link at any time index that you're at, at the moment from the web player. And if you follow a link to an episode that has a time index and press the right arrow play button, then it will start playing from that position. It's not a new idea. It's just something that I've always wanted to implement on the web player. I think Pocket Casts actually does do that already, but they give you a unique generated link to a landing page on their server, whereas this is directly linked through, because I run Statomic and I'm using Jplayer, so this is using all off-the-shelf stuff. I wish there was an industry standard for it. I mean, there isn't. SoundCloud does it, but again, it's unique to their service. So I just wanted to do something that, you know, it's not hard. All I'm doing is I'm passing a query string with episode URL, you know, and time equals how many seconds from the beginning. It's not rocket science, it's just something that I wanted to have. So anyway, the other thing I've done is the feed switched over to MP3 for maximum compatibility. I was receiving multiple complaints about AAC format. There's a few devices out there, typically non-Apple devices that won't allow you to play at 2x and 3x. If you want to listen to 2x and 3x, go right ahead. I can't understand if I talk a bit slow, but I didn't think I talked that slow. But anyway, so it's all good. I'm trying to give people what they want. So there you go. I will be putting up a HE AAC version 2 encoded feed in the next few weeks for those of you that are bandwidth conscious. So I'll post that link and I'll let you know what that link is on a future show. So there you go that's happening. So anyway enough of that and on with the topic for today. And when I, one of the things that I'm doing differently since I'm out on my own is I've been asking my guests what they want to talk about and there's a list of topics and this week Guy has picked software entropy and I guess the thing with software entropy is that when I say that I realize that maybe different people have a different understanding of what I mean by entropy but I might I might start by asking you Guy what you think I actually mean when I say software entropy? So to me it's the sort of inevitable spaghettification of the code that eventually appears. Another aspect of it certainly for me has been a lot of the software I've written especially in games, has been in order to support other developers. So like a level designer will be using code. Effectively, it's like publishing APIs. And that requires you to maintain backwards compatibility far further back than you'd ever want to. It's like being a grown-up at that point. And that has, to me, has a lot of entropy in it too, because you're making decisions not based entirely upon what's best for the product at any one time, but what is likely to be best going forward and what suits the existing concerns that are already in the field. - Absolutely. No, that's a good point. I didn't actually consider that one. And I, but in essence, in a nutshell, yes, That's the idea, is that essentially entropy, when I was... Geez, I hate to say when I was growing up, it makes me sound like a dinosaur. Now, when I was a boy, anyway, seriously, they used to refer to entropy in physics as being order and disorder. The funny thing is that just doing a little bit of research for the episode these days, apparently it's sort of moved away from that concept of order and disorder. And when people describe entropy more recently, It's more about a measure of equilibrium, such that as activity increases in a system, that eventually it will reach an equilibrium by that energy being distributed within that isolated system. So that's all very fascinating and physically and light sort of thing. And for the physicists listening, there you go. And I'm sure I've actually made a meal of that, but still any cow. The point is that in software parlance, I guess what I mean is that the more effort and energy that you put into software development or on a specific product or section of code, it tends to become more disorganized, disordered. And the same is true, I think also of user interfaces. And so it's something that I wanna look at. I guess it's from those two angles. If you wanna read up more about entropy, there's a couple of good links in the show notes and feel free to knock yourself out there. So depending on your inclination, might actually knock you out. But anyhow, so user interface, I wanna start with that, I guess, because that's something that I think applies to the most people, and then we'll start talking about the backend of it. - Sure. - Okay, cool. So the way I see user interface is that for the majority of people or companies in the world, the major driver behind software development is end-user features. And yeah, that's when someone goes, "Yeah, well, duh." Yeah, obviously. if you don't add features or don't have features, then why would anyone buy your product? So yes, I guess that's kind of obvious. But the more features, the more when users are buying your software, they feel like they're getting more value for their money if you've got more features, generally speaking. And obviously, you know, there's other aspects like the complexity of what you've got. And if there's a specific feature that they really, really want, then they'll pay just for that. You know, other features be damned. But generally speaking, I like to think, well, that's sorry, I don't like to think I think that is my perception is that that people want to add more features so that people say, oh, well, I've got all these extra features and therefore you should get my product. So you compare something like pages to Word or you compare Pixelmator, which is a great product, by the way, to something like Photoshop. And, you know, there's a there's a there's a chasm in complexity and features, but people think all the serious people will get Photoshop, the serious people will use Word because it's got so many extra features, right. But I don't know if that's actually a sensible way to think. Because I don't actually think entirely that way. But I know a lot of people that do. So so I think a lot of that yes, there are more fully featured applications out there. And a lot of that is because they've been established for a long time and they've sort of built out this giant feature set. I think a lot of people buy, say, well, let's pick on Word in specific. I think people buy Word in order to be, in order to interoperate with other people. I think they get it because it's the de facto standard. I think they buy Word for the same reason that they used to just buy Windows machines all the time and it like well that's what Word has and that's what everybody has so that's what I'm going to get. I thought people only use Windows because they had no choice. That was my running theory but yeah absolutely I totally agree with you absolutely right. Well I think I think at work they had no choice and then at home they're just like well I'm going to get the same thing as work because that's. Yeah I've been trained at work now so. Yeah it just makes makes sense and and it makes for less hassle. And many, many people, computers are useful, or they have their uses, but they don't want any hassle from them. And I completely understand that. And while, sure, you could argue that the Mac itself is less hassle, if you need to interoperate with work, or you need to get your crazy Excel document and work on it at home for some reason and it's not 100% compatible on your Mac, then the Mac, despite being great in terms of its UI, internally, consistently for itself, becomes a hassle for you to interoperate. That's why you get a PC. And it's a compelling rational argument for basically the majority of people who don't want to dick around with their computers. That said, things changed with the web and OS X fixed a bunch of stuff We've seen a revolution in that more recently There's been less tie-in to specific applications on the Windows desktop So the tables have turned a little bit Absolutely. I guess I picked Word as an example I guess because it was a quick and easy example, but I agree with everything you just said. It's just it's sort of Office has maintained its dominance because of its momentum and people have been using it for so long for interoperability So I look I completely agree, but I do think that that interoperability thing can't last forever I think that it's only a matter of time before the competitors sort of chisel away at it It's already started, but it's not it's not there yet. So, you know office will continue to be a big income earner for Microsoft. But in any case, that's all cool. But just about user interfaces and adding more to them, I guess, because they've been around for a while, these products. I think that the issue is that once you've got a user of a product, then driving a user to upgrade becomes of paramount importance, because you get revenue when, as a software development company, you get revenue when people buy your product. If they buy your product and they use it for 20 years, well, I mean, okay, maybe 10 years is at most, so even that's probably a stretch on compatibility as your operating system, you know, changes and your hardware changes. You know, I guess there's still programs written in DOS that'll still run on Windows 8, I guess. (laughing) Yikes, I mean, yeah, and I guess actually, I can actually think of a few of those, which is scary. But anyhow, irrespective, my point is that you get nothing from those people after that first initial purchase. So what are you gonna do? them to upgrade and how do you entice them to upgrade? Well you've got to have more features. So this next version has all these extra features and functions and options so you should upgrade. And it got me thinking about, is it a fallacy in software that it's easier to get existing companies to upgrade than it is to entice new customers? Because there's conventional thinking and I looked and I looked and I looked and I can only find anecdotal, I can't even call them studies, but anecdotal discussions that say everything from three times to 30 times the cost of to get a new customer as opposed to retaining an existing customer. And I think, well, okay, does that work for software? Because in software, if you want to get your existing customers to upgrade, what do you do? Well, often you'll subsidize it. You'll say, okay, well, you get upgrade pricing, but there goes some of your profit. So, I don't know if the numbers really balance out or not? And it seems to be a heck of a lot of guesswork, but that seems to be the perception, you know? It's like the pervasive perception is I have to add more features, more, more, more, more in order to get my customers to upgrade. Have you seen that sort of effect? Well, so far with Napkin, all of our upgrades have been free. But in general, upgrades are still a big driver of revenue. One of the reasons is that you can... it's easier to talk to your existing customers than it is to capture new ones. I use the word capture in the most friendly way. I realize how cynical and disgusting that sounds. I had an image of someone running around with a butterfly net and going... Yeah, exactly. That's not quite what, but to capture their attention. Basically, you have the attention of your existing customers because they're using your app and you are in, effectively, you know, you have a relationship with them. You have a conversation with them. Striking up a new conversation or capturing the attention of new customers can be difficult. You know, you need to do marketing campaigns, which, you know, can be nice, can work, and can be good, but ultimately you're standing on the street corner yelling at somebody. In fact, you know, no matter how much marketing you're doing, especially these days, people recognize it like oh you're just marketing to me so yeah you lose a little bit of that human edge a little bit right other approaches can be I don't know like doing a show like this and talking about your your app or writing a blog like Gus Muehler does for Acorn or Daniel Jalkin or Ben Simmons with Vesper. Sure. You know, to get your... And I don't think they do it for this, but I think it helps. It sort of gets your name out there. Yeah, it's a side benefit. Yeah, it gets your name out there and people feel that they can trust you and then you can have a conversation with them about the software that you're selling. I do know from... I think he's been pretty public about it. Bill Shipley, the delicious library guy, says that upgrades are a large part of their revenue, especially going from one to two, and that makes a lot of sense. Now things may be a little different now that the App Store is kicking in, and it's kind of harder to measure because people have two revenue streams now. well a lot of people, they've got the classic direct sales revenue through their own store through which you can charge up good pricing, you can offer these incentives and you can communicate with existing customers. And then there's the app store where it's far harder to create a relationship with your customers because you don't have their, you know in the classic you had their email address and you had their name. Well, you assume it was their name. Well, sure. But yeah, I know exactly what you mean. There's no one standing between you and your end user. Right. So with the App Store, it could be interesting to see what the deal with new users versus upgrade users are. Okay. Yeah, I think we're going to see that over the next couple of years. years. Certainly we are at Aged and Distilled and we actually haven't decided what we're going to do yet. Certainly all upgrades to 1.0 are going to be free. When we hit 2.0 I honestly don't know what we're going to do. Okay well that's fair enough. It's one of those things that I'm sure you'll give it some more thought. But bottom line is that plenty of people, plenty of developers now have set the tone and said, I've put a substantial effort into this and I've had a rewrite here and there is no other mechanism for us to, you know, if we can keep giving you free upgrades as per the App Store model, or we can simply say, you know, new app, this is the Rev2, version two of the app and, you know, we're charging for it again because of the amount of work that went into it. And a lot of people I think are over, well I guess it'll always be outrage because it's the internet, but I think a lot of people accept that, especially if it's a good product. So it's the sort of thing that I think that's totally fair to do. Yeah, you are. So, yes. No, go ahead. Cool. Okay. Well, I just wanted to, so irrespective of whether or not it's anecdotal or whether or not there's evidence, it certainly sounds like there's more evidence that I could necessarily nailed down. But I guess the question is more of a postulate like, does it completely apply, does it not? Whether it does or not, and it sounds like it probably does, and that's fine, then that just creates more pressure to add more features. And this is the whole problem with, as I was talking about with the whole idea of the entropy, is that there's this pressure. You have to add more, you've got to give more to get people to do that upgrade, if that's a significant part of your revenue. Yes. Sorry? I said yes. Yes. Oh cool. Okay. Emphatically agreeing. Yeah. So and that's fine. That's where we're at. So okay. Then I got to thinking that the amount of screen real estate that we've got to play with as developers on the desktop just keeps growing. I mean I remember having a 12-inch CRT and thinking that was the most huge monitor in the world ever. And now I'm sitting in front of a 24-inch flat screen and I've had a 27 inch monitor and a 30 inch monitor in my chequered computer history. But generally screen real estate for users grows. And okay there's also the user interface leap from desktop to mobile where everything shrunk but now look at it it's now growing again. So, yeah. So, inevitably with time, space for new user interface elements increases, and it will increase, I think, not quick enough. It's like, I want to add more features, but the screens aren't growing big enough for me to fit all those extra features on there, because the cycle could be three years before I go up two inches in screen size. But my software could iterate four or five times between then and now, and I want to upgrade revenue, come on. So, you then started to have new paradigms to hold even more options. So it used to be, I've got a drop down menu, I've got a keyboard shortcut, you know, thumbs up, I'm done. OK, well, then we've now we've got toolbars and we've got the hovering the hovering toolkits and the context sensitive menus and ribbons and all these, you know what I mean? It's like it's like a layer upon layer upon layer of new interface paradigms to hold more and more and more options to the point at which we have some kind of control chaos. I totally agree, and entropy is exactly the right word to use for it, at least in the classic sense of going from order towards chaos. And again, I think your example of Microsoft Word is perfect for that. It's hard to argue that the, you know, I don't think anybody has hasn't yet seen that screenshot of like the words toolbar, which is just buttons everywhere that don't make any sense. And it's well-intentioned, right? Like it's trying to put functionality front and foremost that you may use. What it doesn't have though is a like an editorial sense. You need to be able to throw things out. And that's ultimately the entropy idea is that like you're saying as you add more features and you need to keep adding features if you're going to sell your product to existing customers. You're going to need to give them more value. And ultimately in software, value transfers into, most times, like a new feature. Something that they could do now that they couldn't do before. That has some kind of value for them. And how do you make them feel good about that? you stick the new button in their face. - That's it. Well, I mean, how else are they gonna know there's a new feature there? - Exactly. - It's all well and good to add a feature, but if it's not visible, well, no one will know, no one will care. - I totally agree. I think so for me, I think, I think the key is to focus on what the actual purpose of the product is. What's the actual value? So in the case of Napkin, the value is that you can quickly and concisely mark up images and share them. It's basically like a visual chat kind of enabler. So that focus helps us decide what features to put in and not to put in. But it also helps us focus on the actual value of the application. So if we do an update that's got a bunch, like 10 more buttons to do a bunch more stuff, that's not necessarily a win because it's distracting from the actual value of the application, which is to be quick. So I feel like if we had less buttons and it was easier and faster and you could get everything you wanted anyway, that would be a win. Now that's, that gets really really tricky though. - Oh sure, oh sure, none of this, when we sort of try and wrap this up towards the end, I've got a couple of ideas, and you've already hit on some of them, which is basically, it is all about focus, it's about understanding exactly what your product is trying to give people, rather than being, I'm an all-in-one box that can do anything you'll ever wanna do, which is what Microsoft Word and Microsoft Excel has become, and people even use Excel as a database, I mean, it's not a database, right? But they'll use Visual Basic scripts and all sorts of crazy stuff to turn it into a pseudo, I'm not really a database database. But I think the greatest two examples in terms of companies that suffer from this problem are Microsoft and Adobe. And I sort of called them out just before with Photoshop and with Word, but I actually looked at screenshots of Excel. You mentioned the screen dumps of Word. I actually looked at the screen dumps of Excel. I went back to Excel version 2.0 And again, link in the show notes. Have a look if you haven't seen it. Now you compare that, which was done in 1987 against Office 2013. And the number of options now versus them is just, it's astronomical. And like I said before, they've added the ribbon along the way. And honestly, I think the ribbon, I had a go at the ribbon on a previous episode, but I've sort of educated myself since then. So I thank the listener, I'm sorry, I don't have their name in front of me, that gave me the right link so I can do some research on that. It is actually kind of cool, but unfortunately it doesn't help the problem of having too many damn features. So the problem I got with keyboard shortcuts ultimately is that you run out of keys. So then you find yourself doing crazy finger combinations like, well, it's shift, control, option, command, V. Oh, right, what does that do? And it's like, oh yeah, that's split the document into shred one half, highlight the other in bold. It's like, come on. 'Cause it gets to that point, right? you just can't keep adding them. So anyway, I guess the bottom line is that all is not lost, right? Because this is all about companies and individuals that are developing software where that is their only source of revenue. If you have an alternative source of revenue, there is a different way of doing this. And, you know, I always bring up Apple. I don't know if that makes me a fan boy or not, but in any case, look at what Apple's done. And the examples I'm going to quote are Pages, Numbers, Keynote. And prior to that, as a few years prior to that, Final Cut Pro X. - Yeah. - Or 10, sorry. OS X, I don't want to go down that road again. So there was a massive furor when Apple took Final Cut Pro and they ditched multi-cam editing support and they ditched native external to tape editing. In fact, the multicam support was gone for seven months. And there was this, I picture in my mind a walkout, like quote unquote walkout, but I don't know if software programs actually got up from their chairs and walked away. Far more likely they just didn't upgrade and kept working. But the point is that there was a big pushback and Apple was sort of on the back foot. And after a while they responded and said, don't worry, we'll add it back. But what they did, oh, sorry, and with pages, that's the other one with pages, is they ditched mail merge. I didn't need mail merge until literally yesterday. My wife's having a party, right? And I said, "It's okay, darling, "I'll take care of all of the envelopes. "I can do a mail merge, I'll just open up pages." No, I can't. Because Apple took mail merge out of pages. I mean, okay, first time I've needed it in nine months. (laughing) It's not like I use it every day of the week. But what did I do? I went to Word. Sorry, Apple. But anyway, the point is that they took that out. It used to be in there. And when they went to Pages version five, the current version, so it's been nine months now that there's been no mail merge in Pages. So what did Apple do? Right, they hit reset. They said, you know what? Screw this. I'm going back to, we're gonna simplify the interface. We're gonna, based on my understanding, they've rewritten the code base or vast chunks of it. And now they're re-adding the features that they essentially removed very gradually, but they're doing it in a far more controlled way in a less bloated way. And I got to thinking, the only reason that they can do that is because they've got an alternative revenue stream. They're not reliant on sales of pages and Final Cut Pro to survive. So they can do that. If customers walk away and get angry on principle and say, "Oh, I'm not gonna use pages because I can't merge my mail anymore, then it doesn't matter because, you know, they're not dependent on that revenue. - Yeah. - Someone like Microsoft and Adobe can't do that. - Well, they have a harder time doing it for sure. That, yeah. - Yeah. - I totally agree. So, you know, the iWork team basically just moved over to iOS and they rewrote everything on iOS. And then this most recent one is them porting all of the iOS stuff back onto the Mac. So it's not really like they removed Mail Merge. - No, well-- - Well, they didn't make a choice to remove Mail Merge. Mail Merge was gone. Like from the product perspective, yes, they removed features. From the development perspective, no, they just hadn't got to adding them back in yet. Like Apple Script support was a big one. Everybody was up in arms that the new Mac stuff didn't support Apple Script and what that meant for the future of AppleScript. And really what that meant was that, the team just hadn't done it yet, 'cause it was pretty much a giant rewrite. But you're totally right in that, you need another revenue stream in order to pull a stunt like that. And the thing about those kind of resets, as frustrating as it is that you can't use your mail merge, Those are the kind of sort of let the field go fallow moments that you need in order to combat the software entropy that we're discussing. Exactly. They could have kept building on it, but they chose to hit the reset button. And that's very, very hard to do. It's a very hard choice if you're not making money off of iPhones, handphones. of a fist. Absolutely. It's a tough call but I guess the whole point of 101 I want to talk about this is we all agree it's like okay got to add features, got to get new customers, got to you know got to get that revenue in you know periodically you know year upon year or every two years depending on your development cycle but irrespective you need to do that right and here's Apple saying actually well no you don't because we have an alternative revenue stream so you know what we're going to do the quote-unquote right thing and we are going to distill this down to a key set of uh a key set of features just occurred to me agent distilled distilling does that have anything to do with is that was that just a coincidence sorry that's a sidetrack there but it just occurred to me is that one of the reasons why you named it agent distilled distilling ideas or is that just me yeah that's cool yeah i mean there is the there's the boozy aspect of it, but there's more than that. The idea is that we want to consider things carefully and we'll... That's the aged bit, is it? Yeah, it's the aged bit and the distilled bit is that we want to get to the root. I mean, the process of aged and distilling and a good scotch or whatever is similar to... focus on quality after careful consideration and time. Yeah. It's what we're trying to capture with that name. And yeah, this all of this is part of that. Yeah. Cool. Sorry. I just every now and then I get a thought that comes into my head and I'm like, I just got that. I'm not sure if everyone, okay, listeners, if you already understood why I called it Aged and Distilled, yeah, sorry about that. But I just figured that out. So there you go. Yeah. It's okay. I think what most people just probably think it's a janky thing, which, and you know, the logo's a barrel. So fair enough. And we're not, you know, I don't want to fetishize drinking or anything, but that we're not, we're not, we're cool with that association. Yeah, exactly. But no, but the real reason is because it's writing software, it's a process of refinement. - It sure is. - And the H2n Distilled to us sort of captures that process. Cool. Now I've had just one too many project managers that didn't get that about software and they're like is it ready to go out? Is it ready to go out? Is it ready to go out? Yes it's ready to go out. Good now you can go on a different project. Like whoa hang on a second. Yeah yeah we do we try not to be like that. Yeah no that's okay I just this is the problem is I've worked for too many big companies but anyway before we go on any further I just want to quickly talk about our sponsor Wet Frog Studios. So selling a business or an app is a lot like selling a house. You can take a huge amount of time and money by redecorating and bringing the house up to scratch and modernizing it. You can take great photos and build a website showing off that house but if there's one thing missing it can stop buyers from ever walking through that door, it's curb appeal. People say that you shouldn't judge a book by its cover but unfortunately human nature, frankly most of us do and some do the same thing with business logos, app icons and ebooks. So So without some kind of curb appeal, people won't usually take the time to look inside and check out all of your hard work and it can go unnoticed. Now you might have seen that on the show recently that we just got a fresh coat of paint and the new artwork is a result of working with Aaron over at Wet Frog Studios. I can't recommend him highly enough. There was an awesome icon for drafts the first few years, Aaron designed that. He also designed the branding for 512pixels.net, minimalmac.com and lots of other recognizable apps, businesses, and websites, including 70 Decibels. If you're looking to add some curb appeal, Aaron can help you. What I really enjoyed working with Aaron about was that he took the time to understand what I was looking for. And a few emails back and forth, and I had 85, 90% of where I needed to be, where I, what I wanted. He just intuitively knew exactly what I needed based on what I told him. And it was so quick compared to my other experiences that I've had previously with other designers. There's a special offer just for Pragmatic listeners. Aaron is offering his app icon and logo design service for $400. Now that's half the normal rate, and that's an amazing deal to get access to a professional of Aaron's caliber and experience. There's plenty of other graphic designers out there that can give you something good, but Aaron will take the time to give you something great. Visit wetfrogstudios.com/pragmatic, specifically that URL, to get in touch with Aaron and take advantage of this amazing deal while it lasts. Thank you once again to Wet Frog Studios for sponsoring Pragmatic. So that's, we've talked about the user interface. I think we need to move on to the guts, not entrails. Meaning, I guess, okay. So I'll talk a little bit about my line of work, which is a little bit different from yours. Predominantly the software that I write is more industrial automation. So, you know, we're controlling pumps and motors and all sorts of different physical devices, servo motors and so on. And while I'm at work, I'll start out with an object that is designed to control a specific pump, let's say. And the end user then says, after you get to site and the code's done and factory acceptance tested, then they'll say, "Oh, we're gonna add a leak detector "because we just realized that we ordered submersible pumps "and without a leak detector, it could all go bad, "blah, blah, blah, blah, blah." So then it's like, "Oh, great. "So now I've got to go and retrofit my block to add in an input for leak detection. Great. So you modify the, so you go and modify the block, then you've got to modify the high level code, then you've got to retest and reintegrate. And it's like, okay, great. So all of this time and money. And unfortunately, because you're there in a hurry, 'cause you're on site temp, typically you're not quite as neat. I've gotten better at it with time, but typically you're not as neat as you otherwise would have been when you weren't under the pump. And I guess if you're smart about how you structure the code from the beginning, you can sort of write your code to the point where it is a bit more flexible. And I guess that's an experience thing, but honestly, it gets to a point where if you make the code so generic that it's infinitely flexible, it also becomes infinitely difficult to actually document it. And when you truly test it, the more generic the functionality, I found that when it comes to integration, the truest test case only comes when you assemble all of the pieces because there could be some race condition between two or three different objects that isn't obvious or isn't apparent, maybe they'll say, hey, well, your test cases aren't thorough enough, maybe. But I guess the bottom line is that I find if you go too generic, sometimes that can cause its own problems. But in higher level languages, it's like, oh, I know, I'll just add another method. I'll add another method to this class. Why not? I mean, yeah, hey, all the data's in there, right? So let's just add some more. And before you know it, you're having this ridiculously long list and this huge object that no one can understand what the heck it does. And, you know, so that's my frustration. And that's to some extent self-inflicted, but it seems to be pretty common. And I guess that's something that I wanted to explore is that the more time and energy and effort you pour into it there's this base of code that's been written and tested and it's been out in the field and people have been using it. It's got that field soak time, if you want to call it that. And you're almost loath to change it. It's like, oh, well, if I do this, will it break that? And I just, but sometimes you're adding new features, you got to. So I guess I'm just sort of curious how you manage, how you've handled that, if that's something you've come across as well. - So I haven't had the exact same problems. Just as an aside, I'm curious, what OS, or like what are you programming against to control these pumps? - Okay, well, there's quite a few different controllers. In the industry that I work in, there's a whole bunch of programmable logic controllers PLCs for short. There's also something called a distributed control system or DCS. Similar kind of idea. Bottom line is that you've got a piece of hardware out there that you physically wire with wires into a drive or into a contactor and that will turn the power on and off to a pump or a variable speed drive. Kind of like if you've got an air conditioner, inverter, air conditioner, those sorts of things. where it can run the motor at whatever speed you set, you know, like a hundred RPM, a thousand RPM, you just give it a set point and away it goes, that sort of thing. And these particular devices are very, how should I say, they're vendor specific. So you'll buy a PLC from Siemens or you'll buy one from Schneider, unfortunately, or you'll buy them from whoever, Rockwell Automation. You'll buy from all these different people and they'll have their own custom programming software. So it's essentially each one is its own operating system that you've got to learn. It's software. It's frustrating as hell. - Well, I mean, you're like a real programmer. You make things work in real life, which is. - Yeah. I don't have this. Well, obviously I've done some high level stuff. I've done, you know, what you do, nowhere near to the level of software that you've developed. I mean, the best I've done so far is a (beep) little clock, but nevermind that. Anyhow, my point is that, oh God. - The point is that, you know, it's fun having a user interface playground where you can say, I'm gonna turn that specific pixel this right shade of turquoise. Why? Because I can. Whereas in a lot of the SCADA systems you deal with, you wanna draw a pump, it's gotta be red when it's running, green when it's not running or vice versa. Or if it's gray scale, it's gotta be just the right shade of gray. I mean, good luck customizing it. You know, you don't have that option. And when you're controlling a device with these PLCs, you're programming with Semantic Manager for Siemens PLCs, you're hacking away at that code. And you've got about two or three different languages to choose from, but if you don't do it just the way that they say, it is never gonna work. So it's not as flexible and that annoys me, but at the same time, it's satisfying because at the end of the day, you hit run and you watch this machine come to life. - Something actually happens, yeah. It's cool, it's really cool and it's very satisfying. And some of my best programming experiences were our industrial machines with servo motors and servo controls, 'cause those are so cool. So you like, there's one machine that I did which makes garage door panels. And this particular machine takes mild steel. So I think it's a 1.6 mil mild steel on a coil. This coil is like five tons, okay? so you can't pick these up, unless you're Superman or something. And put on a decoiling machine that unfurls the coil, then you level it, you emboss it with a wood grain pattern, and all the servo motors then feed it into another machine, that presses a pattern into it, then you chop it off with a guillotine, you accelerate that away, you roll form the edges, punch the holes, very, very cool. And you sit there and you think to yourself, hey, I just programmed this thing. This is so cool. - It sounds awesome, yeah. - Well, yeah, every now and then I drive around the city and I'll see houses that have been built in the last 10 years. And I think my machine made that door. And you're sort of like smiling to yourself and my wife will catch me saying, "What are you smiling about?" And I'm like, "Oh, yeah, nothing. It's fine, sorry." - Yeah, you had an impact on the world. - Yeah, well, I mean, but no one knows who the hell I am. So, they look at their door and they're like, "Hey, the door shuts." I'm like, "Yeah, that's my door." And they're like, "Who are you?" - But you know. - I get to feel good. - I do, yes, I get a warm fuzzy feeling. - So as for the entropy thing, like in user interface, I think it's it's unavoidable to a certain extent, in that the cost of making changes to code, and by cost I mean the time, can outweigh any immediate benefits. So while it may be you feel you need to refactor, you need to eliminate some methods, or you need to maybe just rewrite a system from scratch, it's very hard in shipping software to actually get around to doing that. For the same reason that you were saying before is that the pressure in this system is effectively coming from the users. Well, what is actually coming from is your revenue stream. If you want to be running a business, you need revenue. And so you get revenue from users. And what do the users want? They want new features or bug fixes or whatever it is. Whatever it is that the users want, they don't want you to rewrite a piece of functionality that they don't see any benefit from. - Yeah, I had a manager once say to me, there's no money in refactoring your code. - Short-sighted manager. - Oh yeah, I mean, I hate the guy, but that's not... But yeah, if you wanna be, yeah, if you wanna take it to an extreme, then I can see why someone would say that. - Yes, now, so that's what I mean, that's where the pressure's coming from. Now, the thing is, you know, with pressure of any kind, yes, bailing out the boat with a bucket may help to relieve some of the pressure in terms of sinking, But putting down the bucket and actually patching the hole up may help you a lot more, right? You may take a... Or building another boat right next to it. Whatever it happens to be, there are alternative methods to take that don't necessarily mean that you need to just keep bailing out with the bucket all the time. And in terms of software, sometimes, yeah, rebuilding a system is what's... It may not be immediately obvious that that's what's needed, but down the road, it'll pay off in spades. Absolutely. Finding when that is, is difficult. Sometimes you can be too eager to rewrite something just because you don't like it. Sometimes you need to, sometimes you're too late to do it. And that's an experience thing. Sorry, I cut you off. No, no, that's fine. Absolutely. I didn't mean to interrupt. So if you've got multiple products that you're supporting, then a lot of it also comes down to potential future utility. Like if you've decided I'm going to sunset my app, well, app X out of your portfolio, then obviously you're not gonna spend time refactoring it 'cause there's no payoff there. So yeah, it's a complicated question, but the bottom line is that I think that with all of the financial pressure to continue to draw in new users, you focus on the features, you focus on extending, and you don't focus on the refactoring and the simplification. And ultimately, that leads to this disorderly, this, well, you said originally, hopefully not spaghetti, the spaghettification of Goo code, I think was your term, but it's a good way of putting it. Now, I'm hesitant. I mean, I just made the argument that it's a revenue stream issue, But it doesn't need to be revenue because I think open source suffers from this same problem too. Yeah, that's an interesting... Yeah, okay. So... It's user... It's whatever... There's input pressure into the expectations of what the product has to do. And in the case of commercial software, yes, that's, you know, users and revenue exchange. But I think equally, open source has the same kind of pressures and they face the same kind of spaghettification or entropy push that commercial software does in some regards. Sometimes they can rewrite it, maybe with less blowback than in the commercial world, But a lot of times you find that that just doesn't happen. That world has its own set of pressures. And so I don't want to make it seem like it's just a money-grubbing thing is what leads to software entropy. Software entropy happens no matter what, based on the expectations of the product. I bet NASA has, you know, JPL has some systems that they wish that they could take the time to clean up. Oh yeah, absolutely. On the open source side, it's something I hadn't actually considered, so I'm glad you brought that up because I didn't actually think about that. But now that I am thinking about that, if we're talking about open source software, for example, that's essentially... How do I put this? software that's developed in open source that I've seen exists to offset a commercial need. In other words, there's a commercial product out there, but people are saying, "Well, we would rather have an open source version or something very similar or if not feature equivalent, then a feature similar to this other product so that people have a choice. And then it'll be open source, everyone can contribute towards it and it becomes its own living entity. And I think that in that case, that a lot of the driver is to drive it towards feature parity with its competition. And when I say competition, I mean, you know, commercial competition. So you look at something like Neo Office or Open Office and its feature set, and I am relatively sure that they would be driven by what they consider to be the key features and functionality that's currently available in Office. And they say, "Well, we want to be an open Office alternative, but you can't be an open Office alternative unless you have a minimum set of features that Microsoft Word and Excel and so on already have." And I would see that as being the driver. It's not money exactly, it's more of a feature equivalence. Yeah, no I totally agree. Do you, so do you see an alternative? Like is there a, do you have like a pro tip on how to avoid software entropy? Good question. I have a couple of ideas. I guess this is one more thing I want to quickly cover about some of the other areas that it can come from. And it all centers around people. So before we get to that, just quickly with people. Because people are the cause of and solution to every problem, pretty much. All right, so the people involved in a software project change with time. And in the industry, employee churn is somewhere between-- well, OK, in my industry, I think software, it's relatively consistent sort of numbers, about 18, 36 months on average staying with any one company. Obviously, individual experiences will vary and that's an average. Like in my career, for example, I stayed at a company for six and a half years and that was like an eternity. And I've been at a company for as little as four months in one that recently, well, didn't quite work out. But yeah, irrespective. Point is that on average, about a year and a half, two years, something like that on average. So if you have a product that takes more than three years to develop or is going to have a future version or set of series of future versions that spans more than three years, which for large software is very common, then you're going to have a completely different team working on it at some point in the life cycle of that product. And when teams change, directions change, changes, design principles can change and no more is it just we're going to keep it to eight menus, no more than 10 items per menu. That gets lost or thrown out the window unless there's really clear direction and a good reason given or there's this idea of the you know the the auteur who's involved through the the lifetime of that product trying to stabilize that and keep it consistent. Ultimately, new people, the new shiny, shiny features, they take over and say, well, we're going to keep tacking on more stuff. And that drives a lot some of that entropy as well. So at least that's that's that's been my experience. So, okay, so getting to how the hell you avoid this. And honestly, ultimately, you touched on one of the big ones already. and that is it comes down to focus on what the heck the purpose is of what you are actually writing. If everything, the solution to your success in software, anyone's success in software is simply you know, we're a kitchen sink, we do everything that you could ever want to do. Jack of all trades, master of none, is I think far better to focus on being exceptionally good at one thing or a handful of key things that are closely related in your software than to try and keep adding more and more features. You should try to enhance the features that you've got to make it even better. So I liken it to what Google's done with search. And I kind of realized that some people are going to yell at me when I make this comparison, but here goes. They started out with a big leapfrog on the competition with an innovative search algorithm, but they They didn't stop there. They kept on buying more and more servers and writing new code bases to improve their search result time. They're indexing all of everything that they do. Their algorithms are tweaked constantly. They keep pouring more money back into it. And that means that they're still just a search engine. Google is still just a search, but it's gotten so much better over the years 'cause they keep pouring more and more into that core competency that they've got to make sure that their final software product that they're delivering, and it is a software product they're delivering, that is so good at what it does that it is without peer. And if more companies thought like that with like Word or Pages or whatever, then there will be a lot less of this entropy going on, I think. - No, so I agree. Again, it goes to the pressure thing. I think Google is interesting in the way that the pressure for them works. They want two things, right? They want to get the customer attention that they need. They need to have the best search, but they also need to be able to serve up the best ads for people. So, you know, it's interesting there. The pressure, the pressures may lead them to be able to sort of reboot stuff and do stuff a little bit differently. - Yeah, I realized the danger in drawing the analogy Google is of course, well, you know, a lot of people see Google's ad-driven revenue stream as being... Yeah, I don't mean to... I don't even mean that. I don't think there's a danger, I think. I mean, the topic is software entropy. Google has a lot of software that there's no... I don't think that talking about them is... Whatever their revenue model, I don't think that being dismissive if it serves the greater purpose of trying to figure out what the pressures are to create this kind of thing. Oh, I totally agree, Guy. I'm just hearing the feedback in advance in my head right now. That's all. I can hear it right now. Don't worry about it. I'm trying not to. Everybody just email Marco. He took his email down from the website. How do you do it anymore? I'll let you know. Get in touch. Well, don't get in touch with me, but I will let you know what his email is. Oh, dear. Yeah, so, you know, entropy is interesting in its own right, just the concept of it, in the notion that over time, in the classical sense, everything gets disorganized and in the modern sense, I suppose, everything reaches an equilibrium. I think that is completely true with software and I think that your job as a developer is to maintain order effectively, right? Like in your code, in the interface, in the processes that you have. That's kind of your, you know, that's why you get a paycheck basically is that you're maintaining the order of the system. You're creating a system and you're selling a system, or in the case of open source, you're publishing it. You're providing a system and your purpose is to make that system run. And entropy is going to happen and that is always going to be your number one concern, or at least should be your number one concern. And it raises head in any number of ways, like you said, in the interface, in the code, but even in organizational structures or just the way that you run your meetings. However it is, it keeps cropping up and it's sort of the overriding issue, I think. It's a huge topic. Yeah, it is. I feel like no one talks about it or hardly no one talks about it. That's one of one of the reasons that I had it on the list. I guess one of the other things, just quickly, other thoughts and ideas on beyond, and people will hear me refer to Google and say, "Be like Google." That's not what I'm saying. Still, one of the things I love and hate at the same time, and this is such a silly example, but I'm going to say it anyway, is edit, paste, and paste and match style. If you're a Mac user, you'll know what I'm talking about. I brought this up previously on a podcast. I can't remember when, but the point is, how often do you copy and paste text where you don't want to match the style of the destination? You know, how often really seriously do you? And yet you get both options and the default option is to paste. And it's the wrong one. I mean, who the hell does that? I'm copying some text off of the web for my project, which is like plagiarism and totally wrong. Anyway, and I'll paste that into whatever I'm pasting it into and I get the formatting from, it's like it's the wrong font, the wrong font size. It's in italic. And so that's not what the rest of my document is. Orbits between emails and someone's emailed and it's gone. Yeah, it's come out as Unicode and it's like stripped of every formatting. And that, yeah, it's a silly example, but do I really need both of those options? Pick the one that is the most likely and run with that. Yeah, adding it as a feature, I feel like anyone can add a feature, but what takes the real skill, I think, and where the focus should be is understanding the right feature that people are going to use the most often and adding that, or if not, replacing what you've currently got with that so that it's simple and it's focused. And frankly, the simplest user interface, the simplest feature, the best feature, I should say, without adding complexity is a feature that is essentially invisible or mostly invisible to the user. And if you're gonna add features, then that is the way to do it. And if that doesn't sort of, I don't want that to sound too cryptic, but do you know what I mean? - Yeah, no, I totally want, I can explain that one actually. - Go for it, please. - That comes from the next days. You'd copy and paste and the rich text would be put on the pasteboard. And so when you pasted it, it would maintain this style, which was like a rocket science feature at the time. And it's, you know, they weren't thinking about surfing a website and copying a bunch of stuff out of a website. They were thinking about like, well, I've got two text documents with formatting in them and I want to preserve formatting as a copy and paste text between the documents. So that's why it was the default. I believe paste and match style came in on the Mac, like OS X. Maybe 10.0, maybe 10.1, I don't know. That was a hack around the thing. Now what they should have done is just change it to the way that it should work these days. These days, people are copying and pasting from all kinds of places and they very rarely care about keeping the formatting the same. So it really should change. So that is a perfect example of entropy and not revisiting a problem. And I still haven't. It's still there. I mean, I've got the current version of pages up and there it is, paste and match style. I don't know if they ever will because it could be one of those things that just ingrained, like that's the way it works and just get over it. I'm going to be complaining about this for the next 10 years like Syracuse was complaining about Copeland 2010. Maybe. Well, I mean, good news is if you keep complaining long enough, it actually works. That only helps if people listen to you. No one listens to me, so it doesn't matter. But I guess the only other thing I'd like to add about trying to reduce entropy, and this comes more in the teams thing and when you've got a longer term project, is if you've got a set of rules or a methodology or an interface paradigm that's guiding the development, the initial development of your software, then, you know, for God's sake, write it down and make sure that people read it when they start developing. Don't just say here, work on this bit here, we wanna add feature X. Get them to read the damn philosophy first. And 'cause I've, you know, I just had so many bad experiences of, here's a junior programmer, add this function to this object and go ahead and, You know, and time crunch, time crunch, get it done, get it done. And you come and you have a look and it's like, they've used completely different conventions to everything else. It's totally inconsistent with the project. And it's essentially, they've been off in their own little world. And why is because, you know, early on, well, when I was younger, I didn't write down the methodology. It was all in my head. Well, I got better at that. So now, you know, I'll write a coding standard. Here's my coding standard. Here's what you should follow. I'm not saying it's right. I'm not saying it's wrong. I'm not even saying it's the best or it could well be the worst methodology, but it's about consistency because it's the lack of consistency that drives that spaghettification. And honestly, it takes a few hours to write down a detailed methodology, I think. And that's time that it'll save you days, weeks, months of frustration in the future. So anyway. - No, I totally agree. In fact, yes, writing it down is good, getting other people to read it good, I think what you're getting at is that you need to indoctrinate people into the culture of the product and the code and the way that you make decisions and why you make the decisions. And over time that does become more difficult because you bring in new people, they don't have all of the experiences. You can't really capture everything and just download it into their brains. After a certain amount of time, you assume that other people think like you do, because you've been working with the product for so long. Yeah. And yeah, right. But we assume. Entropy kicks in, right? Yeah. Yeah, that's it. And the problem just gets worse when you've got the hiring boom and bust kind of cycle. So you'll, if you've got a group and you've got to get a product out and the, you know. - Are you bringing a bunch of people? - Yeah, you just bring a bunch of people. I talked about this on the episode 20, the Critical Path and not the podcast, the episode of this podcast called the Critical Path. Anyway, and it was the idea from Mythical Man Month, I'm just gonna throw more people at this and it'll therefore get done quicker. And the analogy being, well, you know, if there are nine women that are pregnant, then they'll give birth to one baby in one month. So, it's sort of that kind of a concept, it doesn't work. And throwing more people at it just throws out all of those rules and you just get chaos and disorder. So the gradual buildup and indoctrination, and geez, when I think about indoctrination, I think of some kind of like weird- - Yeah, it seems like a Manchurian candidate kind of word, but it doesn't- - Yeah, that's not what we mean. - No, embrace the culture of the team effectively. Yeah, embrace it. Or, there's the door. I mean, well, maybe not quite that brutal, but sometimes, I tell you, sometimes I wish I had been that brutal. Where I soft-pedaled stuff and I've let people go, it's like, "No, no," and then you pay for it. But anyway. Yeah, no, that's reasonable. This is the way things work and this is the way we're doing things. And if you're not going to contribute, that doesn't mean like it in North Korean kind of way, like you must behave like this. But at least know what the zeitgeist is and act within the kind of parameters. I think if somebody's going against that then it's probably for the best that you part ways with them. Yeah, that's true. I don't think they're going to be having fun and certainly it's not the best for the project as you see it or as the team sees it. Yeah, absolutely. If you want to talk more about this, you can reach me on Twitter @johnchidjee and you can check out my writing at techdistortion.com. If you'd like to send any feedback, please use the feedback form on the website. That's where you'll also find the show notes for this episode under podcasts pragmatic. You can follow Pragmatic Show on Twitter to see show announcements and other related stuff. I'd also like to thank our sponsor for this episode, Wet Frog Studios. If you're looking to add some curb appeal to your product or company, remember to specifically visit this URL, wetfrogstudios.com/pragmatic to get a great result at half the normal price. So I'd also like to say a big thank you to Guy English for coming on the show today. And what's the best way for the people can get in touch with you and see your work? So I have an app called Napkin which you can find in the Mac App Store I'm @GTE on Twitter, very occasionally I write at kickingbear.com I do a podcast called Debug which you can find at iMore.com or iTunes Awesome, cool. Well thank you so much for coming on Guy, I think this was a really great talk Thank you, I had a blast, thanks man Cool, thanks everyone for listening (upbeat music) [MUSIC] (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) [MUSIC PLAYING] (upbeat music) [Music] (explosion) [BLANK_AUDIO]