insights! #74: from bugs to brilliance - optimising software development

Joubin Rahimi:

Brilliant that you're back for a new episode of insights! My name is Joubin Rahimi and today I get to welcome Ralf Trapp. Hello Ralf.

Ralf Trapp:

Hello Joubin.

Joubin Rahimi:

Yes, great that you are taking the time to share your insights today. You shared them with me and Wolly nearly four, five months ago in Bangkok at a summit held by the company NFQ. And I still remember exactly, we were sitting that evening in a street food restaurant and it clicked for me, because what you do and how you do it, I thought: "These are insights we absolutely have to share." And once you know it, it is actually so simple and clear, but usually you have to arrive at it first. So thank you for being willing to share your time and your insight here.

Ralf Trapp:

Very happy to.

Joubin Rahimi:

Right, before you start, maybe say a few words about yourself so everyone gets to know you.

Ralf Trapp:

Yes, my name is Ralf Trapp. I travel around helping mid-sized companies, preferably in the agency sector, tidy up their software development methods, in the broadest sense, and make them simpler and higher quality.

Joubin Rahimi:

And that was exactly an exciting topic, because we immediately jumped to tools, but you said tools aren't it. We'll get to your aha moment in a second. And we at synaigy also do a lot, but for me that was the aha moment you then had. So maybe you'd like to tell us where the journey began.

Ralf Trapp:

The journey began, it's been quite a while ago, I was at Oxid E-Sales at the time still as technical product manager and we were exactly in that situation. We had quite decent quality problems and, actually had, and then decided, okay, this has to change, this has to get better. And yes, the decisive moment, there were two key moments. Key moment one was that we started and after a while our development lead at the time, our chief programmer, who was one of the more critical people, said: "That won't work, we can't manage that, that's impossible." And then after a year, a year and a half, he came and said: "I can't imagine how it was ever done any other way," and I was like: "Yes, yes." And the second one, then, when we were finished with the whole transition, at that point I was also responsible for shipping the software. And the comparison before and after. Before it was more like: "Let's pray that nothing bad is in there and hopefully it works and hopefully nothing is really broken." And afterwards it was simply: "I haven't even unpacked the software further, I took it as it came from the development team and shipped it, distributed it, and was happy." Those were two moments where I think, that's actually how it should be.

Joubin Rahimi:

And it's still healing, so to speak. Oxid isn't exactly known for shipping buggy software now – that was, I think, a decade or a decade and a half ago. Quite a while back now. You laid a good foundation there in the process.

Ralf Trapp:

I'm actually still proud that we managed that, because from the very start it wasn't at all foreseeable that it would work. But I believed in it, we believed in it, and it did work out.

Joubin Rahimi:

So, hopefully we've all relaxed a bit now. And no, this isn't about the tools just yet, but about the people involved, right?

Ralf Trapp:

People, because that's where it starts. And I mean, we're all in IT, and I really think that, especially when you're dealing with machines, you forget that people are actually what matters most.

Joubin Rahimi:

Let's just let that sink in. And if the human is at the centre, how do you actually get a software developer there – who mostly, I don't know how it is at Oxid, I know it from project business and I know you also always get to co-develop a product, but that's also two decades ago now – it's a different way of developing software than when you do projects based on a product. But there too you probably have the topic of time to delivery, you have a release plan, things maybe promised. Developers then also always have a certain pressure, maybe want to knock things out quickly using tools. But how did you put people at the centre, and how does that then change the quality?

Ralf Trapp:

Well, once you're in a situation like that, it causes pain. Everyone feels it. Not just the software developers feel it, the customers feel it, support feels it, sales feels it. If you can't deliver the software quality you simply should or wanted to deliver, then it grates across the whole range of people involved with it. And I think, no, I'm firmly convinced, that it can get better, must get better, will get better, can get better, and that you ultimately win people over, so to speak, from behind. So what would it be like if we didn't have this pain? And that already gives you a motivation that there's something worth changing. Now specifically regarding software developers. I actually really, really enjoy working with software developers, actually coming from software development myself and still enjoying programming today. Nowhere near as well as all the pros who do it full-time, but I genuinely enjoy it and can really relax while doing it. And I notice it too, when you talk to software developers, you first encounter scepticism. Scepticism, like, oh great, here comes another consultant type who has no clue about anything. And the moment the software developer realises they're talking to a software developer, that's priceless. Then you notice, okay, now you suddenly have access to the person who actually does the software development. And then I also gain trust among the software developers. I spoke to one recently, also in a client context, and it was about a decision we had to make, and then the developer, who I consider very competent, says: "I'll do it the way Ralf says." I said: "Yes, fine." The basis of trust is there.

Joubin Rahimi:

But what do you say then? What do you do then? I want to get at this core. People are at the centre. You say you think from the result backwards, you can ship it without having to do anything else, everything automated. You're certain it simply works. But how do you then change the teaming and the setup? That's a change process in the minds of the organisation.

Ralf Trapp:

Yes, well if you look at situation I just sketched out, you have situation of developers where they spend, I'd say, large part of their time, let's say, fixing yesterday's bugs. Or other people's bugs, that's the thing. Or worse, fixing other people's bugs that someone else made. That means what's really fun about software development, doing new things, developing further, maybe trying out new, I don't know, new libraries, new technologies, you get to do that less and less. And easiest way to give someone a bit more motivation and say: "Look, how about if you could really focus much more, or to greater extent, on doing new things instead of fixing old ones?"

Joubin Rahimi:

Yes, you immediately get the yes there. That's annoying.

Ralf Trapp:

Honestly, no one will say that. Sales won't say it. Support definitely won't say it three times over, because they're the ones taking the hit on the front line. Developers certainly won't either. And ultimately, if you're a software vendor, or if you're on a project spending your time fixing old stuff instead of building new stuff, you're not earning new money either. No customer pays you for fixing bugs.

Joubin Rahimi:

Exactly. Okay, so you plant this idea in the minds of the software developers, so to speak, and they then say: "Right, now I'll do this, and then everything's great."

Ralf Trapp:

No, that would be nice. I always say: “Dear people, this is going to be a marathon, not a sprint, because once you're in a position where you're at full capacity across the board, in every team, you're overloaded. And once you're overloaded, willingness isn't exactly huge to say, on top of that overload: ‘Right, now I'll add something new on top.’”

Joubin Rahimi:

Exactly, what's your experience? Or do you say: "Cut, we need to push through now and simply not do certain things, so we have time"? Or do you say: "You need to push through there"?

Ralf Trapp:

It's more about "gritting your teeth, but with backing from upper management, if you will, because that means something falls by the wayside further back. That means either we now have to scale back the already relatively low output of new things for a while, or even stop it completely in the worst case. Because ultimately it's about clearing up out of an overload situation, to free up capacity again so we can get back in later.

Joubin Rahimi:

In my head, a puzzle piece forms. You've set your sights on the goal, and you bring everyone along. Everyone knows this is another extra mile, but they've probably heard that countless times already. Now we're doing clean-up days again, we're doing a spring clear-out again, whatever you want to call it. Why does it work better now? So what changes in the setup when you're involved?

Ralf Trapp:

A good while back, I don't even remember in what context, I heard the saying: think of the end right at the start. And if you actually think about the end of project-product – it's fairly irrelevant which in this context – what's actually the end of producing software? So the provisional end from a software production point of view? At the end of the day that's about some form of either deployment or shipping. So shipping, if you have a product, and deployment, if you're putting something online in some way. And you'll... I'm surprised again and again how many companies actually do this deployment by hand. By hand meaning copying individual files from A to B. And if you do that across many systems or across multiple clients, in project business you typically have an entire client base that you supply with software updates in some way, and you copy your software, file by file, to the target system, then you end up in real trouble. And the probability of something going wrong is, I'd say, eventually. It's not a question of whether it happens, but when. And if you now keep that image in mind, or put that image into people's heads, imagine this runs fully automatically, without anyone touching anything. Nobody needs to log into any server via FTP any more and copy stuff back and forth, or log into a server and do configurations there. All fully automatic, and working backwards from there. What do you need for that to work at all? First you have all the deployment mechanisms, that's where we're a bit into the tools, but that's so to speak the downstream effect. But before that you need to be sure the software holds up. You actually need to put placeholders into your deployment routines, so you insert variables, IP addresses, server names and so on? Yes, that's one thing, but no, ultimately, if you deploy fully automated, without anyone actually "really doing" anything any more, then you need to be sure the software holds up. That means, before the deployment mechanism, you need the tests. And now you're unfortunately in the situation where software quality is poor, because typically you probably don't have proper tests. Or, as is also often done, some Excel wallpaper that poor souls then have to work through and fill in. And if you say, okay, with the software you currently have – you obviously need to be sure beforehand that it's feasible, that you look at the software and say: "Okay, I'm confident this can be done" –, imagine this were automatically deployable. Now we're here and that's where we want to go. And if you take that thought with you, then you actually have quite a lot of power in the team too, people who say: "Yes, that works." The odd sceptic, well most people are sceptical at first that it works. In project business by the way, I've been away from the product side, from Oxid, for a long time now. In project business by the way I've also often heard, regarding Oxid installations, that you can't deploy that automatically. I happen to know it works, because we just did it recently. So, if you can develop software, hubs I fortunately have, if you know about DevOps principles, about servers, I've seen quite a bit in the last 32 years now, then I can also judge fairly quickly, does this work or not? And if I say it works, then it works.

Joubin Rahimi:

Quite funny, because I just had to check something afterwards here. That's why my gaze just drifted away. I once got to help develop a product. I think that was about 20 years ago. Company Living Systems. And by then I already had a few years under my belt in software development. Extreme Programming is probably a term you know too. I don't even know if the term is still really current in the market or among programmers. But what you're describing, we write the tests first, then we develop, we run it against them. We were already doing that back then and I have to say, thanks to Rolf F. Katzenberger for that. Very smart mind, but extremely clear with all the pros and cons. If someone is extremely clear, he had this thing set up that way as overall product owner from the start. That reminded me of it. What's exciting is that this is still such a topic and that you say you have to bring people along. That means somehow Extreme Programming, this pair programming, unit tests in advance, is nothing new. But the success you're having in this shows it's still totally necessary. So the question: What's your assessment? Why is that? Why haven't we got a better handle on this from a craft perspective? These are all logical people we have there.

Ralf Trapp:

Yes, I think there is, I'd say, software that's built up that way from the start. That is, I'd say, certainly not in my focus as a target group. Logical. But there's a lot of software especially in the agency sector too. And what used to be web agencies, they all more or less do software today. And that means they actually come from, I'd say, the advertising industry and have washed over into the software world.

Joubin Rahimi:

Well, good explanation, yes.

Ralf Trapp:

And then of course you have, from that perspective … I mean, look at it from the advertising perspective. At least the experience I've had: when you work with an agency, reusability isn't really designed in that much. I mean, they look from campaign to campaign. And once the campaign is finished, the next campaign gets made. You might be able to reuse one or two things from the old campaign, but continuous ongoing development doesn't really happen. And if you build software from that perspective, you're not looking at sustainable software development. Sooner or later you end up bolting bits on here and there and there, and eventually you run the thing straight into a wall and nothing works any more.

Joubin Rahimi:

And what you're saying there is, by the way, a hugely important insight for managing directors when choosing an agency. Because as you put it, we don't come from the advertising side. We're also a digital agency. Above all, we have people who studied computer science and actually wrote real software. And we have a lot, so what you're describing, I say: "Yes, great, we can tick that box too." But that makes it much, much clearer that of course the niche you're describing, we see very often. Those are the ones who offer cheap pricing, do the first project. We're always in the more complex environment, often with really great slides, and then after 6 to 12 months the customer says: "Yes, that was somehow a bad move. The integration with the ERP system still doesn't work and now we need to switch agencies after all." That's how we get a lot of our customers, not in the first pitch at all, but often in the second pitch. And that makes sense. And I think that's another important insight for managing directors or decision-makers, to look at where the company comes from and whether it can really deliver the complex work that's typically demanded nowadays.

Ralf Trapp:

Depends on what you want as customer, of course. Do you want a campaign with, let's say, one software landing page that does something and that you know you'll throw away afterwards? Yes, exactly. Or do you want web software that supports or perhaps even runs your business? And then, as a customer, I'd place very, very great value on the company delivering it to me also knowing how to set it up so it still works in one, two, three, four, five years. And there's another aspect from the customer's perspective. If you have a business today and you want to run or support that business with web software, you won't just set the software up once and have it last the next ten years. That means continuous further development is necessary so you can simply stay ahead of your competition rather than trailing behind. That means you often need to be made aware that it must be part of your strategy that the software you're commissioning actually holds up and remains extensible, and that when I change something, nothing breaks. And that brings us full circle. That's exactly what we have in such a situation. You're afraid of every change because you can be sure something will break somewhere, you just don't know where yet.

Joubin Rahimi:

And I think that's a great closing thought, one that underlines the added value of your service, because it's no longer about having a quick profile online somewhere — nowadays business always runs via the web or through digitalisation, through the digital, and therefore requires a completely different level of professionalism.

Ralf Trapp:

Absolutely.

Joubin Rahimi:

Yes, thanks. If people said that was mega exciting, how can they get in touch with you?

Ralf Trapp:

Easiest way is to visit my company's website, procelo.ch. Linked directly below, exactly. And book an appointment there or call. Contact details are available throughout the website.

Joubin Rahimi:

Great, wonderful. Ralf, thanks for the insights.

Ralf Trapp:

Very happy to, Joubin.

Joubin Rahimi:

Thanks to everyone for listening and watching, until next time.

Ralf Trapp:

See you next time.