Understanding Contract-Driven Development – Pros, Challenges & Costs

Naresh Jain:

This is all very important because shortening the cycle time and, you know, basically getting to market faster is very important these days. So you don’t want to wait till the provider has finished the work and then you start your work. You want to actually do it in parallel.

 

Vit Lyoshin:

Can you explain what is the contract driven development?

 

Naresh Jain:

What we’re trying to do is trying to put some kind of a structure and a process and a life cycle around this so that this whole API can, API lifecycle can be governed and can be managed. We call this no code resiliency testing approach because you don’t, not really writing any code, you’re basically testing against the specification and generating all of this on the flight.

 

Vit Lyoshin:

If teams want to adopt this, how can they go pitch to their leadership?

 

Naresh Jain:

We’ve had so many head of platforms and CTOs basically listen to us for five minutes, literally, and I’m not kidding you, and they are like sold. This makes complete sense. I don’t need to. Don’t sell me anymore.

 

Vit Lyoshin:

Hello, everybody. Welcome back to the Vitlaushen podcast. Today’s guest is Naresh Jain. He’s an internationally recognized technology and product development expert. For over 20 years, Nares been working with different companies, streamlining their development processes, coaching their development teams. He’s also running a consulting business called Xnsio. He’s built ConfEngine, which is a conference management platform, and he’s also started the Agile movement in India. Welcome, Naresh.

 

Naresh Jain:

Thanks for having me, Vit. It’s a great pleasure to be here.

 

Vit Lyoshin:

So today I invited you to talk about contract driven development. And before we jump into the topic, would you like to share a little bit about your professional journey and the work that you’re doing now?

 

Naresh Jain:

Well, I can talk for hours about that. No problem with that. Well, I’ll try and give you a quick gist. So I started my career building neural networks for the Indian Space Research Organization. That helped me get into a job at Deutsche bank, again using some of the neural network work back in the late nineties, early 2000. And then I read Ken Beck’s test infected paper that got me interested in looking at how, as developers, we can improve the feedback cycles and get early feedback. From there, I discovered Martin Fowler and got to know about the company Thoughtworks. So I joined Thoughtworks early on.

 

Naresh Jain:

I was there for about four years. Then I started consulting. I helped a company in Mumbai. So I live now in India, Mumbai. And so I helped a company called Directi. Again, very interesting journey, because I remember the first day I was there, I was thinking to myself, like, this company is going to crash and burn because they don’t understand any of the engineering practices like what I had learned four years at Thoughtworks. But it kind of reminded me of the manifesto, right? The people and interactions over processes and tools. And I was like, they have a bunch of really smart people, so let’s see what happens if we can get these folks and expose them to some of the interesting things.

 

Naresh Jain:

Anyway, long story short, that company did really well. They sold one of their companies for $900 million, another for $256 million. They run another unicorn right now. So it’s been pretty successful. And I had a great opportunity to learn from, you know, really amazing smart people. You know, one of their companies now is shipping like multiple, you know, like, I don’t know, several hundred times a day to production and stuff like that, you know. So it was just a question of exposure, you know. Then I’ve done a whole bunch of consulting for, you know, different companies, including Google and Schlumberger and stuff like that all along, basically trying to figure out, because I think one of the things I felt very early on is some of us in the agile space tend to get too dogmatic about things and we live in that bubble and we think that’s basically everything.

 

Naresh Jain:

So Directi for me was at least that wake up call where I really felt like there’s a lot more than agile and stuff like that to build amazing products and change lives around us. And then I’ve had fortune to work with several other companies where I’ve had that similar experiences. And so you get to learn a lot if you believe that there is more to it than what you know. And that’s probably, I think, what’s the kept things interesting? The last five years I’ve been advising Reliance Geo, which is the largest telecom, but they run many other businesses, including retail, healthcare, education. And it’s again been an amazing journey to just operate at the scale they operate. It’s a six year old company valued at $88 billion, heavily invested by Facebook, Meta, Google, Intel. All the big companies all around the world have invested significant amount of money. And again, when you think about it, they are not doing all the conventional things we think, quote unquote in Agile, considered as best practices.

 

Naresh Jain:

They’re doing things that are quite unconventional and disrupting things very rapidly. And so that’s what makes it interesting is that you may have 20 years of experience having worked with the best of the companies, but there’s a lot more to learn.

 

Vit Lyoshin:

Yeah, yeah. So one of the things, how I got to know you is somebody from previous episode mentioned that you are actually responsible for creating Agile Coach Camp site. Can you tell a little bit about that and how you came up with this idea?

 

Naresh Jain:

Agile Coach Camp that’s from a long time back. So Deborah Hartman and I met at a conference in New York, JB Reinsberg. JB used to run a conference in New York, so Deborah was a facilitator and JB had invited me to come and speak at the conference. And so basically, you know, at that point, what we had realized that a bunch of us would go to conferences and pretty much just hang out in the hallway. We wouldn’t go and attend sessions because we felt like a lot of those sessions were either very beginner centric, trying to sell the Agile Kool aid to people. And, you know, for some of us, we were more at the bleeding edge of things and trying to see what’s not working, what can be done differently, and how we can push the boundaries further rather than just being very happy with. Agile is so awesome and agile does all of this stuff. I attended Kit Con, which is the continuous integration and testing conference in Chicago, and they had used a unconference or an open space style format for running the conference, which meant that there were no predefined speakers.

 

Naresh Jain:

They just managed to get a really interesting bunch of folks together and we co created the agenda and the schedule on the fly. And I thought, you know, so I had attended a lot of unconferences or, you know, open spaces before, but they were generally for more non technical conferences. So this was very interesting that you could also apply that. And then I kind of organized something called simple design and testing conference, which allowed, again, me to further take this format. So when I was living in the US, I was not a citizen and I was on an H1 visa. So you have several constraints in terms of how your economical like bank and everything else is set up. So, you know, when I wanted to organize a conference, the first thing people said is you need like a million dollar insurance for the venue.

 

Naresh Jain:

Then you need several other clearances in terms of being able to accept funds and so forth. Right from a sponsorship point of view. So I decided to almost accidentally, I guess, to structure Simple Design and Testing conference as a free conference and as a sponsorship in kind conference or basically come and contribute. And the main question was, how do we ensure that we just don’t get, you know, bombarded with 500 people at the event, because then it would just not be manageable. So one of the things we did was we came up with this idea of having a position paper. So people had to put in, like, a position paper or like, as a statement what they believe in terms of maybe simple design or test driven development or any of the engineering practices, and then that would be a way of people. We actually never ended up rejecting anyone. It was just a self selecting criteria, I guess, that allowed us to select people into this.

 

Naresh Jain:

So some of those lessons that we had learned in Simple Design Testing conference, Deborah and I, when we organized coach camp, we tried to bring those into it, and we had John Engel, who came in and he did the facilitation of the open space itself. And we, we got a lot of, lot of support from, you know, fantastic folks with the first conference that we did. And I would say that it was really, really encouraging to see everyone open up. So I think the first day when we opened the conference, we basically had a kind of a lightning talks kind of set up. So Friday evening, everyone came in, we did lightning talks, then we went out to a bar to let people socialize. And then Saturday morning is when we did the opening of the open space, and people came and submitted topics. And I remember we had way too many topics that we could accommodate, but that was a good problem to have some very interesting topics. I remember one of them was “Run Coach Run”.  And this was basically, as a coach, you got to constantly put yourself in the shoes of a coach-ee so that you can empathize and learn. And so, you know, like, that was one of lightning talks, and that helped, like, a lot of us then, like, relate and, you know, bumble that idea. So I think people liked it. And that’s one of the reasons why I believe, you know, after 15 years, this kind of continues to kind of grow. And I believe we’ve now crossed over 100 Agile Coach Camps worldwide. And I don’t think Deb and I are anyway involved in any of these, but it’s kind of autopilot. And I think Agile Alliance has also been supporting and running some of these. So it’s pretty interesting to see how these things have been, you know, self sufficient in some sense.

 

Vit Lyoshin:

Yeah. I mean, you did a lot of stuff all over the place in different countries and companies and, and also agile coach camps. I attended one last fall, and I really enjoyed it. I found it really, like, very concise and very short sessions, but you learn a lot. You talk to a bunch of people at once. So, yeah, that was great. I highly recommend to anybody to go.

 

Vit Lyoshin:

And now I think they also do it worldwide. So next one will be in, I think, Costa Rica or something like that for the first time ever. So. Which is also awesome. So, yeah, that’s great. All right, let’s jump into the main topic. So can you explain what is the contract driven development?

 

Naresh Jain:

Okay, let me maybe use an analogy to explain contract driven development. And then maybe I’ll step back and explain how, what problem I was trying to solve and how I came up with this thing. So let’s imagine that you bought a house and you want to get the interiors of the house, like the design and everything done, and so you want to hire someone to come and do the interior designing of your house. Is that common in the US? I believe so, yeah.

 

Vit Lyoshin:

If you’re building a new house, I would say it’s pretty common, yeah.

 

Naresh Jain:

So when, you know, you might agree on a broad budget to start with, you may agree on a broad timeline and the interior designer might get to know you and your family and can maybe get a sense of your taste and things like that, and maybe they’ll prepare some 3d models and so forth and kind of do all of that stuff. And then you want to put all of this in some kind of a written format in terms of what’s the agreement between you and the service provider. In this case, it’s basically the interior designer, the cost structure, the timelines, what they will provide, what you will provide, how you want to pay out, what would be the criteria in terms of saying something’s complete, etcetera, etcetera. So typically you would put this in an agreement or in a contract, and then that would be the return agreement between you and the provider. Right. The service provider. And that’s basically how you would manage. And if there was any confusion or misunderstanding later, then you would refer back to the contract and then, you know, say, yes, this is what we’ve agreed.

 

So the appropriate, like, the right person would do that, their part. And this ensures that the relationship between the two continues to be healthy. It also ensures that as things evolve, because things will evolve. Right. As building, it’s a complex process. So as things evolve, this, this becomes a, you know, a place where you can go back and refer and maybe even update it as your thinking evolves. Right. So this is very, very common in any field where two parties are coming together or multiple parties are coming together, is to basically capture their shared understanding and put it in a return contract and refer to that.

 

And this is no different from what happens in software development, right. In software development, especially today with microservices or even before this with SOA, that is service oriented architecture, what would happen is you would be providing, you know, you would be, let’s say the developer for a particular API, and I would be consuming that API and maybe building let’s say a UI on top of it, right? So, you know, we would sit down and we would agree in terms of what is the request I’m going to send you? What all I need to include in that and what is the response you’re going to send me back? What’s going to be the schema or the data structure of the response that you’re going to send me back? And if I didn’t send you what I was supposed to send, then how are you going to communicate back to me in terms of like I, you know, messed up, right? I didn’t send you the right one. This is, this is essentially what we try and capture in, in, in a specification, in an API specification, okay? And there are, there are well defined standards for these. There is OpenAPI specification, which used to be called Swagger earlier, but there is OpenaPi specification now, the new name, which is for any HTTP requests. Similarly, we have async API specifications, which is for things like asynchronous messaging for like kafka, JMS, Google Pub sub and so forth. And if you go back in time, then we used to have soap for those of you old enough to remember, and Soap used to have something called visdil, which is how they would agree on the contract. So contracts are, or API specifications are kind of pretty common in software development between providers and consumers of services. So what we’re trying to do is trying to put some kind of a structure and a process and a life cycle around this, so that this whole API can, API lifecycle can be governed and can be managed between them.

 

So what we essentially recommend in contract driven development is we start with the provider and consumer coming together collaboratively, flushing out what the APIs should look like. And so we call that the API first approach, and we capture that in an API specific, and then we check that in, into a central git repo, because developers understand how to collaborate over a version control system like git. So we decided that we’re going to put all our specifications or contract in the central git repo. That will be our single source of truth. All right, so you agree on the API specification, then you put it in the central contract repo, then the provider and the consumer can start independently developing their piece of work, and both of them would refer to the API specification and do their bit. So as a consumer of an API, I would use the API and essentially use that to generate a mock or a stub of the actual API. So I don’t need the actual API, I can just work off the mock or a stub and do my development. Similarly, as a provider of an API, as a provider of a service, I would use the API as a contract test against my implementation to make sure I’m adhering to the API specification.

 

And when each of us are done with our piece of work, we would then raise a pull request, do the same thing in the CI, make sure all of these pieces are working. And then when both of them are ready to go, then you would go to an integration environment and integrate over there. And hopefully you would not see any surprises over there because a lot of those have been shift left and flushed out much early. And it’s also through a collaborative process. Now what might also happen is as you’re developing, you may realize that, hey, I need an additional piece of information, or for a new requirement, I need to tweak the existing API or enhance the existing API. So what you would do is you would take the existing API, make the changes that you want to make, run a backward compatibility check. You want to basically make sure that the changes that you’re making, you’re not accidentally breaking backward compatibility. Now in most cases, the way people test backward compatibility is they make the code changes and then they take an old version of the consumer and then they run against the, you know, like if you, let’s say, had an app, then you would use an old version of the app with the service, and we would basically make sure the app continues to work.

 

Vit Lyoshin:

Right.

 

Naresh Jain:

So that’s how a lot of people do backward compatibility. But that’s too late, right? You’ve already made all the changes and now it’s too late to get that feedback that, you know, what you change actually broke backward compatibility. So what we’re trying to do is we are actually shifting this whole thing left, which means the moment you make the change, the API, because we are doing API design first. So the moment you make a change to the API specification, you would actually run the backward compatibility test and you would make sure that this is backward compatible. If it’s only backward compatible, then the PR, the pull request will be accepted and that’s when it will go into the Git repo and then from there onwards, the provider and consumer will work off that new version. And so they won’t be out of sync, right? They are, they are always now in sync.

 

And this avoids unnecessary, you know, problems downstream. So that shell is, you know, the idea behind contract driven development. And you know, the, the problems that it’s really trying to solve is the problems of finding late surprises because of contract mismatches. You know, a lot of times the collaboration is not very efficient between the provider and the consumer. Someone makes a change, they think they’ve communicated to another person, another team, but they have not really communicated or people have missed it. So that communication is a bit of a challenge. So we’re trying to streamline that piece of, and for the provider and consumer, make it really easy from a DevX point of view, so that they can get up and running very quickly, they don’t have to wait on each other. And this is also very important because shortening the cycle time and basically getting to market faster is very important these days.

 

So you don’t want to wait till the provider has finished the work and then you start your work, you want to actually do it in parallel. So that’s another world challenge that we’re trying to solve with this. And finally, I think on the API side, because APIs are kind of your building blocks, you want to make sure that your API itself is very resilient. So we do a whole bunch of API resiliency testing that’s all automatically generated for you to ensure that your APIs are resilient and all based off OpenAPI or AsyncAPI specification. So we call this no code resiliency testing approach because you’re not really writing any code, you’re basically testing against the specification and generating all of this on the flight. So that I think hopefully, I know I spoke a lot, but that’s kind of the idea behind contract driven development and the problems it’s trying to address for us.

 

Vit Lyoshin:

Yeah, no, that’s great. And the analogy helps. So I think I have a better understanding what this is. But then who will be initiating to write this contract in the first place? And also, is it being written by both parties, provider and consumer?

 

Naresh Jain:

I think that’s a great question. Right. So different organizations follow different approach. Right? So there is a big school of thought which believes in consumer driven contract, which means the consumer who’s consuming should decide what the contract should be, and they are the ones who will first write the contract, put it in the central repo and then the provider will adhere to that. And I think that’s a good model if that’s how your organization is structured. But that might not be appropriate for every organization because we’ve also seen in many organizations the provider, because there may be multiple consumers, the provider has a much deep domain understanding and would design and provide the API saying this is the available API and this is how you’re supposed to consume. Now you can build stuff on top of it, but because I have deep domain expertise and deep domain knowledge, I’m going to expose a APIs in a certain fashion. So in that case the provider is actually taking a lead and they are the ones who are providing the specification and then putting it in the central repo.

 

I think what would be ideal, in my opinion, is it’s a collaborative process where the provider and consumer come together, they flush it out, both bring unique perspective to the table that is important. And then they do an API design first, but collaboratively and put it so contract driven development itself is not hung up on who does it, whether the provider does it, whether consumer does it, whether both of them do it. Both of them is ideal. But there are enough cases, valid cases, where provider or consumer can take a lead should not really matter as long as that contract has put in a central git repo. And that’s your single source of truth. I think rest of the process will continue seamlessly.

 

Vit Lyoshin:

And then which projects would be more suited for this approach? Like for example, building a new product may be easier because you starting from scratch, but what if you modernize in an existing system?

 

Naresh Jain:

Yeah, I think that’s another great question. So what kinds of projects will this be suitable for? I think to start with, any project where you have multiple things integrating with each other would be important. If you just had one standalone monolith, then probably this is not a problem for you to worry about. But most often these days we are essentially looking at distributed systems where multiple systems are collaborating or integrating with each other. So that would be useful. You know that that’s probably where this would be most useful. Now, what kinds of projects within that, right? Is it Greenfield project? Is it brownfield project? Is it legacy revival? So you may have different kinds of projects that, and we can look at each of them and each of them have, I think a valid scenario or a use case where this might be applicable. So let’s take an example of I have a really old legacy application and I’m basically rewriting that, modernizing it and rewriting it right.

 

So first of all, in this case, I wouldn’t recommend doing a big bang rewrite, right. Because I’ve not really seen those kinds of projects being very successful. So you probably do a gradual cutover. So if you’re doing a gradual cutover, then you want to make sure that at point you have the capability of working with the old and the new both simultaneously, the old stack and the new tech stack. And so in these cases, you would want to first capture what is the contract of the old system or the piece of the system that you’re trying to replace, and then ensure that the new thing continues to work with that contract. And that’s what ensures the ability for both old and new to work simultaneously, simultaneously and gradually cut over. Right. So you probably use contract driven development here to establish how the old two components are integrating in the old world and then how you can take one component, replace with the new one but continue to maintain the contract.

 

So I think if you think of those kinds of use cases, I would think it would be applicable over there. You already talked about brand new projects. If you’re building brand new projects where both the provider and consumer or your several services are all kind of getting started in parallel and you have a very short time to market, then of course this would be a sweet spot because you could define the contract and unleash the full potential of all your teams working in parallel and still being in conjunction with each other. Brown peak projects are interesting because you already maybe have a whole bunch of stuff working, but you’re enhancing or adding something on top of right now, when you’re adding or enhancing something on top of it, how do you ensure, how do you make sure you’re not breaking backward compatibility or you’re not introducing some regression as you’re making those changes? So again, that’s a good candidate where I would basically define the contract, ensure changes that I’m making are backward compatible and not breaking stuff that’s already working. So again, that’s a place where I can apply. So in a nutshell, what I’m trying to highlight is that you could look at problems in the nature of your project and see where this is suitable. And I’ve given you three examples, but there may be many more. So I’m not advocating that contract driven development is a blanket, just close your eyes and slap it on.

 

But look at the problem in your project, in your domain that you’re trying to address. Probably see that this might be a good fit to solve this particular problem, and you might want to use contract driven development in that context.

 

Vit Lyoshin:

Yeah, yeah, that makes sense. I was also thinking about the case when it’s maybe internal to the organization and one part of organization using the system that needs to talk to another one and you can internally organize this between the teams. So I guess that could be also the case.

 

Naresh Jain:

Yeah, I mean with AI and you know, I think everything going on right now, I think APIs are going to be become essentially, you know, like the way different systems are going to talk to each other and AI is going to interact with each other. So if you build any, if you build like GPT plugins or things like that, you already know that GPT is very good at understanding OpenAPI specification. In fact, you have to define your plugin as an OpenaPI specification. You have to provide the open API specification and it then knows under what context to delegate things to you and so forth. So I also believe that with AI this is going to become more and more important and relevant to.

 

Vit Lyoshin:

So you kind of mentioned a couple of challenges there, like one being collaboration between parties and things like that. What are some of the other challenges? Or maybe also cost to building it with this approach?

 

Naresh Jain:

Yeah, so originally I was invited to help a really large organization where they, when they started, they were able to ship features to production every two weeks. And gradually over a couple of years they had got down to release cycles as long as six months. And when we analyzed the data, one of the things we saw is that a lot of their releases had slowed down because they were finding late issues during integration. And that was leading to instability of the testing environment. It was also leading to when someone’s finished, they’re waiting, they’re like hey, let me add this other thing while we are waiting. And then that basically leads to a bundling kind of a thing where your more and more stuff is getting accumulated and take out. So we were seeing all those anti thesis, right? Like basically, you know, integration is broken because you didn’t really think about it. So now you’re thinking, oh, I need to also do this other piece and like hang on, please wait, I will do this and get back.

 

In the meantime, someone deploys something else and that breaks the environment, that makes the environment unstable. So you’re like hey, while this is unstable, let me slap on one other thing. And so you suddenly end up with these really large bundles, you end up with a lot of regression issues and so forth. And eventually this basically delays your entire release cycles, makes them very unpredictable, also makes the product very unstable. So if this is something that you can relate to, then that is, this is a common anti pattern that we have seen over and over again. And so the antidote for this is essentially, you know, try and decouple your releases, try and decouple your components, try and aim for independent development and deployment rather than bundling. And for all of this, you will need to ensure that the foundation by which these services are integrating is rock solid. And that’s where contract driven development kind of becomes important.

 

Vit Lyoshin:

Yeah, I see. And what about the cost of adoption? It. Adoption it.

 

Naresh Jain:

The cost of adoption with everything is twofold, right? One is what is the visible cost and what is the hidden cost? You know, the visible cost in this case is probably very little because, you know, all the tooling and everything else is free. So there is really no, you know, at least financially, like, there is no initial cost that you have to pay and stuff like that. But of course, the hidden cost, which is basically the learning curve and maybe even more importantly, not the learning curve as much as, but the changing the way people design and, you know, develop things, right, that will need to shift, because what you’re trying to do is instead of thinking of integration late in the cycle, you’re thinking about that upfront, you’re thinking about flushing out the contract upfront. And that’s not an easy skill for a lot of people, right? They’d rather just hack some code and then figure out how to make those jigsaw puzzles fit together. That’s fine in some cases, but in large enterprise products, where time to market is really critical, you can’t just take the chance of just hacking something and then hoping that they’ll all fit together. So you really shift this left and get people to think about API design first and try to make a lot of implicit decision design decisions explicit. And it kind of has a very similar effect as test driven development, if you will. Because in test driven development, you are just writing the test first.

 

But that really changes a lot in terms of how you’re designing, how you’re thinking about it, what principles are at play, what’s your style of design? You know, more like a reflexive design rather than like a big upfront, you know, ivory tower architect type design. So some of those same principles are at play here. As you’re flipping things around, you’re getting people to think about this upfront and you’re trying to do this in a very iterative, feedback driven manner. And so, you know, those are all the hidden cost, if you will, that one will have to take into account and I think at the end of the day, it’s a big cultural shift in many organizations in terms of the provider and consumer collaborating and working together. You know, that’s often, you know, in many organization, you know, some ivory tower person is going to just write some blurb and say, here’s how these things will talk. And that really doesn’t have much meaning to it. Only when the team sit down and start integrating, that’s when they come up with all challenges and like what’s the data type? What’s the, what should happen in this case? What should happen in this scenario? So we trying to preempt all of those things so that you can, you know, avoid those last minute surprises.

 

Vit Lyoshin:

Yeah, yeah. It’s a lot of, not a lot of, but some knowledge required to be at the product management level for people who are driving the teams and making those connections and setting up the sessions for developers to figure out, engineers to figure out. Yeah. So you mentioned a little bit about how, what the advantages of contract driven development, like resilience there, backward compatibility, is there, are there any other advantages that you can mention in terms of like scalability or product quality and things like that?

 

Naresh Jain:

Sure. So I think the big advantage that I touched upon so far is the shift left and getting early feedback, which is very important from a developer experience point of view. Second is basically because of parallel development, you are able to basically shorten your release cycles because things can happen in parallel, they’re not waiting on each other, you can independently deploy and things like that. The third is improvement in terms of the collaboration between the teams and avoiding those last minute surprises. So better collaboration and collaboration, not in the sense of let’s all meet together and have nice party. It’s collaboration in the sense of here’s how I’m going to check in code, here’s how I’m going to notify you. Here’s the pull request, here’s the process, this is what we will follow. Everything’s documented, everything’s visible.

 

There would be no surprises that actual hands on, day to day collaboration. The fourth benefit which you briefly touched upon is because of resiliency testing and early API testing you are ending up to. Basically it would result in your APIs being lot more resilient, well tested, and that of course will ensure that your APIs itself are not going to fall over and in production you will not have outages and stuff like that. Does this lead to better scalable design? I’m not sure if this would directly result in scalability because I think there is some more additional thought process that is required to make sure your APIs are designed from a scalability point of view. Your business processes are aligned towards them being scalable. For example, would contract driven development force you to be async versus sync? Probably nothing in contract driven development per se will force you to use async or sync, but that’s a different thought process you might bring to table saying, hey, I want to make sure that I can handle extremely large volumes of load, and even when I have sudden bursts of requests coming in, I want the ability to be able to still keep accepting requests. That’s when I would probably go and design something to be asynchronous. And so those are the slightly different thought process that contract driven development itself may not bring to the table.

 

So scalability, I would say, requires this plus, plus more stuff.

 

Vit Lyoshin:

Okay. And then you mentioned that tooling is kind of most of tooling for free and people already kind of know this. Can you mention which ones if the team is now want to start using this where they can start with this?

 

Naresh Jain:

Yeah. So I would recommend, you know, there’s not a lot written about it. It’s still kind of relatively new. And even though contract driven development as a terminology is pretty old, I don’t think some of this thinking is, is that widely adopted and used. So there isn’t like a lot on this subject. Long back I had written an article on InfoQ, but recently I did a talk at Yao conference in Australia. I think that might be a good starting point where I demonstrate the open source tool called Specmatic that we’ve built to do contract driven development. And our kind of did a live demo showing how it’s able to do ensure, first of all that your API specification and implementation is in sync.

 

Then it’s able to take a dependent service that you have and basically use a proxy to stub it out by generating a contract for you. Also things like Kafka or other kinds of things, how you can stub that out. So it kind of gives you a step by step walkthrough of that. So that would be a good place to kind of get understanding of some of these concepts. And then I think there are a bunch of tools we have done some. If you go to the Specmatic IO website, you might also see some comparisons we have done with other tools. And so you might be able to kind of use that as a reference. And you know, again, it’s just a good starting point for you to look at other alternatives and compare and contrast.

 

We obviously have our viewpoint, but, you know, we would welcome you to kind of go and test it out yourself.

 

Vit Lyoshin:

Yeah. So is that the tool that you built with your company?

 

Naresh Jain:

Yeah. So Specmatic is something that Joel, me and Hari, three of us originally built it out. We put it open source. It’s still open source. In the past, I’ve had some bad experience open sourcing and then a big company coming and chasing me with a patent stick. So this time what we try to do is to just protect our own interest. We put most of the stuff in the open source, and then when we wanted to patent it, we were told that at least in India, you can’t patent if it’s all publicly available already because it’s public news at public knowledge at that point. So we kept parts of it private.

 

And basically that’s what the patents have been. We’ve now started getting the grants. We’ve got a few. Few patents granted already and a few more in the process. So hopefully we will be able to, at least the original thought process will open source all of this stuff and give it for free once we have the patents. But something along the way happened, and that was very interesting for me. So when we had this open source, we would get emails from people like, I’m not kidding you, but at least five emails every day asking, what is the future plan for this? You know, how does this project line up on your roadmap? What is your business model? How are you going to make money out of it? I evaluated it. I really like it, but I am worried to recommend it because I’m not sure you people from India when you will disappear.

 

So we would get a lot of these emails and we would keep wondering, like, what do we do? Right? Like, and then, of course, you know, one of our very good friend, very big, very popular person in the industry, he called up one day and said, are you stupid? Why are you throwing away a billion dollar company? Why don’t you monetize this? And we were like, no, I mean, this is really not the intent behind it. We just wanted to open source this, and we believe a lot more people would benefit from it. He’s like, yes, but when you give it away for free, people actually don’t really value it. So. And that kind of resonated with what was happening with all those emails. So just as a thought experiment, we essentially put a pricing page and we said, here’s our pricing plan. And what we saw is that the downloads had skyrocketed.

 

You know, when we put a pricing page you know, the number of downloads had significantly gone up, almost a hockey stick growth. Right. And so now what we are thinking is what is open source will continue to be open source and we are continuing to add new stuff, but there are few niche things that we have done which are more enterprise features. We will probably monetize those as a commercial product and essentially offer that as an enterprise license. And we’ve already signed a few deals from an enterprise license. So that also gives us the confidence that, yes, people are actually willing to pay money even though most of the stuff is available for free. Because one of our big customers basically said, you know what, if I don’t pay you guys and you disappear, I’ll be in trouble, sir, I’d rather pay you. So that was very nice of him.

 

And so we’ve now had a few customers who are supporting us through the commercial thing so that we can continue to keep most of this stuff open source.

 

Vit Lyoshin:

Yeah, yeah, that’s great. And that’s actually a great test. When you put a pricing page, people start saying that’s trust, right? They believe you’ll be there for a while.

 

Naresh Jain:

So, yeah, I mean, if you’re going to charge, then you better be professional about it. And so I can expect professional service from you guys. And so that makes sense. I mean, in hindsight it makes sense that, you know, when you have a pricing page, I more people download stuff. But before that we were like surprised. It’s like, hey, you know, I’m giving you, this whole thing is out there, you know, and if we disappear tomorrow, you can always take the source code and do what you want to do. Right. It’s not a hosted service.

 

That’s only with us. And if we disappear, then you are left with nothing. But, yeah, I think sometimes that’s not how other people.

 

Vit Lyoshin:

Yeah, that’s how market works, right? Yeah. So again, if teams want to adopt this, how can they go pitch to their leadership and say, hey, we found this great approach, we want to try this. We think it’s great. Are there any tactics for them?

 

Naresh Jain:

This is a very common question and also something that always surprises me. Right. We’ve had so many head of platforms and ctos basically listen to us for five minutes, literally, and I’m not kidding you, and they are like sold. This makes complete sense. I don’t need to. Don’t sell me anymore. In fact, one of them told us that, cut out all your slides. We don’t need to see any of your slides.

 

Just show me the last slide and that’s it. Like just one slide and that’s it. Right. And so my point is that I think, you know, technical leaders and leaders in general, you don’t need to really sell this idea. They get it. All right, so to your question, what do I need to go to sell to my leadership? Really not much. One slide. Yeah, but I think before you do that, right.

 

If I was in your place, what I would do is I would try it out myself and get comfortable with it. I would not take someone’s word for it, right. I would actually try it out because sometimes ideas sound great on a PPT. Ideas sound great when someone tells us about it, right. But when we actually try it, there’s a lot of impedance mismatch between what you heard and what you actually experienced. So my recommendation is, before you go and pitch to anybody or try and convince anybody else first, be convinced first, experience it yourself, right? So for example, Specmatic is open source. You can just go get, download the thing. We have a lot of sample projects.

 

You can take one of the sample project and just give it a spin first, right. Then maybe if you’re developing an API, take it and run it against your API and see what it shows up, right? Does it make sense? Does it not make sense? And this is generally like what I’ve been advising people. And, you know, I’ve heard very interesting and inspiring stories. The other day, someone got back saying, you know, I tried it on my service and this generated 9000 some tests for me, right? And at first I thought this was a bug in the, in the software. Why was it generating 9000 tests for an API? But when I looked at what it was doing, it was very interesting. It was trying to generate all possible combinations that, you know, you know, and I found some 800 some tests did not pass, right? And, you know, again, when I dug into it, it made me realize that, you know, there were corner cases that I’d never thought about or I would have not imagined that it is possible or I had not safeguarded myself, or in some cases I thought the framework will take care of it, but it was not, it was doing something else, etcetera. So when people have that kind of an experience, that’s when I know that they’ve really tried it, they now know the. How it works.

 

Now is a good time to go and pitch to someone else, right? So that, that’s my general advice is like a give it a spin yourself. Don’t be too worried about convincing leadership because that’s actually very easy. So first give it a spin yourself, you be convinced that this makes sense, then maybe spread the word, and then, you know, I’m sure leadership will see value in it and know it’ll resonate with them.

 

Vit Lyoshin:

Yeah, yeah. I mean, this is awesome. If the tool can. Can do this, then that’s really just one slide presentation showing them like, hey, this is what we’ve got. You don’t need QA engineers. You don’t need, like, people manually testing. I remember in the old days, I used to help with testing, and it was like literally manually clicking buttons, trying to cover all the possible cases, writing down all the issues. It’s enormous amount of time, and if you can do it in, like, a few minutes, that’s awesome.

 

Naresh Jain:

In fact, I would like to quote Jez Humble. So I met Jez recently. I used to work with Jez at Thoughtworks. Jez Humble is the guy who co authored the continuous delivery book and has done a bunch of really amazing work after that. So Jez saw the demo of Specmatic, and he basically was summarizing that all great ideas in hindsight, look common sense. And that’s why basically one slide is good enough to explain what it is, because it is common sense, but it’s not common sense until someone’s actually gone that extra mile and prove that that’s how it is. But once someone’s done that, then it’s like, yeah, obvious. How else would you do it? I thought that was very profound, the way jazz humble had put it.

 

Right. Like, all great ideas in hindsight, look common sense. And if you think about it, like, agile feels exactly that way. It’s like common sense. But no one was doing it that way until someone actually, or some people actually showed it and proved it, that this actually makes sense. Then everyone is like, yeah, this is just common sense. So I hope, and I believe what Jess says is true. I hope more people will look at it and will have the same expression that, yeah, one slide is enough, and it’s common sense.

 

Right? So, yeah, but that’s. That’s what I think.

 

Vit Lyoshin:

Yeah, the product speaks for itself. Right. So, yeah, that’s great. All right, I. So we’re coming to an end here. And would you like to say anything else to the community, to people who would like to start using the technology or anything that we haven’t covered yet?

 

Naresh Jain:

Well, I think there’s a lot of interesting stuff happening these days, so I’m not sure I’ll be able to. I’m not sure what I have covered and what I have not covered. There’s a lot in that. So of course, go check it out and give it a spin for yourself. That will be a good starting point for you. But also, I think just in general, my experience is don’t get too dogmatic with anything. Just be pragmatic. Try things, see if it works, then take it.

 

If it doesn’t, move on. Right. Life is too short to be dogmatic and be hung up with stuff that doesn’t actually work. So that’s what I would suggest as parting thoughts here.

 

Vit Lyoshin:

Yeah, that’s a great suggestion. Many people just stick with something and blindly keep doing this even if it doesn’t work for them. But yeah, that’s great advice. Okay, Naresh, thank you very much for your time today. That was great conversation. A great new technology for somebody to learn about, and I hope we can talk more in the future.

 

Naresh Jain:

Cool. I enjoyed it. Thanks Vit for hosting this. And I must say, you had some really amazing questions. Hard me to think so. Yeah, thanks for that. And do check out https://specmatic.io for more details.