Alexis Monville (en)

Build a Product with Gojko Adzic

—

by

Alexis
in ,

Gojko Adzic is one of the 2019 AWS Serverless Heroes, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko’s book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.

Gojko is a frequent speaker at software development conferences and one of the authors of MindMup and Narakeet (I am a user of both those tools 🙂 ). For example, I created that video just using existing slides and speaker notes in a few minutes.

Impact Mapping, published in 2012, is one of his books I reference the most in my day-to-day work especially to create OKRs. The .org website on Impact Mapping is a great place to start!

“If you are not keeping score, you are practicing not playing”

Gojko Adzic

Building Products is what we explore in this episode of Le Podcast on Emerging Leadership. In this episode, learn from Gojko:

“The hardest single part of building a software system is deciding precisely what to build.”

Fred Brooks

Listen to the episode here:

You can listen to this episode on your favorite platform: Anchor, Spotify, Breaker, Google, Apple…

Here is the transcript of the episode

Alexis:

Hey, Gojko, glad to have you here. How are you and can you tell us a little bit more about you and your background?

Gojko:

Hey, wonderful to be on the show. I’m a developer, currently working on two products. I’ve worked as a consultant, I wrote some books, effectively, I really like coding. And since I started on a developer job 20 something years ago, I realized that in order to do good coding, I have to learn how to do good testing, how to do good product management and a bunch of other things. And my interests seem to be going around in a spiral, I tend to learn a lot about doing some coding thing. And then that leads me to making more complex product so I need to learn more about how to test it well. That leads me to figuring out well, how do I reduce the amount of things I need to do in order to do all of this well, so I need to learn more about product management, and then it gives me more capacity to do more development and start new products. It’s kind of going on in a spiral and every time I touch one of these subjects, I end up writing a book about it, I guess, is a way of doing a memory dump so I can free more random access memory for myself.

Alexis:

I love that. I love the way you are describing that. And I love the fact that it’s a virtuous spiral that is leading to more books, because I already enjoyed reading your books. So that’s a really good news. Of course, one of those books that I’m using radio a lot is Impact Mapping. Can you tell us a little bit more about what led you to that book? And probably what is impact mapping? You will need to explain that once again.

Gojko:

What led me to the book is I was CTO of a company that basically ran into a wall and spent all the money that it could spend. And it did that in the worst possible time where kind of 2008, 2009 it was almost impossible to get any good investment, and we ran out of money. And I was a minority investor in that company as well so I didn’t take any salary. And I was left almost without the money to pay the rent next month, that’s how stupid I was. And we were incredibly, incredibly efficient in terms of software production. It was by far the best team I’ve ever worked with, even till today, in terms of technical competence. And we were doing things that became buzzwords later before they had a name. So we were doing stuff like continuous delivery before people knew the continuous delivery buzzword, we were doing cloud based deployments back then, we were doing almost 100% automated testing. And it was wonderful. The code quality was wonderful, but we delivered no value.

Gojko:

And because we were really, really efficient, we efficiently burn through our core budgets. And as a CTO of that company, I was really embarrassed when it came to the point that I had to admit to myself what we’re doing is wrong. Because I thought we were doing so well. Up until then I really focused on on the technical quality of what the product is. And I’ve realized that there’s a lot more and as a technical person, I need to engage a lot more with product people. Not in a sense of not trusting them, but in a sense of being able to more efficiently challenge their ideas and help them make better decisions, and help facilitate a discussion between technology and product. And that led me to a lot of research and trying to figure out what we did wrong. And I started studying the emerging discipline of product management in software and how to kind of people do product management and deal with assumptions. That’s, I think, roughly around the time when the Lean Startup came out, and the software world really started awaking to how much we waste on stupid work and stupid products.

Gojko:

And one of the really wonderful things about software for me is it’s almost like magic. You literally turn ideas into products. You sit and drink coffee and turn something you have in the back of your head with some magic words. We don’t use Abracadabra, we use const value, and for each and things like that, but that’s magic, create products out of nothing. But at the same time, if what we build is missing the point, then you can spend a ton of cash and it just vaporizes, it disappears in thin air. There’s nothing to show for it. And the research I was doing back then to figure out what we did wrong and how would I never repeat that mistake in my life led me to learn about this technique called effect courting that the E news agency in Sweden was developing. And I just saw how incredibly wonderful that is for facilitation.

Gojko:

And the reference book for what they were talking about then was in Swedish day, there was an English version of that book, but wasn’t that popular. And I have very high respect for E News people and I don’t want this to sound like I’m kind of disparaging them, but I don’t think the book was accessible to the average software developer or the average software stakeholder. And I decided that I’m going to just try this out, and trying it out I saw how good it can be. And then decided to kind of write a book that will make this technique more approachable to people, especially doing interactive software delivery. And that’s basically the story of the book.

Alexis:

Excellent. I love the story. And I love it. It’s anchored in something that is really important to you. People always love to talk about their successes and how great they were, nut it’s always interesting to learn about something that didn’t really work well in the end, and what you can learn from that is really important. So I love the story behind the book.

Gojko:

Yeah. I think there’s so much wasted potential today in what we do as an industry. I mean, if you look at how much software gets produced and how much energy and how much effort people spend building these things, and then you look at the results of some of these efforts, most of it is just going to mediocre, most of it doesn’t go anywhere, a lot of it is kind of pointless. And it’s very difficult to even know in the short term if what we’re delivering makes sense or not. One of the best examples of this, a few years ago there was a project that the British Broadcasting Corporation where it was shut down, it was a personalization project for the video player, and it was shut down after a few years when they spent something like, I think 75 million pounds, can find the link and send it to you so that you can attach it in the podcast. I don’t remember exactly now. I think it was about 75 million pounds, something like that. It was shut down because it delivered no value.

Gojko:

And because this is a publicly funded cooperation, it’s a public broadcast that the government Office of National Audit got involved to figure out how can you possibly spend so much money on software and deliver no value. And the conclusion at the end, I’ll send you the link to that you can put it in the podcast links for your audience, was they could do it because it was urgent. And what that meant is that every month what they delivered, somebody was evaluating to say, well, is this good? Is it bad? Is it valuable? And the stakeholders were deluding themselves where they were making the decision if something was valuable or not. And it was basically somebody in the company told some developers, “Well, I want this feature.” They deliver the future and say, “Well, is it valuable?” They say, “Well, yeah, that’s what I asked you to do.” And it’s completely pointless. It’s just running around in circles and having no way to actually understand if we’re going in the right direction or not.

Gojko:

And I think impact mapping is the easiest solution I found to that problem. It’s not the best solution, there are probably better solutions out there but they’re very, very academic, very difficult to apply. The most popular process for goal driven requirements engineering in the academia is something called the iSTAR. And the basic book on iSTAR is about six or 700 pages. You must provide some wonderfully precise way of measuring value, but I don’t think any of the people I ever worked with would understand that and have time for it, where impact mapping is something that you can explain in 10, 15 minutes to business stakeholders and one afternoon later they will already have an impact map. And that’s why I love about the practice. It’s it’s kind of fast, it’s collaborative, and it really helps people solve an actual problem.

Alexis:

Can you explain impact mapping in a few minutes for us?

Gojko:

Absolutely. So impact mapping is a visualization technique that helps developers, business stakeholders, product representatives, analyst, UX people, people from different backgrounds, have a really good conversation on how the plan or a proposed deliverables connect to the value and how do we know that we’re going in the right direction, what is the value of what we’re going to deliver. And they help people visualize the big picture for what needs to be achieved and create a good way of measuring if we’re going in the right direction or not. Impact mapping does that by connecting the business goals through impacts, through changes to the users behavior or changes to the customer’s behavior, and to the deliverable. So it presents this middle layer that helps us measure change in a short term. What’s really wonderful about that is that behavior changes are observable on a shorter timescale. So if we change some software over there, and people start staying longer on the website, or they start interacting better with their friends, or they can administer Linux systems easier, or they can create larger server farms faster, then we’re delivering value. And behavior change is something that can be measured in the short term, it can be measured with a trial population of users, it can provide a leading indicator of value. And that’s why it’s so important.

Gojko:

And I remember reading Michael Jackson’s book, of course the consultant architect not the singer, I don’t think the singer wrote any books, about problem frames probably 20 years ago, or even more. And he said that one of the biggest problems in software delivery is creating a connection between the problem machine and the solution machine. And impact mapping creates a connection between the problem world and the solution world through these impacts and behavior changes and allows us to see where we’re going, allows us to measure that what we’re doing makes sense and allows us to focus on solving problems instead of just delivering solutions.

Alexis:

That sounds really easy said this way. And I think it’s exactly why the approach is so useful. It’s because it’s really easy. And once you started asking yourself the questions, it really helps you to do exactly that; connect the impact you want to achieve with the solution you want to break. And that’s really, really helpful. I love that.

Gojko:

So one of the one of the books I really love, I read this book a few years ago and I’m really sorry I’ve not discovered it a longer time ago, is Four Disciplines of Execution. For people that have been doing a good product management or can do delivery in a good way, there’s nothing revolutionary new in the book, but they’ve explained things so well it’s amazing. So I think even if you are the total expert in your field, it’s worth reading that book because the book is so well written and the ideas are so well explained that it’s totally amazing. And they boil down the difference between organizations that are excellent in executing their plans, compared to organizations that are not who they execute in their plans to kind of four big differences. The first big difference of the first kind of discipline of execution is focused on the wildly important, which is really keep your eyes on the ball and focus on the ball and work towards that. Impact mapping helps with that, because you have this one goal at the center of the map, and you’re really focusing on delivering that.

Gojko:

I’ve worked with organizations where once we start creating an impact map and have 50, 60 ideas in a backlog connected to a single impact, and the first two epics deliver the impact, then we can just say, “Look, we don’t have to do the other 48, we focused on the goal. We’re not focused on delivering the solution, we’re focused on delivering the results. And we’ve delivered the results so let’s move on.” The second thing they talk about is focus on leading metrics of value, on leading indicators of value. They say that every organization can very easily measure at the end if an initiative succeeded or failed. If you start something to increase your market share, or increase revenue, or increase profit, six months after you finish or a year after you finish, you will be able to know if you did it or not. Very easy. The measurements are there. But those measurements are irrelevant, really, for knowing what should you do next week. Like if you have 50 user stories that address the same impact, which of these user stories should you do and which you shouldn’t do? You can’t know that if you only measure the results six months later. If you’re like, the BBC in the eye player project, and four years later you wasted 75 million pounds, that’s game over. We need leading indicators of value.

Gojko:

And impact mapping helps incredibly with that because it provides this glue layer in between that is these impacts that we can start measuring, are we going in the right direction or not. And there’s a wonderful story from Mark Schwartz in his book, The After Business Value, where they talk about this project they’ve done at the US Immigration Services, where it was a massive, massive government project but they looked at how many cases a human case worker can process per day. And that’s a leading indicator of value that then you can focus on. And they were measuring the behavior change for these people. So every time they deliver a piece of software they were measuring if humans are processing more cases per day. If yes, we are delivering value, if not, what we deliver is incomplete, pointless, damaging whatever. And impact maps help amazingly with that. The third discipline of execution that they talk about in the book is to create a team scoreboard. Create a way for the team that delivers to know are they going in the right direction not. Not to have to wait on external feedback from some third party that three years later says well, this is valuable or not. But look at really focusing on providing value to the people that providing information to people that deliver so they can make better decisions.

Gojko:

And they have a wonderful quote in the book, I love it. They say if you’re not keeping score, you’re just practicing, you’re not playing. And for a lot of organizations, we throw some software against the wall, we have no idea if it delivers any value or not. And again, impact maps help with that because they make it clear, well, this story is related to this impact. Our scoreboard, the way we measure the score, should be is this impact happening or not. And this opens up some really, really interesting discussions that can happen. There’s a wonderful piece of research, and I’ll give you the link, I think it’s interesting for your readers to understand as well, from Microsoft, where a guy called Bronco Harvey went to analyze if the stuff that was promised in PowerPoint actually came through for some initiatives. And his conclusion was that about 1/3 of initiatives that they looked at actually moved the numbers that were supposed to move in the right direction, about 1/3 actually created no statistical impact on the numbers that were supposed to improve, and about 1/3 actually damaged the numbers they were supposed to improve.

Gojko:

Microsoft is a pretty good software development company, and if you look at it from that perspective, they don’t get things always right. And of course, they don’t get things always right because the business people are not clairvoyant. They don’t have a crystal ball, they don’t control the competition, they don’t control the market. And writing the scoreboard allows us to actually see in a shorter cycle are we delivering or not. And the fourth discipline of execution they talk about is creating a good cadence of accountability. The last discipline they talk about in the book is creating a cadence of accountability. And really, that means reviewing the plans as we’re going along very frequently, and being honest about are we delivering value or not. Being honest about is what we’re doing providing what we expected it to provide. And if not, then there’s something unexpected going on. Then we need to do a bit more research, we need to inspect whether there’s something blocking our users from realizing the value we expected. Or maybe the ideas we have they’re just bad ideas. And from that perspective, impact mapping really helps connect all these things together. And it’s a wonderful visualization technique that’s really simple.

Gojko:

And you said it was easy, I think there’s a nice distinction we need to start making between simple and easy. I think impact mapping is simple as a way we can explain it in 15 minutes. I don’t think it’s incredibly easy to do, there are some challenges about doing it. It’s not too difficult to do, but it’s much, much easier to do than a lot of other very complex bureaucratic things. And that’s why I love it.

Alexis:

Yeah, that’s true. It’s simple to understand, it can be hard to get to a map that you really like. The thing is, it’s easy to start, you can have something really fast, it will not be perfect but if you accept that you will keep that map and you will continue to improve it, you have something you can work on, and you can improve it. And it’s convenient to visualize it. And it really helps with prioritization and saying, okay, we will focus on that particular impact now. And that’s good. We are good with that. So yeah, you’re right. It’s simple, it’s not necessarily easy.

Gojko:

One of the things I think helped me a lot was reading that habits book on how to measure anything. That’s kind of when I was doing this research for my benefit on how do we get good business metrics out, I came across that book, and it’s a wonderful book. And in the book, he talks about how lots of people discovered metrics that are not perfect, because they don’t totally eliminate uncertainty. And he says that good metrics don’t necessarily need to eliminate uncertainty, it’s really difficult to eliminate uncertainty. But good metrics help reduce uncertainty. So I think impact mapping is one of these things where it will reduce uncertainty and the more you do it, the more it will reduce uncertainty. And even if you start and you don’t get the perfect map, you don’t get the totally mathematically correct thing you need to do, it’s useful, as you said, because it’s better than what people were doing before. So it reduces it a bit.

Alexis:

Yeah, exactly. Exactly. When we scheduled the call, you told me that you were available before a certain time in the day, because after that you were programming. And of course, I’m very interested in collaboration and in close collaboration like pair programming. Is it something that you are always doing, pair programming? Or is it something that you’re doing just for the moment for a specific product you’re working on?

Gojko:

I work on two products at the moment. One is relatively kind of successful and more stable. We’ve been developing that since 2013. And there are two people working on that product, There’s me and a colleague of mine, David, and we pretty much pair program all the time on it, because that allows us to share the knowledge of what’s going on. And that allows us to create a better product, that allows us to keep each other honest, and not cheat and not cut corners. And it genuinely leads to much better design, because we can have two pairs of eyes looking at something instead of one pair of eyes. And we develop this product that basically stands on its own, it doesn’t require almost any support. And it allows me to travel around when there’s no Corona and the planes are flying, and it allows David to do his own things in his time.

Gojko:

So it’s very important for us that the quality of the product is allowing us to work at a sustainable pace. Because there’s only two of us, we cannot spend time fielding customer support calls or fixing bugs and things like that because then we’re not producing value on the product. So what comes out has to be really, really good. And I think pair programming is absolutely critical for that. Having said that, I honestly enjoy programming more on my own. I find a lot of joy in programming. Programming is one of the best things I can do to lift my spirits up and enjoying my day. And pair programming can be brutal, it can be very difficult because you’re always having to explain everything you’re doing. And I found that I cannot get really immersed in the problem, I can’t get in the flow if I’m pair programming. As I said, it does produce a better product. And from a product development perspective, it’s the right thing to do. From a enjoyment perspective, I also like spending a long period of time just on my own, listening to music and very quietly being immersed in a problem and trying to solve it. And that’s kind of what brings me into the flow.

Gojko:

The other product I’m building is a very young one, I kind of literally launched it commercially less than six months ago, I think in October. It launched commercially in April last year, it launched as a betta. It’s a video editing tool that is saying that people who are not video editing professionals and they want to very quickly create a video from assets such as images or screenshots, and it does. For developers and techie people in particular it’s really good because it allows you to convert a markdown file into a video, which means you can have video on the version control. And it helped me a lot doing stuff for the previous product, actually. That’s how I came with the idea. Because there’s only two of us, we have to do programming, we have to do support, we have to do sales, we have to do product management. And one of the things I ended up doing is creating videos for users to learn how to use the product. And then every time we changed something small on the screen, I have to re record everything again. And because I’m not a video editing professional doing a five minute demo video takes me two or three hours or took me two or three hours.

Gojko:

So I started looking for ways to automate that. And then I figured out well, I can just automatically compose screenshots into video and even integrate with text to speech engines that have improved significantly over the last five or six years. And they can do English better than I can. I mean, I can’t get rid of my accent so if you hear me speak in a video, that’s not as nice as hearing a nice gentle voice that speaks in a perfect English accent. And I can do that with machine learning voices now. So basically you get the markdown document, you compile it, and it gives you a video. And then I realized, when I automated for this other thing, there’s a product here. So I’ve kind of extracted that into a separate product and launched it. And for that, I’m programming on my own. And I enjoy that immensely. So I can spend 10 hours immersed in a problem and not notice how much time has passed. And I realized if I work on my own, I enjoy it a lot more. But pair programming creates a better product.

Alexis:

This is excellent. So the first product is Mind Map, right?

Gojko:

Yes, the first product is Mind Map. It’s a mind mapping tool mostly used by schools and universities. We have some kind of project management cases and also some people are using it for describing the testing plans and outlining books and writing, but it’s mostly used in educational setting.

Alexis:

And the second one is Naraeet?

Gojko:

The second one is Narakeet. Yes, exactly. Thank you very much for investigating so much. That’s amazing.

Alexis:

Yeah. I have to admit that I’m really excited about Narakeet because I wanted to have a short video to explain something. And now that I know that I can even just create a slide in Google slide and start from there, I’m really excited about it. I’m working on it right now.

Gojko:

Thank you very much. Yes. So it started this a bunch of shell scripts actually to get everything editing. I don’t know, I have this flaw in my mind where if I see something that I do five times, because I’m lazy in a good way. I don’t like repeating myself. And if I see something I do five times manually, I cannot have an urge to automate it in shell scripts. And this thing actually started as a shell script, and then evolved into a nice web service for people. So I’m really glad you can use that as well.

Alexis:

This is really good. This is really good. I have a question for you. When we are in close collaboration with someone, it’s sometimes a little bit difficult to get things across in the right way. How do you deal with that? How do you deal with the potential conflict? How do you deal with not being on the same page when you work so closely with people?

Gojko:

So I have two techniques I tend to apply to resolve situations like that. One is, I don’t know who I stole this idea from, so I can’t really give you the exact source of this. But I think I stole it from Michael Bolton, the tester not the singer, of course. The idea that I phrase it like now, I think he phrased it slightly differently, is that it’s much easier for people to complain than to tell you what they want. So if I’m working with people and I can’t really get them to say what they actually want, I throw something that I know that they’re going to complain about. Like I propose something idiotic, and then we get to a good conversation that actually makes sense. The other technique that really helps me clarify things is to offer realistic examples. And I think, examples of how something is supposed to work, examples of how we might want to use something, are again, concrete enough for people to really understand that there’s an additional case here, or we’ve not covered everything, or we need to discuss something in a better way.

Gojko:

And examples are a wonderful technique. This goes back all the way to I think Jerry Weinberg’s work on exploiting requirements from 1989, or even longer, on giving people something that is concrete that everybody can agree on. In a complex organization that delivers a product, you have people from lots of different backgrounds, and they all use different sources of truth and different forms of explaining information. UX designers use wire frames, developers use code, testers use some kind of testing scripts, business people use PowerPoints. And it’s really difficult for all of them to agree on anything. But everybody can talk about realistic examples. And that’s something that has turned out to be an almost universal tool for good communication.

Alexis:

Excellent. Is this the route ideas that lead to write the book Specification by Examples?

Gojko:

I think so, yeah. Spec by Example, again, came out of a slightly different journey for me, where I was working for a company where they had lots of database developers who only looked at Oracle PL SQL code, and application developers who looked at Java back then I guess, or C# wasn’t out yet properly. And business analysts wrote all these kind of log documents where nobody was reading them. And I was really trying to figure out how do we avoid the long testing cycles? And how do we avoid getting stuck in something that we deliver and at the end it turns out it was the wrong thing. And that led me back then to discover, I think, fifth from what coming home and fitness that came around that time. And I started thinking about this from a perspective of this is going to help us automate testing. But I realize there’s so much more to this. And it’s actually kind of a good communication technique. And test automation really becomes secondary, once you have a good understanding. It’s easy to test, but kind of the tests almost become secondary. So the book Spec by Example came out to kind of that learning journey.

Gojko:

I told you earlier, I think, once I remove a bot with me doing code, I realize something else is a bottleneck. And in that case, testing was the butt link so I had to learn how to do testing. And that led me to this whole idea of what was back then, example driven development or acceptance test driven development. Behavior driven development as a phrase didn’t exist yet back then. I think Dan North came up with that phrase around the same time. And most people would call that stop behavior driven development now, but there was a very interesting situation where we actually… I think XP, when XP became popular or started becoming popular, early 2000s, developers were the first to jump on the train. And then we remove the bottleneck, lots of organizations removed the bottleneck from development. And then they all realized, well, the next bottleneck is testing. And as Jerry Weinberg says, once you solve your number one problem, your number two problem gets a promotion. I think the community that invested a lot in solving this kind of developer tester communication gap and that’s what led me to examples and Spec by Example.

Alexis:

Yeah, it’s excellent. I love the idea of looking at the world process and looking at the bottlenecks. You remove the first bottleneck on development, you have a bottleneck on testing. And then you can say, “Oh, yeah, we need to deliver.” You solve the bottleneck on delivery, although it’s absolutely perfect. And then you realize that you are not delivering the right product. And you are going back to the beginning saying, “Okay, what is the missing link between the users and the value they want and the definition of the product itself?” And you solve that also a problem. It’s interesting how you connected all those dots. I love it.

Gojko:

Yeah. I think it’s not cyclical, I think it’s an upward going spiral. You solve one problem and then it takes you to another problem. And I think our industries is very cyclical but the cycles are quite long. If you look at what’s happening now in the technical infrastructure space, in essence, we’re almost back to the time of mainframes, or the time of mainframes is coming back again. In the 70s and early 80s before the PC revolution, people were renting, effectively, CPU cycles from mainframes with timeshares and things like that. And now you have people renting CPU cycles from Amazon, or Google or Microsoft, either using virtual machines or using severless functions now. And in a sense, it’s a much better mainframe and much more accessible mainframe than it was before, but it’s timeshare, we’re coming back to that. And-

Alexis:

Exactly.

Gojko:

… really interesting after this timeshare, there’s going to be the new equivalent to the PC revolution or something like that, where we go back to client server software in some new way. But my best guess is it’s going to be client server software on very small devices like IoT, or things like that, that’s kind of emerging. And we’re going to end up in in really silly situations and some wonderful situations. You can really see some examples of that. I think there was an outage at Amazon in the US East one region, that’s kind of the first Amazon cloud that went up in North Virginia. There was an outage a few months ago where the message distribution system, Kinesis, that they use, brought down a bunch of other services. And there were people locked out of their homes because they had these smart lock devices that were talking to the Amazon cloud. And now you have this mainframe going down, and people can’t go into their homes. And that’s ridiculous. So after the mainframe, we’re going to go back to smarter clients. Because if the cloud goes down, you still still need to go back to your home, obviously. So cyclical, but the cycles are slow and people don’t really notice that much.

Alexis:

Yeah, I think during the PC revolution people were mocking the, I don’t remember who was the person at IBM that said we will probably need five computers in the world at the beginning of the computer story. And people were mocking those saying, now you can see how many computers we have now, but from a big mainframe perspective, we are probably on our way to have five big computers in the world.

Gojko:

There is three computers that, maybe four computers really matter. I don’t know enough about the Asian market. But really, we have Amazon, and Microsoft, and Google. And I think, unfortunately, IBM missed the game. It’s incredible how IBM kind of totally missed the mobile, and the web and the clouds. And it’s very interesting to see if they will catch up. Oracle is trying to build their own cloud, but I don’t know anybody who’s using that. And you effectively have three computers that matter. And maybe there’s Alibaba or somebody like that in China, I’m not really sure about that market. I think that’s an emerging markets. And I need to learn more about that. But yeah, we’re coming back to three or four computers effectively, and everybody else having down terminals that connect to that.

Alexis:

Yeah. And the smart computer at the edge, that’s exactly that edge revolution, because the example you mentioned about not being able to go back to your home, that’s exactly what you don’t want when you have a car and the intelligence should be in the car and some of the data should be in the car because you want the car to be able to break or find its way to some places without the need to even connect it to the network.

Gojko:

And things are so so connected that it’s ridiculous now. I remember, two or three years ago, Amazon S3 went down for a couple of hours, I think. And it took down half of the internet with it, it took down Reddit, it took down about a bunch of other services. So everything is connected to everything else now. And that’s amazing, because you have this kind of information distribution that anywhere you go in the world, you carry all the world’s knowledge in your pocket effectively. But because everything is connected to everything else, crucial service like that going down for a couple of hours might mean yeah, car stop working now, and that’s ridiculous. So yeah, we are going back to those cycles. But the reason why I mentioned this, I think is we’re having the same type of cycles, I think, in the software development world as well. Because we unlock one bottleneck as a community and that changes the context, and then we go and unlock another bottleneck. And then at some point it comes back. So I fully expect at some point that programming will become the bottleneck again, and then we’ll have to come up with much, much better techniques for programming or better languages or better ways of doing things.

Gojko:

And whether that’s because everybody settled on JavaScript, that is the worst possible language you can think of in terms of language design. But it’s incredibly productive for people, and it turns everywhere. So now we have these monstrosities like TypeScript that’s trying to kind of fix it, and WebAssembly that’s trying to allow compilation of JavaScript and other things. And maybe when it comes back to that, we’ll have better languages, finally, to work that run everywhere. Who knows? But it is a cyclical thing. And I think it’s worth reading stuff that happened in the previous cycle. When I was trying to figure out how to improve the developer testing cooperation at this large company, I was reading stuff that people were writing about in the 80s and 70s. And there’s lots of good material there. People today, chase the current fad, and always look at whatever next shiny thing gets invented. But we tend to… Software industry is not really old but it’s already gone through a couple of these cycles. And it’s really worth looking at what people were writing about in the previous cycle to figure out what ideas can we take from that and apply in the new context.

Alexis:

Yeah, I agree. You, if you look at Frederick Brooks or Melvin Conway, you can see those things that oh, yeah, they exactly describe the problem I have now and it was 40 or 50 years ago.

Gojko:

Fred Brooks said the most difficult problem in software is deciding exactly what to build. And look at where most people are now, or at least people I have worked with as a consultant. The bottleneck is not in programming, the bottleneck is not in testing, the bottleneck is in product management for a lot of people. So we came back to the most difficult thing being deciding what to build.

Alexis:

Exactly. It’s really an interesting conversation. I’m really grateful you accepted to join the podcast today, Gojko. Is there’s anything else you want to share today?

Gojko:

Well, I don’t know. Let’s leave it at this, I think. It was a really enjoyable talk. And thank you very much for inviting me.

Alexis:

With great pleasure. Thank you, Gojko.

Alexis:

Thank you for listening to this episode of Le Podcast. Go to alexis.monville.com. For the references mentioned in the episode, and to find more help to increase your impact and satisfaction at work. Drop a comment or an email with your feedback or just to say hello. until next time to find better ways of changing your team.

Photo by ThisIsEngineering from Pexels