Transcript
Stefan Tilkov: Welcome, listeners, to a new episode of the CaSE Podcast, another conversation about software engineering. I'm extremely happy to have Christin Gorman as my guest today. Hi, Christin.
Christin Gorman: Hello! Nice to be here.
Stefan Tilkov: It's awesome to have you on the show. Can you start by introducing yourself?
Christin Gorman: My name is Christin Gorman. I am Norwegian -- or I'm half-American, technically, I guess... But I'm a Norwegian developer, so I've been working/doing programming for 20 years now; I'm getting really old. I'm currently working as a contractor for a small company called Kodemaker. We go out and help customers build software. I'm hands-on writing software, that's all I've ever done really, professionally.
Stefan Tilkov: Very cool. When we decided about what to talk about in this episode, we spent some time with the title, and then settled on "Why large projects fail and what to do about it", so maybe we can start by defining what kind of projects it is that we're talking about here. What kind of projects do you do, and why do you think some of them are good candidates for a conversation like this?
Christin Gorman: I guess I can touch on your last question, why do I even care about this, and why is this something that I rant about at length... My first jobs, I was working for small companies and startups, and I was the only developer, or one of two; we'd have a very natural progression. We'd have to focus on what was the most important to do, and what our users needed, and we had to deliver or we'd go out of business, basically. That was how I started working.
Christin Gorman: Then I progressively started working for larger and larger companies. So I went from that and I worked for -- I was in the oil industry to start with, and I worked for Schlumberger and WesternGeco. That's a much larger organization, but it's still a product development company. Then we went from there to my first public sector project in 2010. And after ten years of working either as a startup, trying to get things working, or in a product development organization, working on problems, being met with the level of inefficiency I was met with when I tried to do something in the public sector - it was just astounding to me.
Christin Gorman: I was surrounded by the most intelligent, wonderful people, who were very technically competent, and also just nice people... I have nothing bad to say about the people in my team, but we were just unable to work effectively and to deliver what the customers actually needed. So that's kind of been the trigger for me - after ten years of working more or less sensibly... You know, I was always complaining, of course, because that's kind of my nature - I always want to do things better - but it was a real shock to see how badly things can go, and it really opened my eyes to why I'd been hearing all these years that "Oh wow, you guys are working so fast. This is amazing" and I was like "This is normal, isn't it?"
Christin Gorman: So what I've been ranting about was these large contracts that large organizations set out; they had this predefined requirement specification, like "We are gonna save the world, we are gonna do this amazingly big project", and you put it out to tender, and then you have this enormous team of lots and lots of people trying to solve everything for this customer. That's been primarily the kind of projects that I've been trying to argue against -- or try to inform people of better ways of working.
Christin Gorman: Recently, in the public sector in Norway, for instance, there's been lots of controversy recently about this healthcare platform project. I know there was one in the U.K. ten years ago, where they spent 10 billion pounds for this huge healthcare platform, but it didn't even work; they had to do something else... Things like that.
Stefan Tilkov: We don't have those kinds of projects in Germany. In Germany everything always runs on time, and on schedule; never has anything like that happened around here.
Stefan Tilkov: I think this is going to be an interesting episode, because one of the things that I really enjoyed was that you complained very entertainingly when I saw you do a presentation on many of these topics... So I'm really interested in diving into more detail here. I'll also share a bit of that history; I had the same feeling, being surrounded -- that resonates with me very strongly... Being surrounded by awesome, super-smart people, who only want the best, they're all motivated, they all wanna do good things, but they completely fail at doing it, for some strange reason. So let's try to figure that out, and then maybe try to define or find a few ways out of that hole, if you find yourself in it.
Stefan Tilkov: Let's talk about the projects... Why do they go wrong? What are some of the most common problems? I think you hinted at some, but maybe we can go into more detail about that.
Christin Gorman: One of the problems is our human lack of -- we are very limited in what we are able to conceive of in our small brains. There's a limited amount of complexity that we are capable of dealing with. And as Einstein said, you have to make things as simple as possible, but not simpler. That is invariably what happens when we try to bite off too much, when we try to solve too many problems or take on too much; we have to simplify that to be able to deal with what we're going to do. We have to simplify things too much, so then unnecessary complexity has to be thrown out the window, and we end with these -- you know, in computer terms you have these systems where you have tons of menu items, and tons of input textboxes that are only there because someone else needs them. But then textboxes you need for your job aren't even there, because they've been simplified away.
Christin Gorman: We need to just realize at the outset that we just cannot process that much at a time. We have to break things down. I think we're just too ambitious; we don't realize our own limitations. Especially when you're in charge of a large organization, you think "Let's solve the organization as this one thing that is solvable", but it's just too much. We need to realize that we just cannot do that. We have to break things into smaller pieces.
Stefan Tilkov: That seems like an obvious thing to say, right? I have this huge problem, so I subdivide it into more simpler problems, that I can solve each of them in turn. Why doesn't everybody see that way? Why do people want to do those large things?
Christin Gorman: Yes. Especially when we're working with software, I think we know how quickly complexity just runs completely out of hand, because we have to deal with the nitty gritty details. I think for developers it should be a lot easier to realize the inherent necessity of breaking things into smaller components. But I think lots of the people - or at least in my experience, the projects that go wrong have been decided upon by people who have no idea about this. They worked at a completely different abstraction level. So for them, it is just one problem; it is just "We need to handle health journal information." That is one thing to them. They don't see all the details, and they don't have this inherent understanding of how extremely complex that necessarily becomes if you wanna support every possible user group.
Christin Gorman: Again, people see things from their perspective. If you're the top manager for this company, you have a simplified view of all the things beneath you, and you're going to see that as "This is my company", and then you want a solution for your company; you want something that's easy for you to understand. And the problems arise when the people who decide what to make are not the same people who are the ones that are going to use what's being made. That's where problems start. The farther those two groups are away from each other, the more problems you end up with.
Stefan Tilkov: The first thing you hinted at reminds me of this saying that "All things look very similar to each other from up here in the ivory tower." If you're far enough away from stuff, then it looks as if it's exactly the same thing. You have to get closer to find out that these things both look kind of similar, but they're really very different. And then if you try to solve them with the same solution, you're going to end up with lots of extra complexity. So the well-meaning idea of simplifying things, or building them once instead of twice, actually leads to something that is ten times as large and doesn't solve the two problems as well as two separate solution would. I think that is a very common thing, so I completely agree on that.
Stefan Tilkov: Is it also a matter of people's status, or of managers' background? How much of a human thing is it to want those large things, those large projects?
Christin Gorman: There are all sorts of drivers, of course. If you're this project manager, there's far more prestige in having led this platform that revolutionized the healthcare industry, or whatever. There's far more prestige to be in charge of that, rather than saying "You know what - I'm going to work on this particular application that helps nurses in nursing homes." That's not as prestigious. So there's definitely that.
Christin Gorman: But also, another huge problem is so much of -- you know, the people in management have lots of... There's the management schools; they have a proud history, and a long history, and lots of very good educational programs, I'm sure, that teach people to manage physical projects. So I think lots of project management ideology comes from managing the construction of bridges, for instance... Which is a completely different thing.
Christin Gorman: When you construct a bridge, you're building this physical thing. You can't build the bridge halfway, and then say "Oh, well it should have been five meters to the left." That obviously doesn't work, right? So you have to have these long planning phases where you just draw, and you have nothing physical, and then when you're done with that, then you move on to the implementation phase. This causes so many problems when you try to do that within software, and you have this idea that you can sit in meetings with the users, and business people, and write post-it notes, and make all these requirements/specifications, you ask the users what they need... So you spend years and years doing all of that, building up this "We're gonna solve everything", and then you say "Okay, here, technical people, implement this!" This is a recipe for disaster, and we can talk more about why that is.
Christin Gorman: We as software people know why that's a bad idea... But the fact that so many managers have this old-school mentality of managing completely different things causes large problems, as well as the prestige element.
Stefan Tilkov: But isn't what you're saying just "Well, we should all be doing agile software development, and our problems will be solved."
Christin Gorman: In a way I guess I am. But what I find immensely frustrating over these last ten years - because it's been... Well, how long has it been since the Agile Manifesto came out? It's been like 20 years.
Stefan Tilkov: 20? Wow. Let me check.
Christin Gorman: But agile, the word Agile is just a joke now, because it's been taken over by people who use the word, and they think using the word solves the problem. I lost count of the amount of times that I've said "We need to work in an agile manner. We need to iterate, and we need to get feedback from actual users to drive the process." And people are like "Yes, but you can do that in the implementation phase." For Heaven’s sake!
Christin Gorman: It's like, everyone agrees that we have to be agile, but using that word doesn't really solve the problem. You have to understand what the word was meant to be, at the outset at least, because as I said, we don't have the same limitation within software. That's both a blessing and a curse, I guess. You know, we can build a bridge; we can build this tiny little string/rope bridge, and then we can expand that over into a motorway as we go along. We can move where it goes; we don't have those same physical limitations that they do in these physical projects... And not taking advantage of that fact is nuts. We can actually get started right away, and actually build something quickly, test it, validate it... Do users actually need this? And if they do, we can build on it, we can change it... We don't need this massive process where everything has to be decided upon upfront.
Christin Gorman: That's another driver that I just thought about for this complexity - because users have gotten used to this thing, that when they first get software, nothing changes for decades. So they know that if they're gonna get a new system, they'd better think of everything, because they know that they're not going to get any updates after that. So they're desperate to pour in every little bit of functionality that they can possibly think of. So the specification for what you have to build just grows and grows and grows.
Stefan Tilkov: So how much of a problem do you think it is that it's often not the users, but rather somebody who represents, or is supposed to represent the users? I think you mentioned this distance between the people who have the responsibility for building the software and the ones who actually use it. Is that part of the problem as well?
Christin Gorman: Yes, it's definitely part of the problem... And so much of my time has been spent on "Can we actually speak to the users?" The users, firstly, they are often separated in time from the development phase. So they are asked by business people like five years before the development even starts. That is so essential, to just get more direct -- that they can talk to the people in charge of actually building stuff while they are building it, so you can get the actual same functioning feedback loop.
Stefan Tilkov: So what has your experience been? If you get access to the users, do they actually work with the team, or are they reluctant to do that?
Christin Gorman: That's another big problem, of course. Most users, they have a day-to-day job. Their job is to actually do the work that you are trying to help them do better with new software... So that's a big problem, of course, that they don't have time to set aside to give you the feedback that you need. And also, most users are -- well, depending on what you're trying to make, many users are not very familiar with computer systems, and they hate the idea of software changing all the time. They find that immensely frustrating. So there's this conflict between -- you know, if you ask the users what they want, they will say "Just give me something that works."
Christin Gorman: Of course, that makes a lot of sense; if I could telepathically understand what the users would want, and just understand fully what their day-to-day problems are, that would be the best thing to do. But the only way for me - or a developer - to really be able to understand what is actually needed, we have to have a running conversation, and to try and fail a lot. I feel like half the stuff you do ends up being on a misunderstanding.
Christin Gorman: But for users, that's very often -- you can't just ask the user what they want, because very often when you give it to them, they will then realize that "Oh, actually that doesn't work at all, because of this, or that, or the other." It's very hard for both the users and developers to really fully understand the consequences of what you're gonna be building and what kind of problems it will be solving.
Stefan Tilkov: So we've had a good experience with paper prototypes and with early things that give users some idea of what it is that we think we should be building, and they can tell us "Well, that is a stupid idea. I can't use it like that." And of course, it helps a lot if you do that before you start even building that first implementation, that they can actually use. Is that something that you've experienced as well? Is that something that you've used, this approach?
Christin Gorman: Yes, anything you can do to get feedback... But also, I see very often that people use that kind of approach to keep the developers at bay. "We'll use some paper prototypes. We'll do user testing with our mockups, and whatever... And therefore, you the developers don't need to be involved with the users at all." So that's an issue that I see a lot.
Christin Gorman: I think it's fantastic to use mockups, but the amount of issues that arise once you start trying to actually write code to support the paper mockups - it's essential that you really get to those as quickly as possible. There's so many things that can go wrong, and so many things that you don't think of, that only appear once you actually try to code it. Then you're like "Oh...!"
Stefan Tilkov: Yes, completely agreed. Maybe the value in those prototypes is to figure out what you shouldn't be building, more than what you should be. This fails even at this level. They see it for the first time, they can imagine that this is what it would be like, and they're telling you "That is not something that I need. I need something completely different. That's very valuable information."
Christin Gorman: Absolutely.
Stefan Tilkov: But I completely agree that you have to actually -- even for a developer, even if you pride yourself in your mental skills, and all of your knowledge of computer systems, you figure out things once you actually build stuff; once you have to build it completely, you figure out "Well, I've never thought about this particular corner case. What do I do here?" and then it helps the developers as much as it helps the users to actually build things, and then get feedback from that. I completely agree with that.
Christin Gorman: Yes. And I also think that it makes sense to have developers involved, even if they're not making the prototypes, but at least keep them in the loop. So much time is wasted often by developers coming up with ideas that have already been tested; then you end up discussing things over and over and over again. So just process-wise, it makes sense to have everyone involved as much as possible. Even though developers aren't part of the early prototyping stages, just having some technical people involved early on makes a lot of sense.
Stefan Tilkov: Another thing that you've mentioned before, and I think you have a problem with that word - the word "platform", and this idea of having those big things that solve everything. Can you talk a little more about why you think it's a bad idea to do those big platform projects?
Christin Gorman: Well, first thing, again - when you're going to be building software, I think it's essential that you step back and think "Well, what am I actually trying to do? Who am I actually trying to help?" The only reason we build software is to help users do something. And I've never heard an end user, like a nurse in a nursing home - they've never said "Oh man, I just wish I had a platform." The end users - they don't need a platform.
Stefan Tilkov: "With a microservices architecture!" Sorry.
Christin Gorman: They don't need these things, you know? So we need to focus on what people are actually building. And if what you end up building turns into a platform, then that's fine. But the point is, I think it's very natural for people -- if you are in charge of a full portfolio, lots of different applications, you're selling software, or you're buying software, or whatever, if you're in charge of lots of stuff, it's very natural for you to think "Oh man, wouldn't it be easy if I just had a platform for all of this stuff to fit nicely in?" But you have to consciously and always try to get out of the mindset of what's comfortable for you, and to focus on what's useful for the end users. And the end users - they don't need that platform.
Christin Gorman: I don't necessarily have anything against platforms, it's just that that should not be your end goal. Even Apple - they have a huge platform now, with the App Store, and all this kind of stuff; but they didn't start off making a platform. When they started making the iPhone -- you know, I heard a podcast where they were talking about the process, and their main focus was "We need to build a phone that works, that has enough functionality for people to actually have a working telephone device, with some cool extra features." And then the platform kind of grew from that. That's how you build platforms.
Christin Gorman: And again, what I've been arguing a lot when it comes to public healthcare systems - even as a developer, you don't necessarily need things to be in a platform. What you need is for various parts to have good APIs. You need to make systems/services that have APIs that you can call.
Christin Gorman: The project I'm working on right now, we're building a -- well, a platform, you could call it; it's a web application so far...
Stefan Tilkov: Guilty!
Christin Gorman: It's kind of a web shop, but it's for local, niche stores that don't have the resources themselves to have a web shop, and to put all the efforts. We have this kind of common thing, so people can get their goods delivered, same-day delivery to the local area. So it's basically a platform for local stores to put their wares.
Christin Gorman: And of course, we're integrated with Stripe for payment, and we have to send emails, and we have to send SMSes... So we are integrating with lots of different services, but none of those things are on the same platform. And I think there's lots of people, especially businesspeople, who are buying software - they think that in order for things to work together, it has to be on the same platform, and that is just not true.
Christin Gorman: Even if we had a platform that had payment solutions, and email services, and SMS services, even if that were on the same platform, there would still be different API calls, right? Sending an email is not the same thing as sending money to someone.
Stefan Tilkov: From the ivory tower, it looks very similar to me.
Christin Gorman: There's too many people who are way too far removed from the actual coding aspect, from making decisions... And they think that they're helping people like me, who are writing the code - they think they're helping me by building these platforms, when I don't even need them. Who needs them? The user doesn't need them, I don't need them... I mean, if they evolve naturally, then fine; but again, we have to make sure that there's an actual need for it.
Stefan Tilkov: But it sounds a bit as if it's always management's fault. Is it always management's fault?
Christin Gorman: Yes!
Stefan Tilkov: Okay... Done. Thank you. No, I mean, isn't it also sometimes developer or architects who overcomplicate things and create huge disasters in terms of size and complexity?
Christin Gorman: Definitely, of course. This is a human issue, we see things from our perspective. Me as a developer - and I keep catching myself doing this all the time; the user says something completely sensible that they want, and I'm like "No, because that's gonna ruin my code!" We have our own perspective of things. We go to a conference and we learn about this new technology we wanna try out... We have these technological visions about how cool it would be if all the systems worked together in this or that way... So yes, definitely, this is not a management issue at all. I think that everyone involved in building software needs to actively, on a daily basis, just slap themselves in the face and go "Hey, it's not about you! It's about the user." What do the users actually need? It's not about the beautiful code, or the wonderful architectural diagrams, or the prestigious, big project... It's about "Why are we doing this?" That should be the purpose.
Stefan Tilkov: Okay. What role does size play? How important and what kind of effect does the availability of resources -- and maybe it's not even size; the resources in terms of people... I shouldn't be using "resources" to talk about human beings, but you know what I mean, right? We're in the enterprisey world after all, right? So what's the effect of resources, whether they're human, or financial, or whatever, on projects?
Christin Gorman: I think in every dimension it's super-important that we cut back. One of the projects that I've been ranting about on Twitter a lot, this healthcare project - they've said "We have ten years, and we're gonna spend 22 billion NOK"
Stefan Tilkov: How much is that in --
Christin Gorman: This is a complete disaster from the outset. If I give you ten billion Euros, you're going to be thinking "Oh, how do I spend the ten billion?" You're going to spend those ten billion Euros and then come back and ask for more. If I give you ten thousand, you're going to have to be a bit more clever and focus and prioritize.
Christin Gorman: So for all sorts of reasons, it's super-important that we do not just start off with these ten years, and umpteen billion. You have to limit time, limit the budget, and also limit the number of people. The more people are involved, the harder it's going to be to work. Listen to me - I'm chattering on, I have lots of ideas... The more people like me you have to deal with on a daily basis, you're not going to get anything done. People are just going to be arguing and talking and trying to figure out what to do, instead of just working effectively. It's super-important to cut down size in every possible aspect, as much as possible.
Stefan Tilkov: What kinds of ways have you seen being successful in coordinating the work across multiple teams? My idea would be that if you have this huge thing, then you could do it with 500 people, or you could decide not to do that; cut it back from 500 to maybe 100. But 100 is still way too much for a team, right? Because a good team size is 7, 8, 10 people, something like that...?
Stefan Tilkov: Let's just assume that somebody has allocated way too much budget, like those 10 billion Euros, or dollars, or whatever; they've given the project ten years, which is way too much time, and they've assigned 500 people, which is way too many people. So we cut it back, but we can't cut it back to just ten people and half a year, because it's too complex for that. It's not a simple thing; it is a complex thing. Maybe it's a healthcare system, which is hugely complex; or something to do with tax law, or some complicated life insurance, or whatever thing. It doesn't matter; something complicated, that has lots of actual complexity. Not accidental, not homegrown complexity, but actual business domain complexity.
Stefan Tilkov: So let's assume we can cut it down from 500 people to 100 people, and from ten years to two years. Then we're going to have those 100 people not in one team, but in many teams. How do you coordinate them without doing something that, again, becomes way too enterprisy and complicated to get stuff done?
Christin Gorman: This is, obviously, not a trivial thing... But again, if you focus on the end user, it doesn't have to be that hard. The software that you're building - it's going to have to help someone do something. And there's just no user that has needs for a software system that requires billions -- if you look at what a single person actually has to do, and tasks that they have to perform, it is normally not that hard to find divisions of labor that can focus on actual needs.
Christin Gorman: If you think about the things that have been massively successful when it comes to software systems, they're always the smaller ones. Email - sending email is super-simple and limited. It's like a To, and a From, and text, and attachments. There's lots more complexity involved, of course, but because it's so limited, it is also way more useful to far more people.
Christin Gorman: You need to just break it down into things that people actually need, and not worry so much about -- you know, my email client looks nothing like my IDE for writing software, but that's okay. We need to stop worrying about users having different-colored buttons... We need to find ways of limiting collaboration between teams, basically. Try to say "How can we avoid that these people have to talk to each other? How can we let them work in peace, and really develop something that is useful on its own?" Again, sending messages here or there, of a specific type. Or doing some concrete thing.
Christin Gorman: In my experience, it's not necessarily that hard to find reasonable, sensible divisions of labor when you look at what the actual needs of the actual users are. It's only when you look at things from the developer's perspective, like the person who's responsible for the technological platform; or if you look at it from the management's perspective, where it's like "Oh, I'm in charge of everyone working at the console level", or something like that. That's when it becomes complicated. If you look at who's actually going to be using what, then finding sensible divisions of labor is perfectly sensible.
Christin Gorman: And again, the clue here is we need to find ways of dividing things so that the teams don't have to collaborate all the time. You have to have loosely couples and highly cohesive team units, that they can deliver functionality without having to coordinate with everyone else. I shouldn't have to ask three other teams "Can I release this now?" I should be able to work effectively and deliver value without having to coordinate with everyone.
Stefan Tilkov: I completely agree. In fact, we've been advocating something quite close to that. We've been advocating that each of those teams gets release responsibility for a system or a set of systems, and doesn't have to collaborate on the same system with other teams, because that of course means they have to coordinate all the time, and figure out a way to solve both sets of problems in the same system, as opposed to having two... So this idea of accepting a certain degree of redundancy - redundant code, redundant data etc. - with the goal of increasing autonomy, is something that I think many people have discovered independently, sort of at the same time... Because this fact that things don't move fast if you don't do that has become obvious to many people. So I agree with that.
Stefan Tilkov: I was wondering, while you were explaining this, whether we could turn this into some diagram, some typical consultant diagram, or a law, or something... But it seems to me that if you want to become more generic, then the cost of that increases maybe with the square of the increase of genericity when you do that. For example, you could build a text processing program; you could build a competitor to Microsoft Word. I don't think you can build a competitor to Word in six months with three people. There's tons of stuff in there. Or maybe Excel, or a browser, or something like that. It's a huge amount of knowledge and technical expertise that went into each of those things, because they're hugely complex things.
Stefan Tilkov: And they are very widely usable... Almost everybody has a use for one of those things. I can use a spreadsheet for all -- 90% of the things that I do with a computer, I could do with a spreadsheet. So it's a very generic piece of thing. But it also costs a shit-ton of money. It was an incredible investment to do that, and most organizations don't have that kind of money, or don't want to throw that kind of money at anything. It doesn't make any sense, because they're not building a software product for a few hundred million people. They're building something that's being used by (I don't know) maybe 10% of the citizens of this country; that is still not the same thing as a text processor, or something like that, that would be used by hundreds of millions of people.
Christin Gorman: Absolutely. It's also important to realize how long has Microsoft been working on Excel and Word...
Stefan Tilkov: Exactly.
Christin Gorman: They've been working on this for ages. So yeah, definitely. So much work has gone into that. Also, as developers, we need to leverage Excel to a far higher degree. That's one of the things that I think can really, really give enormous cost savings in lots of projects - if we just say "You know what? We're going to make a system that solves 90%of your most common problems. 90% we can automate. We can make this super-simple. But then the remaining 10%, that are a bit complicated, if we don't have to pull that complexity into what we're making for you, you can still use Excel to solve those things."
Christin Gorman: I think that's a really good technique to start off. You don't have to wait until every possible feature that anyone has imagined is in place. You can start off by solving the most common thing, and then let people -- if they're already using Excel, you can at least take that in steps. First of all agree you'd still be using Excel for some stuff; the next delivery even more stuff would be taken out of Excel. But maybe some things... Don't -- you know, if that's what they've been using to organize their work, maybe we should at least have that as an option. If they need to do some weird and wonderful thing once every five years in Excel, then that's not the end of the world. And instead of spending billions dragging that into an already complex system...
Stefan Tilkov: The platform! It should be part of the platform, right? Every decent platform should have a bad reimplementation of half of Excel.
Stefan Tilkov: Yeah, I agree. Maybe sometimes we should be -- a colleague of mine wrote an article about that; I can link to that. I think sometimes as developers/architects/technical people helping decision-makers make good technical decisions, we should be the ones maybe arguing for not building software at all...
Christin Gorman: Yes, absolutely.
Stefan Tilkov: ...because many times it's a very bad idea. "Well, don't do that. It's not a good candidate."
Christin Gorman: "Use a Google Form", you know?
Stefan Tilkov: Yes. Yes, exactly. That sounds like a Trello board to me. If you ask me, that's a Trello board.
Christin Gorman: Yes, totally.
Stefan Tilkov: Or a WordPress installation.
Christin Gorman: Absolutely. Or Sticky Notes. There's so many things you do not need software for.
Stefan Tilkov: Yes, I completely agree. Okay. So while we're ranting, I don't think we've talked enough about vendors. What role do vendors play in this whole thing?
Christin Gorman: Yes, this is a big problem, of course, because you have all these large, like SAP, organizations; we've found they can't possibly know the domain of all the various companies in the world... So they start to think "Well, what can I sell? I need to make something that I can sell no matter what their actual problems are." So basically, they sell just glorified programming languages; it's this own system where you can configure and make your own software within the platform. So it's super-configurable. But anyway.
Christin Gorman: I don't know what we can do with them, but from a technical point of view, it's so obvious that to get them to work you need an enormous amount of customization to make it fit the domain it's for. And I think people just don't realize that customizing software and writing software are very much the same; it's a similar kind of thing. If you're gonna be customizing it anyway, you might as well use the best tools for software customizations, which is actually code. Writing code is far more effective than doing the same thing within a platform... I don't know.
Stefan Tilkov: Yes. We've probably all seen those projects where the customization of a piece of standard software was more expensive than we could ever imagine. A customer-specific -- not rewrite, but a customer-specific, bespoke custom solution would have been... If the customization project cost 100 million Euros - well, I can build the whole thing for 10.
Stefan Tilkov: Of course, that might be just developer arrogance, like "not invented here" feelings. "How could they possibly spend this amount of money?! I could do it for a tenth of that." Lots of developers will think that way. Maybe not everyone, but lots of them. So that could be one part of it.
Stefan Tilkov: Another factor is the risk part of things. People think it's less risky to go with the standard software... Which I don't think is --
Christin Gorman: And this is the thing - it's not standard software. This is the thing with those platforms. I'm all for buying standard software. Stuff you can use off the shelf is fantastic. Anytime you can use something off the shelf, go for it. You should definitely use off the shelf where you can. But if you have to spend millions customizing it, that is not an off the shelf product. You need to just realize that you're not getting off the shelf. You're just buying a very ineffective way of customizing software. It's the most ineffective way of writing software ever. Arrghh!
Christin Gorman: So yes, we need to somehow -- I don't think I'm the right person to convince management people about this, but somehow we need to get the word out that this is a con. It's a complete con for so many people.
Stefan Tilkov: Yes, probably there's a breaking point, at a certain level of customization. Obviously, a little customization is fine, because you don't have to customize everything. But there is a certain point where it turns into actual custom development, where as you say, you get all of the problems associated with that. Problems with updates, and inefficient development tools, you can't find people who know this stuff, and you specifically can't find good people who know this stuff, because the good people don't wanna do that kind of work, and all these problems.
Christin Gorman: Yes, and you can't upgrade it to the latest version because your customizations are incompatible with the new version...
Stefan Tilkov: Right. So all those things happen, but they happen after a certain point in time. It's always hard to, in the beginning, find out whether you're in that range or not. Because every time you have a -- and I've been to many of those vendor meetings for our clients. I've also been involved in making those decisions, sometimes for ourselves, for our own company... You have to make the decision, while you're still completely ignorant of what it is that you need and how well that is actually being handled by that piece of software, because the vendor only has one answer, that is "Yes, of course. Of course it can do that. Sure, no problem." Everybody does that. And then you start the project, and those projects are very hard to do in an agile fashion.
Stefan Tilkov: You don't typically do a customization project in small increments, where you get user feedback after a few weeks. That's not how they happen. They typically happen with a lot of planning, with a lot of (like you say) the construction site work, the classical project management was very good match for those kinds of projects, and you spend a lot of time thinking of what it is and gathering requirements and then spending on all the customization thing... And then you run into that sunk cost fallacy, because after all you've now spent two years customizing the damn thing, so it should better give you some return on investment, otherwise you'll look really bad... So I think there are not many people who actually love their customized standard software. They're not very often very sexy.
Christin Gorman: No, I've heard of very few. And I think the ones I have heard of have been the managers who worked with it in the first place, and they have every incentive to make it sound great, but end-user-wise it's a complete disaster, typically.
Stefan Tilkov: Maybe we can postulate that if end users are happy with standard software, then it's always the kind of standard software that hasn't been customized. We could test that. Maybe our listeners can give us some feedback on that.
Christin Gorman: Yes, verify that.
Stefan Tilkov: I would claim, there is awesome standard software that many people like and love, and they would much prefer it to whatever custom solution their company has... Because many individual software solutions, many custom software solutions suck, and have a horrible UI. They look as if they have been built 20 years ago because they have been built 20 years ago... And you'd much rather be using whatever Google provides, or Apple provides, or Microsoft provides, because it's much nicer, and modern, and fast, and it looks as if it could do the same thing.
Stefan Tilkov: But I haven't yet heard anybody say that of one of those enterprise resource-planning systems, or supply chain management systems that took two years to customize before they -- nobody has ever told me that those have sexy UIs, and that they like using it, and prefer it to custom solutions. I'm sure about that.
Stefan Tilkov: I want to ask you one other question, which I think possibly might lead to criticism of everything that we do, which is "How sure are we that people's lives actually are improved by software?" I'm not even saying that people are involved in the decision-making process about the user interfaces and the way to do things; I'm questioning, even if it's usable and pretty and has a good user experience and stuff like that, how often do people actually ask whether their life or that job has improved after this software has been introduced?
Christin Gorman: Yes, I think this is so important... I just saw Microsoft are now rolling out this surveillance tool thing as part of their Office365 thing...
Stefan Tilkov: I think they've just apologized a few hours ago, so this might be old news once this airs... But I don't know.
Christin Gorman: Okay, thank goodness.
Stefan Tilkov: But I know what you're talking about, so maybe you should explain it to the listeners; maybe some have not caught on the debate.
Christin Gorman: Yes. Basically, part of their Office365 pack kind of rates you, gives you a score for how productive you are, and how good you are at interacting with your colleagues, and all that kind of stuff. There's so much software that is being built... This is obviously like surveillance stuff, which is problematic, but there's so many things that we build that just make people's lives worse... Like notifications. They're always like "Hey! Come look at your phone! Look at your phone now! Look at your phone! Keep paying attention! Buy more crap!" You know, tailored/customized advertising.
Christin Gorman: So much of the stuff we build is making people's lives way worse. We're selling products... I mean, the smartest people are being headhunted into marketing, and financial stuff that very often are not making the world a better place at all. And I really wish that we'd focus more on why are we even building this. Are we solving a real problem, or are we making that problem worse just so some people make money? And I really wish that more people would say no to taking part in projects that obviously have a negative social value.
Stefan Tilkov: I think it's -- well, it's not an easy decision, but it's kind of an obvious problem if you have ethical doubts about the kind of project that you're doing. I don't know, maybe you're not a big fan of the military, and you're being asked to write software for some killer drone, or something. That's not easy, maybe it's not obvious for everyone; it would be kind of obvious for me, but people have different opinions on those things... I think that is one part.
Stefan Tilkov: Another part that I've found interesting is that sometimes you automate things, and when you automate them, you very often automate the business process as people want it to be. Not only managers; I don't wanna blame the managers again... But the people responsible for defining how stuff works actually mandate this particular process be implemented into software... When in actual real life things might be done differently.
Stefan Tilkov: In a doctor's office, the doctor's assistant might be doing some sort of work that she's not really allowed to do. She's maybe handing out recipes to patients who come in every week because she knows it's perfectly fine. This person gets it every week. You won't codify that, you won't make that part of a piece of software, because that would violate a rule. But because you have now implemented the rule, you don't leave room for exceptions. You don't give people the opportunity to do things differently than what's in the rulebook. And everybody has always worked around the rulebooks. Everybody has always done stuff that was not allowed, not strictly, but still somehow okay... And that's kind of a problem, because our systems don't typically have that option.
Stefan Tilkov: If there's a rule that says "Well, this has to be signed off by an actual doctor. It can't be signed off by an assistant, or a nurse, or whatever", then as a developer you would actually be doing something wrong if you implemented it differently. You have to implement it in the way that the law says it needs to be done, even though that doesn't actually help anybody... Because the poor person won't get their recipe this week, even though they need it. It's really complicated; it's not as easy.
Christin Gorman: Absolutely. That's another thing that I think we should be aware of. In many cases, the right thing to do is instead of preventing someone from doing something, highlighting that it might be problematic. In some cases we can't do that, but where possible, that should be -- in a way, let people do the wrong thing, but just show them. Flag this with a big, yellow marker and say "Hey, are you aware that this thing is not following the standard?" That might be a better thing to do, rather than saying "No. Computer says no."
Stefan Tilkov: Yes, I completely agree.
Christin Gorman: There's nothing worse than computer systems that actually prevent you from doing stuff, because their rules might change, too. That's another thing. If you let people make mistakes, and instead kind of highlight what you believe might be a mistake, then you make it more flexible in case people actually have to override it. Stuff like that we can do.
Stefan Tilkov: Yes. And I'm not trying to suggest surveillance again, but with this you could actually gather some feedback as to where your rule doesn't work. I mean, I have implemented this wonderful automated process, but nobody ever uses it, because it doesn't work for them. Why do they always take this shortcut? Why do they always do it by hand? Let's watch them, let's figure it out, and see "Oh, that is what we needed to automate, not that." That would be very helpful.
Christin Gorman: Yes.
Stefan Tilkov: Okay. We've talked so much about what's bad about those projects... Maybe let's talk a bit about what we could do to improve it. Of course, this will relate to what we've just talked about. So what's your best advice? How do we go about improving those projects for us?
Christin Gorman: Yes, there are so many things. But again, we've talked about this, just cutting things off. Just give up on this idea that you can have this one, unified thing that solves everything. Just break things down to "Which users do we want to help?" and then set up a team, five developers, some UX people, and just work with them, show them design ideas, implement stuff... Just start straight away talking to them and find out "How can I deliver value to these people as quickly as possible?" Don't wait. Don't have this like "Oh, we mustn't bring--"
Christin Gorman: I think that's another problem - people don't have developers in-house, and that kind of leads to them "Oh, let's wait until we have enough to do before we actually start with the development thing." We really need to get away from that. Get technical people on board straight away, along with UX and design and whatever... But everyone, just talk to the users, sit next to them, sit in their offices - when Covid allows us to... But anyway, focus on end users, break people into small teams, and start straight away.
Christin Gorman: For business people - they're always wanting "Well, how much will this cost? How long will it take?" Just set from the outset, "This is our budget for a limited time." Limited budgets, limited time, because that focuses you. Then you are thinking of "Okay, what can I do within the next six months? What can I even do within the next three months?" Limit stuff to smaller units. it makes so much sense in every possible dimension.
Christin Gorman: And this sounds like such a no-brainer; I feel like an idiot, because why do I even have to say that? And again, from what I've mentioned already, this is how I worked when I first started, for startups, because this is the natural and intuitive way of thinking about these things. It's kind of sad that, for some reason, once things go professional, then people go away from what is intuitively right, from the outset.
Stefan Tilkov: Let me follow up on one thing that you said. We're both working for consultancies, so we ourselves make money working for projects like that. But you mentioned that people should have their own developers. And in fact, I strongly agree. So I would claim that the number one thing that I would advise - if I had anything to say - the public sector should do is to get in-house expertise. Find a way to pay developers actual competitive salaries and get some actual technical expertise in-house to make better decisions. Would you agree with that?
Christin Gorman: Yes. Having your own people in-house, that know what they're talking about... Not least just so you're capable of hiring the right people... Just knowing who you should get. Because finding the right contractors to help you is gonna be a lot easier if you already have some kind of technical expertise, so you know what to look for. So yes, definitely.
Christin Gorman: And again, this should make sense to everyone. If what you are building, if your service depends on computer systems in any way, shape, or form, then writing software is part of your core competency as a company. And not having the capacity to make your own product - that's crazy.
Stefan Tilkov: I could agree more.
Christin Gorman: Especially in the public sector - there's not gonna be a marketplace for implementations of the Norwegian tax code. There's not gonna be a marketplace where they can buy Norwegian tax regulation stuff. This has to be made by the Norwegian public sector. They have to own this. So that's a no-brainer.
Christin Gorman: Actually, the project I'm on right now, there are no in-house developers on at all, and we are nine people now... So it is possible to get people in. But again, we're like ten people in total. That is the entirety of the project. So hiring in people if you don't have them on board, that's fine, too. But just don't let them take over completely. You don't wanna hire a consultancy and then have them show up on day one with like ten Scrum teams, with seven people in each...
Christin Gorman: As long as you maintain control of the process, it's perfectly fine to get in external people, but control what you're making, and have some idea of where you should be going with it.
Stefan Tilkov: In Germany, the public sector has managed to create a market by building the same thing many, many, many times. The federal state, the decentralization leads to the fact that everybody makes their own decisions, so everybody hires somebody else to do the crappy system. So we've got tons of crappy systems. I shouldn't be ranting about that particular aspect...
Stefan Tilkov: But again, I think we agree on that. And as you said, it's a general rule, no matter what the organization does. It's not restricted to the public sector, it's restricted to any organization that does anything that depends on software, which basically is almost everyone. So almost every company, every organization needs this in-house competency, even though we kind of make money because people don't have it... I guess we would be making money even if they had that capacity. I think some contractors, some companies, some consultancies who depends on their lack of knowledge would maybe have a problem, but we don't have to worry about that, so that's fine.
Stefan Tilkov: Okay, enough of the self-aggrandization... So what about the other vendor aspects? What about the platform vendors, and commercial off-the-shelf software vendors?
Christin Gorman: Here, again, if you have your own in-house people who know what development means, if they know what's possible to build, actual software development... And once you know what these platforms can deliver, then I'd feel much safer in that they would take rational choices. The problem now, the reason these vendors are able to sell in these systems is because they're selling it to people who have no idea what the alternatives really are. They just don't know. Again, what I'm selling is basically "Just don't buy the platform." That's not a product.
Christin Gorman: So you have someone who sells everything, and then you have people who say "No, no, no. Don't buy everything. And of course, buying from the guy who says "I can give you everything you want in one platform", that sounds a lot better. But I guess just education, and having people internally who understand this. I think that's the only antidote, really.
Stefan Tilkov: Okay. I think this was an awesome conversation. We've hit on most of the things that we wanted to talk about... So maybe for some final notes, do you have some resources that you would like to point people to? What are good things to read or check out if people wanna find more help, or find more rants?
Christin Gorman: I've just finished "Seeing like a state", which is an amazing book that I think everyone should read. There's nothing about software there, and it just shows how we as human beings have trouble. Again, the title of the book, "Seeing like a state" - it's how we struggle trying to implement these huge projects that do too much at once. It goes through everything, from scientific forestry in Germany, in the late 1800s, where they decided that "Oh, we want organized forests with just spruce trees, that are spaced just so, and have no other plants around, because we don't want any mess. Very organized, nice rows of trees." This worked brilliantly for 20 years, and then the whole forest died, of course, because you need that underlying complexity. Things aren't that simple.
Christin Gorman: There's just tons of really interesting examples from all over the place. You have communism, you have forced resettlement schemes in Africa... It's a really interesting book about how human beings try and fail, again and again, in every possible domain, when we try to do too much at once. So a super-interesting book, "Seeing like a state."
Christin Gorman: But for more software/technical stuff, I recommend Accelerate, which is just a book looking at actual companies out there, and measuring the quality they're delivering, how fast are they able to work... These are real facts about what works and what does not work about software. It's a very interesting book, and it just shows how to organize things and how to work effectively.
Stefan Tilkov: Okay. I would add one myself, if I may, which is the whole work of the British Government Digital Service, which I really like...
Christin Gorman: Yes, yes!
Stefan Tilkov: They've got lots of excellent resources about how they improved government IT, and some of the stuff that they wrote, some of the pages that they have published, some of the open source software that they did, and the open source guides are just fantastic. I read them, and I have a similar feeling as sometimes when I listen to your talks, which is "Ah, finally somebody says it!" So that's a good thing; they improved, they actually did quite a few things that are similar to what we discussed... So we'll put that in the show notes as well.
Christin Gorman: Yes. I wholeheartedly support that. There's wonderful reading material... And depressing reading material, if you happen to be living in a country that does not have sensible guidelines, like they do.
Stefan Tilkov: Yes, that is true. Yes. Christin, it was great talking to you. Thank you so much for being on the show. For our listeners, I think it was a very interesting episode; I know it was for me. Thank you very much, and have a good day.
Christin Gorman: Thanks for having me. Bye.
Stefan Tilkov: Bye!