Tech on Fire: Jon Collins, Analyst, GigaOm

Today we have the second of our series of podcasts for Tech Trailblazers, the #TechonFire interviews, in conjunction with GigaOm. This time Jon Collins gives an engaging interview all about DevOps, given that he’s a specialist in DevOps for GigaOm having come from a background of starting off as a programmer.

Chief Trailblazer Rose Ross asks him all about the last 10 years of DevOps and how things have changed over that time. She also delves into what trends we’ll see in DevOps in the next 10 years, things such as the spread of GitOps, and how startups have their role to play in providing solutions for the future.

Plus, find out more about mental health and wellbeing in IT and how firms often only pay lip service to new development paradigms like Agile, but secretly just go producing products in the same old way. Watch the full podcast here:

YouTube:

Also available on

• Spotify
• Anchor

Interview transcript:

Rose Ross: Well, hello everybody, and welcome to the Tech Trailblazers Tech on Fire video/podcast. My name is Rose Ross, and I’m the founder and Chief Trailblazer at the Tech Trailblazers. I’m delighted to be with Jon Collins who is an analyst with GigaOm, who is joining us to talk about DevOps. Hello Jon, how are you?

Jon Collins: Hello, I’m fine. Long time no speak Rose, good to speak to you.

Rose Ross: Yeah definitely, it’s definitely been a while, but then we usually bump into each other at things like Cloud Camp and stuff like that and events. Unfortunately not been an opportunity over the last year or so.

Jon Collins: Indeed.

Rose Ross: So, as we were just discussing earlier, I thought it would be great for people who somehow don’t know you, to find out a little bit about Jon. So, who are you are you, and where do you come from Jon Collins?

Jon Collins: Well, how far back? I guess most relevant to this conversation is, I started as a programmer 30 odd years ago which is quite scary. And then I was very-very lucky, completely lucky; I had no idea at the time, this was a graduate scheme, but I joined a little company which happened to be doing most things right when it came to software process and so on. It was a subsidiary of Philips; we were building CAD systems. It was a tight ship, we were out in the countryside in Portacabins, using HP Apollo workstations. The quality was high, we had configuration management, we were testing things, we were building on a platform, and back then I read a book called ‘Peopleware’ by Tom DeMarco and Timothy Lister; you’re getting the full spiel here, it was all about how to do software writes. It fits in with those books like, The Mythical Man-Month, those sorts of things, it was one of that genre. I read it and I thought ‘well that’s all obvious, but it’s what people are doing anyway, so why write a book like that?’

I then went to another company which is a subsidiary of Alcatel and where we worked it seemed like every single thing that they said, ‘Don’t do it that way,’ was done at Alcatel. I ended up running the software tools and the development environments, it started as about 35 developers and ended up with hundreds of developers, hundreds of systems and databases, and all kinds of things and networks that I had to run. I ended up with a team of 10 people, and lots of stress, but it was it was just fascinating.

So, largely, I think that’s where I’ve come from, and I’ve worked as an analyst, as a writer, in tech over the years as a consultant, but interestingly with DevOps the whole thing has come full circle. So, I’ve gone back to the roots of what I spent most of my hands-on career doing. And I guess the first thing that I had to worry about when I started covering DevOps, about two or three years ago was – I’m gonna get found out, the world’s completely new, it’s all moved on, it’s all microservices now, everyone’s cool and everyone’s young, and I’m going to have nothing to add. And then I started to find some chinks in the armour, and I realised that a lot of the things that we were trying to fix back then, are still problems now. And just because it’s got a fancy umbrella title on it, like DevOps, or Infinity Loops, or CI/CD, or whatever it happens to be, there’s still a lot of work to be done, which is my starting point for the research.

So, I put a report together called something like Scaling DevOps in the Enterprise, it had a fancy pants title like that. But essentially what I meant by that was, here’s all the things that if you don’t do them, you’re always going to struggle to do DevOps at scale. That was based on loads and loads of interviews, finding out what people were finding easy these days, and there’s so much very different to what it was back then, like building on open source platforms, the Cloud, etc. But there’s still a lot of things that people are really struggling with. So that’s set my stall out for DevOps really.

Rose Ross: Well, that’s one of the things that Tech on Fire is going to look at because we’re celebrating our 10th edition, so we’re looking back over the last 10 years, and looking forward over the next decade. So, can you give us a little insight into some of those challenges, and that will probably go nicely into that whole startup conversation, because the startup world tends to be where people go, ‘Oh, there’s a problem, I’d like to fix that, and I think I could build a business out of that’.

Jon Collins: Yeah, and that’s so true, particularly true in the world of software development because it’s almost a self-fulfilling prophecy. The world of software development is full of developers, so when they spot something that they think needs fixing, they build something. If you’re in the world of enterprise apps, you wouldn’t create another enterprise app on the fly, or the world of storage, you don’t suddenly go out and get the soldering iron out and build your own storage. Whereas the developer world is full of programmers that are thinking ‘I can fix that, I need to sort that out’. And they’re building front ends, they’re building tooling and so on. So, that is a blessing and a curse.

I think the challenges for DevOps are in part created by that, in that when we look at the DevOps landscape, if you like, there’s literally hundreds of companies; there’s 248 at least, smaller/larger companies that are all doing something that would fit under the umbrella of what we might call DevOps. And then there’s a whole bunch of companies that don’t fit under that umbrella and have got no intention, they’re still quite happy talking about application lifecycle management, or requirements management, old school terminology, or stuff that just doesn’t fit in that world. So, we do have a problem of fragmentation in the tooling. But then, also, the fragmentation notion is the same word can be applied to what we see in the enterprise.

I remember one big bank saying, ‘We’ve got 5,000 pipelines, software development pipelines. That’s because we’ve got 5,000 products that we’re building, and each one has a different pipeline, so literally the way that we build each one is unique’. And one of the organisations we’re working with at the moment, they’re trying really hard to work out how to create common frameworks and standards. No company wants to be the best in the world, apart from software vendors. No big bank wants to be the best in the world at software pipelines, that’s not what they’re there for.

Speaking to an online travel organisation, they said, ‘We want to be famous for brilliant travel experiences. We don’t want to be famous for brilliant network engineering’, and it’s the same with this. So, a significant challenge is, there’s no standards, I take it off to the, hyperbole… there’s no standards, there’s no common frameworks, anything goes – it’s very chaotic environments, and that’s obviously overstating it, But I think realistically, where we are with all of this DevOps stuff is, there’s loads of highly-successful smaller projects, there’s a very small number of highly successful major projects, and everyone automatically goes to the Netflix’s quoting these massively successful cloud-first organisations, Twitter, Spotify, and so on.

But any organisation that isn’t cloud native, and you’re looking to get from small levels of success, pockets of success, to turning your organisation into digital first, cloud native, etc. yada-yada, there’s just this big gap without knowledge in it, it’s a massive gulf, and you’ve got to cross that gulf yourself at the moment. There’s no set agreed standard way of getting you from those proof of concepts that have been brilliant, to everything working brilliantly, and you being a digital first company. That’s the problem.

Rose Ross: So, how are startups over the next 10 years going be part of solving those problems?

Jon Collins: Well, every challenge is an opportunity in disguise, and the opportunity isn’t particularly well hidden. It’s sitting right out there blindingly obvious, I think. The nature of how we build applications is continuing to fragment, and that’s in part the way that it’s almost sorcerer’s apprentice stuff, I know that gets overquoted, including by me. But just because you can create something new, that doesn’t mean you should, but people still are. So, there’s new platforms appearing all the time, there’s new vendors appearing all the time, etc. etc.

At the same time, the alternative to chaos is order, and so the opportunity is how do we order this, and that’s a massive overstatement as well. But, the tools that we’re currently giving people are acting at a certain level, they’re helping people build things, but what they’re not doing is recognising that we don’t just need builders here, we need architects, we need planners, we need managers, etc. etc. and the tools available to those people, the other stakeholders, are lacking. So, there’s two things you can do, either… there’s possibly three things you can do because AI is always the third thing that everyone mentions; either you can make it much-much simpler, or you can provide better management.

By much-much simpler, either you take away the fact that things are so complex… so one big trend that we’re seeing is low-code, no-code, all of that kind of stuff, even RPA – Robotic Process Automation, and some of the platforms: Salesforce service now at one end of the scale, Appian, Bendix, the pure plate low-code providers, etc. they’re just making it easier to build things. And therefore, it if it’s making it easier to build things, it’s also easier to manage building things. One doesn’t necessarily lead on to the other, but the way that they’re doing things, it kind of does.

I could dine out on this for weeks, ‘Ex-programmer therefore…’, whilst I’m an ex-programmer, I recognise the value of building something with code. Equally, I recognise the value of building something where you don’t have to encode every single statement that needs to take place. So, there’s huge value in just a simplification of certainly the simpler tasks. And there’s probably an application of the Pareto principle there, which is low-code platforms could fulfill 80 percent of application requirements. If you want to build something that’s very-very similar to what everyone else is doing, you shouldn’t have to build it from scratch. So, there’s that end of the scale.

Meanwhile, the second pillar is, let’s make it more manageable. And I think we’re all seeing a wave towards more standardised architectures, then more standardised ways of managing things, and then more standardised tooling to enable that management to happen. So, through no fault of anyone, other than it just seems like a trend, it’s just the way everyone’s going. We’re seeing the container-based microservices target, with Kubernetes as the orchestrator. So, if there’s 5,000 different places that your application might end up in the structure, it might look; this is like, well, why not use that one? Why not build something using containers, and then you can deploy it using a vendor solution that plugs into Kubernetes engine, and then you can redeploy it, etc. etc. And then when someone else comes along, they recognise it, they know what to do with it because they recognise the microservices, they know how to build containers, etc. etc. So, that standardisation of architecture is taking place at the moment.

Last year, we saw 20 percent of enterprises we surveyed were actively deploying Kubernetes. A much-much larger number were actively pursuing the deployment of Kubernetes. Fast-forward a year, the next thing that comes out of that is things like GitOps which is, ‘Right, you’re deploying in that way, how about we standardise how deployment looks’, and that’s GitOps. From that you then go, ‘Well, if we’re all going to follow GitOps…’ and GitOps, which involves storing configuration information for the deployment in the same place as the code, and then you get an orchestrator to pull the information about how the application should be configured, from the same place as the code, in the same way a compiler would. So, you’re never thinking about ‘will this deploy?’; the deployment engine is doing that for you. And then if there are any changes post that happening, because someone’s gone in and tweaked the deployment, then an alarm goes off, ‘Ah, you need to fix that’, it needs to go back, and their configuration information needs to be updated so that they’ve got this closed loop thing going in GitOps, so that you can run entirely virtualized applications in code and everything is stored in Git under configuration management.

So, that’s a really-really positive development, and the result from then is that vendors across the board think, ‘Well, if they’re doing it, we’ll do it’. So, we’ve worked to kick this kind of thing off, then you’ve got Microsoft who are really keen, IBM are really keen, loads of other vendors, Codefresh are really keen, GitLab are really keen, they’re all talking about GitOps now, and suddenly GitOps becomes a standard way of doing things, which is fantastic. So, that’s kind of groundswell stuff.

Then from the top down, there’s a kind of – how to put this politely – a kind of ‘Oh, for crying out loud’ moment from a manageability…

Rose Ross: That was very restrained actually.

Jon Collins: Thank you, thank you, I appreciate your thought!

So, from a manageability perspective, there’s a point of no return, we can’t carry on going this way, in terms of just building more and more things, less and less efficiently. And from that need, we’re seeing a lot of interest at the moment around manageability capabilities. So, that means tools that go to the people overseeing development, that then helps them specifically identify bottlenecks in development – we’re building, and building, and building and everything’s arriving at testing, and then testing is really slow. And so it’s just ending up with this glut of things that need to be tested, and then we all have to stop for three weeks while testing happens, those kind of bottlenecks.

There was a lack of tools to enable people to see that, and then know what to do about it. But then value stream management emerged over the past couple of years as a technique, which in layperson’s terms it’s kind of let’s apply business process optimization to software development; it’s all about looking at something, working out where its inefficiencies are, and then improving it at the process level, but doing it specifically for software development. So, value stream management tools, a lot of them like IBM’s UrbanCode Velocity shows everything as little bubbles in spheres moving through. So, you can see one sphere full of little bubbles and the next sphere empty, and you kind of go ‘Ah well, we’ve got a bottleneck between those two spheres’. So, very easy visual mechanisms for managers and more senior roles, to see where and how they need to improve things.

Other tools like Tasktop are coming and thinking of things like, are developers happy? We’ve got everyone working really well, but everyone’s super-stressed, this can’t be right. So, just basic stress levels can also be monitored. And then the masterclass of value stream management is, ‘great, we’ve got everything working super-efficiently but the results are useless’. So, we’ve delivered 3,000 functions over the past six months but no one wants them. That’s not increased our sales, that’s not increased our levels of customer satisfaction, and it’s just a bunch of shelfware. So, the masterclass of value stream management is saying, are we building things of value? Are we delivering things of value? And then are people getting value out of them?

And so VSM (value stream management) is clearly a big thing at the moment, you can tell because suddenly everyone’s trying to differentiate, so if it’s not value stream management, it’s value stream insights, that’s far more important. And when people start playing these marketing games, the bandwagon is well and truly rolling. We’re seeing other aspects of that kind of thing, we’re seeing a growth of things like policy as code, infrastructure as code, management and testing, and the whole Shift Left and DevSecOps, and that kind of thing, But overall, it’s all about how we can stop worrying about doing things, we’re doing things fine, well we’re not, we can always improve there, but that stuff can look after itself for a bit. How about we focus on how we manage it, how we secure it, how we de-risk it, how we make sure that we’re delivering the right stuff out there. That’s where a lot of attention is going.

Rose Ross: There are a couple of things that struck me within that. What you’re saying is that one of the things about the development community is they do like to get into the weeds of the code. So, it’s not surprising that we’re seeing these splinter factions of codes and platforms, and this variety of different options for people to code in from that perspective. I was going to ask about the low-code no-code, is this the death knell for developers? I’m sure not. But it sounds like there’s more of this move to what I would describe in my sort of non-developer world, as building blocks for products, software products, and that if you’re using the same bricks you’re going to just have a foundation that would be the same across a number of different things. Or am I oversimplifying things there?

Jon Collins: You’re definitely not. I think that there’s a number of philosophical mistakes people always make about software. One is…

Rose Ross: This is getting very deep now Jon, easy, I’m gonna feel I’m now at loggerheads with Greek philosophers now.

Jon Collins: It shouldn’t. But in Greek terms it is a dilemma, it’s two conflicting theories. One is that things will inevitably get simpler and simpler, and they don’t. Software has stayed as complex as it’s always been. Because there’s always different ways you can write things, there’s new languages you can produce, there’s new platforms you can put things on, there’s market differentiation. Right now, with Internet of Things and all the different ways that that’s driving new chipsets, all the things around AI and how that’s driving new ways of data correlation and collection, and the way that architectures are fragmenting from edge to cloud, but that’s norm. The norm is an increasingly exponential rise in complexity, and throw in Moore’s law and everything else, that’s always going to be the case.

And then back to back with that is, it’s always going to be the case that you can stop, think, prioritise, build on existing platforms, look for commonalities, look for modularisation. This is going right back to 1975, and Jordan and Constantine theories, and this is what good container-based and microservices-based architectures build on, getting that level right, which is between application level and very small bits of component level, there’s a level in between which we’re currently calling microservices, which if you manage those you will be in a lot stronger position than if you try and manage applications which are too big and cumbersome, and if you try and manage all the little bitty bits, which are too small and fragmented, so that’s always the case.

To your point, low-code is essentially giving us that middle level, it’s giving us platforms. I had some fascinating conversations where we kicked off the low-code report with various end user companies, and one said – and it wasn’t even that big a company, but they said they got so much more value when they engaged with the vendor, and then with the vendor’s development teams. I had this minor epiphany, as the person was talking about how the development never goes away, it’s kind of another form of outsourcing. And when you’re speaking to developers and setting priorities and saying, ‘Well, that’s not really going to work for us, but this might’, and so on, then you will get a more solid platform.

I think we’re always looking for mummy and daddy to sort everything out for us, and all the problems will go away, but that doesn’t exist. It’s about ultimately taking responsibility for what happens within the code, and then working with the vendors in that case, and the developers, to make the code work for you. That’s always going to be the case, at the same time as making it a platform rather than making it ‘build it from scratch’ every time.

Rose Ross: Or as I like to say, ‘don’t reinvent the wheel’, because effectively sometimes that’s what they’re doing, they’re doing exactly the same thing, but just in a slightly different way.

Jon Collins: And rebuilding the cartwheel, creating the spokes, etc. etc, you don’t need to do that, you literally can take a wheel and use it. And people seem to struggle with the notion of either everything’s going to be auto-magical, or you need to build it from scratch, and the answer is always neither, it’s about getting that level of modularisation right.

Rose Ross: But as they say, then you should focus on the things that you can control, it does feel a little bit like the things that make sense to standardise on, and partly I feel… looking very much at this from a startup perspective, people like to do it in a better way, because they think it’s perhaps not as good as it could be, being driven somewhat by the view of perfection. Also, if you have people who are on your platform, and they move away from somebody else’s, that means you’ve captured that audience away from one of the competitive platforms, or code languages is, for example. That makes what you’re trying to do a lot harder, because you’re pulling people away from something, and you have to have something quite compelling to do that, because of the skills and suchlike around that.

Jon Collins: Something I want to be absolutely clear on, software development is still super-hard, and people building software… we talk about DevOps being the future of CI/CD, and we talk about value stream management being the future of DevOps, and we talk about, no, it’s not just value stream management anymore, it’s value stream insights, and value stream platforms, and blah-blah-blah. And meanwhile, the developers, engineers, and managers are sitting in companies scratching their heads going, ‘Hang on. We can’t even get our build processes, right yet. You’re over there, rushing off over the hill with some brand new concept like a cuckoo with a diamond in your hand, and we’re just trying to build stuff (which in the parlance, CI); we’re just trying to create, build systems such that we can build it today, change it, build it tomorrow, and do that really-really fast’. So, do that continuous integration and continuous deployment thing, and we as an industry are failing our end user organisations, if we’re rushing off with the latest and greatest next thing, and saying, ‘Well, it’s all low-code these days, isn’t it? We don’t need to worry about that stuff anymore’.

No, we absolutely do, and we need to help organisations in the real world who are still struggling with the basics of – and basics, not as in, ‘Oh, it’s so simple, why haven’t you got the hang of it?’ But basics as in fundamental foundational elements of getting this stuff right, which are very-very hard to get right. We’re not doing anyone any favours by rushing off with marketectures and not helping engineers if you like. I’ll shut up there, but…

Rose Ross: No, it’s fascinating, and I think about it more because I’ve got some friends who are developers on the job these days, and it makes me think about some of the other stuff you were talking about. I was quite fascinated by these bubbles; I like this management bubble.

Jon Collins: The bubbles, they look lovely.

Rose Ross: That sounds great, the empty bubble is not good. But, I was just thinking of people that I know who are developers, and somebody goes to them, ‘Why is this bubble empty?’ and they go, ‘Oh!’, it’s not the management element of it, also you need to be able to understand what’s going on and see the bigger picture around it. You’ve presented it in a very simple… I’m sure it’s not quite as simple as that.

Jon Collins: Just trying to paint a picture with the words.

Rose Ross: Indeed, indeed, well we like the bubble stuff. There was something else you referred to and I thought, ‘oh that sounds a little bit like living in a bubble’. There’s a lot of bubbles going on, so this is kind of building a picture.

Jon Collins: I was thinking about bubble tea to be honest; I think you could sit and have a cup of bubble tea as you’re watching the bubbles go by, in your little bubble.

Rose Ross: They should think of those goldfish bowl offices of yesteryear.

Jon Collins: Absolutely, 100 percent. So, a question you had by the way, which I forgot to answer it earlier. So, I’ll say it quickly, and then you can… is, so where are the opportunities here for startups? So, I’ve thought of an answer to that.

So, the answer to that is that we’re definitely in the manageability aspects, and where you mentioned that the developers see opportunities within their own companies, and then build out from there, because companies born of frustration, if you like, and Honeycomb is a great example in the observability, IT Ops, and AI Ops space, which was born out of Facebook developers. There’s a company I’m thinking of called ZenHub, they’re building a kind of portal onto GitHub, in terms of throughput, flow, project management and Agile feature management and so on. That was also born out of, ‘Hang on, we need to sort this out’. And so that building on manageability is really true.

But the other thing that I was thinking of, as you were talking about low-code, was as we’re talking about not doing it all from scratch, etc. verticalized solutions, by which I mean solutions for retail, solutions for healthcare, solutions for manufacturing…

Rose Ross: So, vertical sector focused, yeah.

Jon Collins: Yeah, so low-code for manufacturing, low-code for retail, low-code for whatever, linking in with data management for those areas. So, either going very vertical like that, or going very horizontal, low-code for video, low-code for big data, etc. It’s not just low-code, but there’s something for something.

At the moment, we’re still very much building generic platforms, although many low-code vendors have got more focus than they might put on their website, so some might be more mobile oriented, some might be more forms and workflow oriented, some might be focused specifically on – it might be low-code but you can still get very-very big applications on the back of low-code, so some might be focused on that market. But it’s still kind of generic platforms, no one’s locking down particularly on the legal profession, or any of the verticals I’ve mentioned, or any of the horizontals I’ve mentioned. So, I’d say a big opportunity for startups is to create templated solutions for sectors, or for use cases, definitely.

Rose Ross: Why do you think those haven’t been tapped into yet? Do you think it’s because you’d need somebody who’s been in that market to go, ‘There’s a gap here vertically’, or do you think they just go, ‘Oh, look, this is something’, are they all tending to go a little bit more tech-oriented rather than sector-oriented?

Jon Collins: I think it’s the nature of platforms and the nature of differentiation to an extent. However, however much you want to be specialised; you have to start by building a foundational platform, and if you do it right it’s going to be generic; otherwise, you’re just building a one-off solution for a tiny part of the industry. There’s an element which, let’s face it, a strong-strong chance of being true, that I just don’t know about those platforms. So, there might be a little low-code-for-legal platform that’s fantastically well known in Wisconsin, all the lawyers are using it, all the paralegals using it, no one outside of Wisconsin heard of it.

Rose Ross: Yet. But they will be now Googling that…

Jon Collins: Well, it makes you wonder, doesn’t it?

Rose Ross: …and that solution, low-code for Wisconsin for legal, as I’m just about to put .com in.

Jon Collins: Yeah, parallel codes.

Rose Ross: Exactly. Who said it was low-code? I had to put type loads of stuff in there. But yeah, it is as you say, because if they are focused on that particular sector, why would they be botheringJon Collins to brief you, because they’re going to be looking at tapping into those contacts who are in IT, and worried about software in the legal world, or partnering with people who already service those vertical sectors.

Jon Collins: There are going to be a lot of point solutions, we know this to be true. I’ve been around the block enough to know that in retail, or in manufacturing or whatever, there’ll be one company that’s still the provider of one little bit of software, which does one specific thing.

The other part of the answer though comes from that, which is you can’t scale a software vendor by being a point solution. And so, if you want to create a platform for the world, the way to do it is to build a set of capabilities that aren’t specific. And then to build policy-based templates that enable those capabilities to be used. So, I wouldn’t be building a low-code-for-legal solution. I would be building a low-code solution, and then I would be building a set of templates, or policies, or whatever it is, that enable it to be used specifically in the legal profession. That’s how I’d architect it.

Rose Ross: And then from there, to go to market you might well partner with somebody who is already providing solutions into that marketplace, and then it becomes a white label thing for them, perhaps.

Jon Collins: Yeah, then you find that legal is just a content problem. Then you go into other content-oriented industries, safety critical systems or whatever it is, and then you’re duking it out with the people that arrived in that space from the other direction, it was ever thus.

Rose Ross: So, we’ve talked about low-code, what about no-code, how’s that going to factor in?

Jon Collins: It’s a very good question.

Rose Ross: That sounds a little bit harder for me to get my head around. I can get low-code, I can get the logic of that, I’m not quite sure how I get where I go with no-code. I don’t know enough about it, so please enlighten me Jon.

Jon Collins: Well you’re in safe territory, because a lot of analysts don’t know how to get their heads around it either.

Rose Ross: Hurray! It’s not just me.

Jon Collins: When we did our reports on low-code, I’m using low-code as a generic term to mean low-code/no-code as I’ve been talking about it; I haven’t been specific enough, and my bad if someone was thinking, ‘Oh, he doesn’t mean no-code’, I just wasn’t adding on the slash no-code bit on the end of it.

When we put a report together, it was low-code/no-code, we combined the two different types of vendors. As we reviewed that and we thought about it a bit more, probably this time next year we’ll do two separate reports. The one on the low-code side of things, which tends to be… it’s all about use case, use low-code if you want to prototype something, and you want to build it quick, and then you’re going to want to customise it and make it more enterprisey and mission critical from that point.

And so the term used is ‘citizen developers’, so you might have someone in the business that’s able to throw something together relatively quickly. It may be someone like me who’s not touched computers for a while, and can go, ‘Oh, well, I get the hang of this, yeah’, etc. So you can build a front end, you can tack it into a back end, you can put some APIs in, then you’ve got something and then you can start building on it. And then where that becomes really powerful is then you get the development teams in behind it, and they start building in the extra security features, and the more detail functionality in the business…

Rose Ross: So, it’s a proof of concept type of scenario that you’re talking about there.

Jon Collins: Low-code gives you a more straightforward on-ramp to a full-scale application, and the resulting full-scale application will be a hybrid of low-code and full-code, probably, obviously there’s a spectrum of things. Whereas no-code tends to be for something that is always going to stay relatively small, so it’s literally a drag and drop interface, you pull a few bits together that enable some data to come in here, it goes through this, this, and this, and it pops out the other side, and then so-and-so’s informed and it responds to this. Yeah, Zapier-like triggers an event that goes into some other system, etc. but the end result will tend to stay pretty much what you just built.

Rose Ross: It’s a small part of a bigger cog, basically, that’s going to be static, it’s just going to evolve with the stuff around it. It’s not going to change the world; it’s just going to do that job.

Jon Collins: Correct, and with these things there’s always going to be an exception to prove the rule, and I’m putting myself and even as I said it…

Rose Ross: Well, you can say I said that. You had nothing to do with that, I just made that bit up. I just talked all over you.

Jon Collins: No, you’re spot on, and the truth is that there will always be something that proves any of these fixed definitions wrong, because the nature of software is to play with the boundaries.

So, I would say you will never get a no-code result turn into a full-scale enterprise application. The reality is that’s highly unlikely, it’s most likely to be some little thing that you produce that delivers on a certain need, it delivers a little mobile app, maybe it becomes exceedingly useful as that little mobile app, but it doesn’t ever transmogrify from a little mobile app and become your pan-enterprise warehousing system with full accounts built in and…

Rose Ross: Yeah, but maybe it becomes… now I’m obsessed with what’s happening to no-code here. I don’t want him to not go anywhere, he’s got to have some prospects. He would become part of a low-code project, and then he can take over the world; he or she, or they could.

Jon Collins: But it could, you can have a music analogy, it could be a one hit wonder, or a three hit wonder.

Rose Ross: It’s Kung Fu fighting.

Jon Collins: Exactly, it’s the Kung Fu fighting, it goes out there, it changes the world in its little way and everyone will remember it forever. So, it’s got huge success, but it’s not like AC/DC where every year there’ll be yet another. It’s not scalable from that point of view, it’s not a machine, it’s not something that will last the decades and evolve and become a whole brand etc. It will remain Kung Fu Fighting.

Rose Ross: Love a bit of Kung Fu Fighting, but then again I am a bit more AC/DC myself, being a bit of a rock chick. I would have worn my red leather jacket, if I’d have known you were going to start talking about AC/DC.

Jon Collins: Well, I’m sorry.

Rose Ross: That’s alright, I forgive you.

Jon Collins: But everyone liked Kung Fu Fighting.

Rose Ross: They did. We’re going to have to stop or I will start singing! So, moving quickly on, you touched upon Agile as well, and this wellbeing stuff. So, this is really curious, I was not expecting you to say that. I always love it when it’s a bit of a surprise. And obviously listening to Kung Fu Fighting or AC/DC probably will help raise people’s mood, so we can maybe link into, music helping with wellbeing, I certainly feel better when I’ve got the radio on. Although other than what I’m talking to you, clearly, because I’m very happy now. But what’s this all about? Are we saying that happy developers make better code, is this what we’re finding?

Jon Collins: Ooh.

Rose Ross: We’ll not say better, better is probably the wrong word. Because the thing is you talked about the stress element, and everybody knows, particularly in startups, you look at developers in the startups, there’s a huge amount of pressure in a very small team, and that type of thing where you’re potentially getting burn-out and that’s not going to be good, because then you lose the continuity from that person. Obviously, it’s not good on a personal level, you don’t want to suffer burn out.

Certainly from that perspective there’s been lots of talk about it, a lot of developers who have been in teams and now are a lot more remote; is all of this coming to a bit of a head? The pandemic has obviously been very challenging for everybody, and mental health quite rightly is one positive that we could see out of it. It’s become much more of a conversation piece, because we now have that element of shared stress around one common thing, obviously it’s impacted people in lots and lots of different ways: some people,there’s been positive effects, some mixture of both, and some very-very negative. But, tell us more about this whole stress conversation.

Jon Collins: Sure. There’s so much to unpack and probably we’ve only got five minutes left. So, as someone who has experienced a lot of work stress in his time, I had to have counselling and everything else. So I’ve done my time, if you like. I think there’s a lot to unpack, if we start from the beginning, the very glib thing anyone can say is that it’s better to have a more positive working environment – that’s an easy thing to say. But then equally, it’s an easy thing to forget, and it’s not a notion that everyone will share. So, a bleeding-heart liberal can say something like that. And then the accountants come in, sorry accountants, and say, ‘Right, productivity is our only metric. How many hours were you at your desk? How many function points did you deliver? How many features did you create?’ etc. etc.

Rose Ross: The KPI focus.

Jon Collins: Very KPI focused, and all that immediately vanishes into thin air. I think there’s an opportunity to change the language, and there’s an opportunity to actually understand what people bring. There’s not even a single notion of something called ‘the programmer’, we’re not all massively engineering focused, there’s artists and there’s scientists mixed together in the notion of programming, and the whole debate over is it real engineers or is it artisan, etc. etc. Some are true craftspeople; some are absolutely dyed in the wool mathematicians. So, it doesn’t make sense to lump them all together and say, ‘Well, we’re trying to make them all happy’, and then equally, we’ve all got tendencies towards laziness, yeah reality checkers, if you judge someone on the number of pull requests they do a day, they’re going to do more pull requests. Do they need to? Not necessarily. If you’re judging someone on the number of things they’ve taken out of Jira, and fixed and redeployed, they’re going to pick the easy ones, because then they’ll be judged on that. We, as a race, are very susceptible to respond to how we’re being judged.

So, there’s so many factors to take into account. Particularly given what you just mentioned about home working and remote working, and how that’s changed. We need to change the language and structure around how we judge success. We need to be giving people the wherewithal to perform in a way that they are capable, and that doesn’t necessarily mean that one set of rules, even if you want to move outside neurotypical kind of thinking, and then you want to think about bringing in people with disabilities, and so on and so forth.

It’s going to have to be about how we create teams with common goals, with impetus, with shared desires and aspiration, with trust. Trust is such a huge element and with very strong cohesion within the groups. Will that create more success? Possibly not in the short-term, but will it create more long-term sustainability? I absolutely believe that.

Obviously, I’ve just thrown in a whole bunch of psychobabble, and how do you measure that, how do you make that true, how do you fit it into the tooling, how do you stop people from reverting to type? Something I call the gurus dilemma where you get an agile consultant goes into a place, gets it all sorted, gets everyone doing great scrums and daily stand-ups and everything’s working really… then they go away, and six months later everyone’s reverted back to the way they used to do stuff.

Rose Ross: Well, it’s like fine tuning a car though isn’t it? If I want to chuck another analogy in, wear and tear, day-to-day use, you need to pop it back in the shop for a bit.

Jon Collins: It absolutely is. I don’t think there’s any substitute for some really good old-fashioned team-based approaches, such as listening, servant leadership, yeah leading from the middle essentially, and clarity of communication and those kinds of things. So, that the danger that we’ve got at the moment with this whole DevOps thing, is it’s all continuous, continuous, continuous. It’s a need for speed, and I don’t actually think that’s particularly healthy because we’re creating speed, again with the car analogy, at the detriment of self-maintenance and the need for pitstops.

Rose Ross: Yeah, and are you going in the right direction? Gosh, we can keep this motoring analogy going for a while. There’s lots of things about speed, but if you’re going the wrong direction it’s not really that helpful. And, from the feedback loop, you’re not going to get the right feedback of moving things, if you look at the whole sprint idea – yeah, but then two weeks you’re not necessarily going to get what you need from that, where the product should go.

Jon Collins: It’s reasonably standard to hear from organisations, ‘Yeah we do daily stand-ups, but we don’t really talk about what we’re going to deliver’, or essentially the same, ‘Yeah, we pay lip service to whatever methodology is currently famous, but we still don’t do things right’. And to me that holds the answer to everything, or the question that everything should be answering, it doesn’t matter what terminology you’re applying, it doesn’t matter if you’re safe, agile, or if you’re whatever; or if you’re using value stream management best practice, or you’ve got the DORA metrics; what really-really matters is not whether or not you’re using the right terminology, or whether you’re measuring the things that the industry sees as useful to measure, it’s whether you’ve actually got a fully able, from a delivery perspective, team within which there’s confidence and trust across them, and that level of cohesion across team members. So, that’s more important than anything.

Rose Ross: Well, it will be interesting to see what startup angles there may be within that over the next decade.

So, timing-wise, anything you’d like to say to wrap things up, Jon? This is a big topic and we’ve darted into territory that I wouldn’t normally let you, but you’ve got away with. But I think that DevOps is such a huge part for all of the tech startups that we… I wouldn’t say represent because that’s not the right word, but that are in our ecosystem. It’s just interesting because really whether you’re in a startup, whether you’re in a big enterprise, if you’re developing almost that sort of bubble within a bubble, if we want to keep withthe bubbles, is like I’m in DevOps, I need tools to create a tool to help people in DevOps in an enterprise environment. It’s like DevOps squared almost, potentially.

Jon Collins: It’s complicated isn’t it?

Rose Ross: Yeah. Any particular last thoughts on what the next decade could bring? It sounds like it’s going to be a really interesting time though. Things move really quickly, and then they also move quite slowly as a tide, if that’s possible.

Jon Collins: To be fair, we’re never going to fix the human race, and nor should we.

Rose Ross: Perfectly imperfect.

Jon Collins: Perfectly imperfect. I wrote a song called ‘Perfectly Logical’, which is very fitting there.

Rose Ross: That’s very DevOps that is, ‘Perfectly Logical’, brilliant.

Jon Collins: Just thinking through as you were speaking there, I was thinking, well what would I add. I’m a great believer in visibility in order to make decisions, and the old ‘If you can’t measure, you can’t manage’, is absolutely true. But equally, it’s something I learned a long-long time ago, back when I was a programmer, but it has stayed on the surface when other things have descended below, and it’s the notion of the win-win. So, if we’re going to get measurement right, all that we are really ever doing when we’re building things is trying to deliver value to another participant, and it’s the nature of entrepreneurism, it’s the nature of startup, it’s the nature of everything we do. We’re trying to get value to other people, and we’re trying to get value to ourselves as in, ‘I’ll give you this, you give me that’.

Rose Ross: A reward thing, yeah.

Jon Collins: And so something that we know isn’t true when we see it, is when we’re giving more than we get. Right now, I think there’s a huge opportunity to create tools that we need, and we’re seeing it already in the emergence of employee experience platforms. I do believe that we’ll see a lot of these fragmented tool sets, I think one of the opportunities for startups, it doesn’t matter if you’re a feature company because the bigger platforms are going to need to build in those features. So, we’re going to see a lot of acquisition over the next couple of years.

And what I’d like to see is that the win-win notion is built into those platforms which, to use a bit of consultancy jargon, stakeholder value. So, if we go around all the different stakeholders, be it a programmer, be it a customer, be it a manager of the company, whoever it is, what are they getting out of it? The tools can give us that information, the job is to know that everyone’s gaining proportionately from whatever they’re putting in. That’s what I see as, not so much an opportunity for startups, but where I would like to see these platforms developing and delivering.

Rose Ross: Brilliant stuff. Thank you, Jon, it’s been a pleasure. Well, hopefully we can catch up inperson again soon.

Jon Collins: You never know, you never know.

Rose Ross: Well, thank you everybody, thank you for joining us here on the Tech on Fire podcast with Jon Collins from GigaOm.

I’m Rose Ross, the founder and Chief Trailblazer at Tech Trailblazers. You can catch more from GigaOm on our platform, which is www.techtrailblazers.com or follow us on Twitter @techtrailblaze or find us on LinkedIn.

Thanks again, Jon.

Jon Collins: No problem. Thank you.