reborn55 - Fotolia
What low-code/no-code and pro-code mean for providers
Dave Sobel talks with SeedCode CEO John Sindelar about the low-code/no-code movement and how providers should be thinking about building on platforms such as Salesforce.
Dave Sobel is host of the podcast The Business of Tech and co-host of the podcast Killing IT. In addition, he wrote Virtualization: Defined. Sobel is regarded as a leading expert in the delivery of technology services, with broad experience in both technology and business.
This week, Dave speaks with John Sindelar, the CEO of SeedCode, an extensions developer for FileMaker. They discuss the growth of low-code/no-code and development platforms, as well as SeedCode's FileMaker calendar application, DayBack.
Transcript follows below.
Dave Sobel: John, so I've got to start with the obvious question. I want to start with your background. You've got an art history and philosophy major, yet you're doing software development. You got to tell me that story.
John Sindelar: Yeah. I mean, I wish it sounded more romantic, but I was a painter. I was trying to sell paintings and show in galleries, and I was working really hard at that. And as part of that, I needed to do a little tech. Back then, we sent slides to people, and I needed to print slides and stuff. So I got into computers to help automate that. I started using a FileMaker, Claris FileMaker, to help automate that. And then I needed a job. And I wanted a job that would leave time for painting. So, I started making FileMaker applications for people and realized that it scratches the same itch as making paintings, but without that kind of confrontation with your own self-worth. It's rewarding. It's very much like you get to make something and then see its effect out in the world. It became the thing I wanted to do instead of paint.
Sobel: So, there is definitely a creative element to what we do, despite it being technical. Now, you've come at this then through a development perspective. FileMaker is one of those products, though, that tends to be in a lot of places, particularly small and mid-sized places. You've got experience in what we've talked about. Development has changed a lot over the time that we've been doing that. And one of the reasons that I wanted to talk to you was you've been involved in the low-code movement. Help me understand: What's low-code?
Sindelar: I mean, that's kind of one of the things I want to talk about. I don't know that any of us are really sure. But one of the clearest explanations comes from Salesforce. If you talk to Salesforce admins, they make a pretty clear distinction between two kinds of work they do. And they'll sometimes describe it as clicks, not code, or declarative versus programmatic. And what they're trying to get at is that I don't need to know Java or Apex to accomplish a certain set of things and I do need to know Java or Apex to accomplish another set of things. And that's one way to think about this low-code thing. I mean, in some ways I think FileMaker was low-code. I could show a FileMaker script to my mom or a friend who wasn't a programmer, and they could read it because it reads like English. And at least when I was growing up, that's not what I thought code looked like. I thought code looked like code, like it was 'encoded.' And so we've always had readable languages, but this low-code thing is trying to get beyond that to something that's even more of a guided experience for the developer.
Sobel: Okay. That's interesting because your explanation there ties into something I've been telling my listeners a lot, which is the idea of [to] be building on platforms and be building on something like a Salesforce. So this actually ties in really well. So help me understand: There's another pair of related phrases, which is 'pro-code' [and] 'no-code.' [How does] pro-code and no-code fit into that?
Sindelar: Yeah. So I guess no-code is literally I'm filling out some kind of form. I think we've all used a WordPress plugin, where you want to add something to your WordPress. You just fill out a form and you're done. There's nothing that looks like code. I couldn't make a syntax mistake in that environment, for example. And then pro-code is, I think, what we think of as you're in a text editor of some kind and you could make a syntax mistake.
I think that one way I think about this is that the outcome of both of these things is the same. That form the user fills out when they're coming to your website, their experience is the same, whether that was generated declaratively or programmatically. The difference is in the level of control the author or the developer has. With pro-code, you have a lot of control, and with these other things, you have less control. And I think that the interesting part is how much control do we need in developing solutions for customers?
How DayBack began
Sobel: So, if you've migrated from building products around FileMaker toward what you're doing now -- the product you're working on right now is a product called DayBack, which you call a hackable calendar. How does that fit into this coding approach, thinking about the DayBack product?
Sindelar: Yeah. I think that our DayBack users have the same spectrum of issues that anybody wrestling with no code has. They find the calendar itself, the platform, very expressive, and they can do a lot with it and can fill out forms and make it behave the way they want. But when they want to go further, when they want a finer level of control, they need some way to inject a more expressive description of their goal into the platform.
Sobel: Talk to me then a little bit about the inspiration of DayBack. Was that driven by your problem, problems you'd heard from customers, from owners that you talk to? How did that start?
Sindelar: So, two sets of problems. One, just a personal problem of time management -- partly, I've got to have a job but have time for these passion projects. And then [with] the job, you end up making promises to customers and you can't keep them because you don't know what's ahead of you and you don't know how to budget your time.
And then, at first anyways, we were delivering to other developers, and we realized that they had a hard time making -- the web doesn't like to make grids. It likes to make lists. So anything that looks like a grid, like a calendar or a Gantt chart or Kanban, is just tougher. And so we wanted to make a scaffold that they could run with. And these two things lined up. And so we ended up making this very customizable calendar, at first for developers and now kind of for anybody.
Demonstrating DayBack through storytelling
Sobel: Okay. So besides talking about no-code, because some of my Patreon [subscribers] have been asking about that, the other thing that caught my attention that I wanted to ask you about was you've been using calendars to tell stories. I found that really fascinating. But kind of the three big examples is you've got a way of showing the U.S. COVID-19 response. You've got the way of showing women's suffrage as a story, [and] voter suppression. How did he come up with that, the idea of telling stories through calendars?
Sindelar: Well, part of it started with wanting to look forward. The problem we were trying to solve for ourselves is we can make plans for two weeks out, but you really need to make plans for two months or two years out. And so we invented this calendar that could look at longer timescales. But nobody could experience that because nobody really has meaningful events in their calendar five, 10, 15 years into the future. So, one of my colleagues was like, 'But we all have this shared past, and if we could show people that they could see their shared past in a surprising way, then that would show them the power this calendar had.' And so we started thinking about meaningful stories out of our shared past, and with this election cycle and with COVID coming up, it was just clear that there were these stories about our past, like the right to vote and women's suffrage, and then what's happening with COVID, that we could tell stories about this shared past that people could see in a new way.
Personally, everybody on the team has found a lot of other use cases and other small stories that they want to tell. And it's also changed our vocabulary when we talk to businesses, because now when we talk to businesses about planning or charting or capacity, all these issues that you're running into as a small business -- the smaller you are, the line between having too much work and not enough work gets super thin. And so now we're saying, "Hey, your calendar, your schedule is telling a story about your future. You should probably know what that story is. Is it a story that 'I don't have enough work'? Or a story that 'I don't have enough resources'? Is it a story that 'We're slammed' or 'We're behind'? And so it's given us a new way to talk to our customers, which has been pretty cool.
How providers should think about using platforms
Sobel: So a lot of my listeners tend to be coming from this, from an IT infrastructure perspective, but one of the things I've been talking about is the idea of leveraging platforms, like a Salesforce, for them to just start thinking about not moving beyond just the computer pieces, but to the stuff above it. If they're starting to think about this low-code movement or no-code, how would you direct them to something to get started on thinking about that?
Sindelar: I think there are two things to look at. This is a great question. This is where I have the biggest question. We're looking at two kinds of things. One is all the nodes, the end points where your data lives -- Salesforce, QuickBooks, Zendesk. They're building out low-code integrations to other nodes so that you can bring your help desk stuff into email, or you can bring it into Salesforce. So that's one thing: The nodes are building their own.
And then there's a whole layer of application providers that are building middleware for this, like Workato, Zapier, Node-Red, that are letting you craft these interactions in a kind of declarative way so you don't have to figure out the QuickBooks API.
I think that the decisions that a lot of small business IT [teams] are going to make is whether they're going to put their integration logic in a middleware layer like Zapier, Workato or Node-Red, or whether they're going to choose endpoints based on how well fleshed out their low-code connections to other apps are. And if I had to put chips in there somewhere, I would say that the nodes have a better incentive to build richer connections between them than these middleware applications do. And I've seen this in Salesforce already. The integrations between Salesforce and Zendesk, for example, are much richer than what you can do using Zapier between Salesforce and Zendesk.
Sobel: If listeners wanting to get in touch and understand more about what you and your companies are up to, what's kind of the best way to do that?
Sindelar: We tell a great story on the site -- just dayback.com -- and the election timelines are there, if you want to see what does it look like to look at a Google calendar that's 180 years long.
Sobel: Well, I know I spent a bunch of time poking at it before this call. Well, John, thank you very much. I appreciate the time.
Sindelar: Really great talking to you. Thank you, Dave.
About the author
Dave Sobel is the host of the podcast The Business of Tech, co-host of the podcast Killing IT and authored the book Virtualization: Defined. Sobel is regarded as a leading expert in the delivery of technology services, with broad experience in both technology and business. He owned and operated an IT solution provider and MSP for more than a decade, and has worked for vendors such as Level Platforms, GFI, LOGICnow and SolarWinds, leading community, event, marketing and product strategies, as well as M&A activities. Sobel has received multiple industry recognitions, including CRN Channel Chief, CRN UK A-List, Channel Futures Circle of Excellence winner, Channel Pro's 20/20 Visionaries and MSPmentor 250.