Right now we're talking about ...What Matters in Business is Growth
Should Citizens be allowed to Code? If so, what will this mean for the future of programming, we need your vote!
UPDATE: It’s official! Concepture will see you at SXSW 2017 participating in the session “Should Citizens be Allowed to Code?” For more info visit: http://schedule.sxsw.com/2017/events/PP60745
Both of these questions come up often when talking about the emerging trend of no-code application development and the impact on programmers. We all tend to get worried to a point of jumping to conclusions when entirely new disruptive ideas are proposed — like — no code application development and promises of creating programs without having to learn code syntax.
The truth is programmers will always be needed — especially those with deep full stack development expertise and any programmer with highly specialized coding experience. The more we explore the impact of this no-code trend, we see how programmers will benefit from increased opportunities to work with less experienced programmers using no-code development platforms.
This present conundrum is why we have proposed a SXSW 2017 panel “Should Citizens be allowed to Code”. Interested? We’d greatly appreciate your Thumbs up on the topic and leave a comment — we are looking for all viewpoints.
With software development tools becoming more sophisticated and easier to use by removing the need to learn code syntax, people can think about problem-solving from a higher level of abstraction. Programmers share or sell their existing code libraries with non-coders who will use those unique libraries as a configurator in a no-code development environment. We see this being the way of the future, and it means that everyone benefits.
People who have deep technical expertise in a specific business area or industry can work hand-in-hand with experienced programmers to do even more complex projects. Coders drive the key development of the more complex underlying framework of new tools and more advanced applications. Non-coders as configurators can work their way toward ever more complex problem solving. This way experienced coders can spend more time doing what they love, solving complex problems that are the core of any application’s value.
At this point in the article, I imagine the reader has formed one opinion or another. I’ve presented the topic enough times over the last 18 months to realize how polarizing it quickly becomes in conversation. I have noticed posts in Medium.com about no-code programming with many stridently worded comments to authors warning them of being overly idealistic about the future. There are people who feel adamant about the world of programming code being difficult if not sacred. The promise of a no-code approach for creating applications is often a point that is argued versus discussed. We would all benefit from more discussion given the advancement of the trend.
On the other side, we have people who are intrigued by the idea of not having to learn code syntax in order to create web applications. They have technical depth in various engineering, science or business processes and they just want to create applications themselves.
We believe there is an approach that encompasses both the experienced and the less experienced programmers. This is what we’ll be talking about at our SXSW 2017 panel with Mark Magnuson CTO of Concepture and Julie Shannan Director of Girlstart.org and the plan is provide answers to these questions:
1. What are the opinions and truths about the no-code application development trend?
2. Who benefits from building applications with tools that do not require writing lines of code, and how does this impact business growth?
3. If no-code programming continues to grow and evolve, what might be possible for a wider range of social, economic, and gender perspectives?
Give us a visit and a thumbs up or a thumbs down. You get to vote on the panel until the end of August. We are looking forward to hearing from you.
This article is based on content at http://concepture.com/not-a-code-generator-coders-drive-framework/
SXSW 2017 PanelPicker voting for this panel is here.
Community voting ends September 2, 2016.
Tom: What can BILDR do that I cannot do already with my existing development tools?
Mark: It’s an interesting question because you can sort of ask that of any level of abstraction in code. Let’s go back down to assembly language and ask what each layer on top of that does for you that you can’t currently do in assembly. On a technical level, not much, right? You can do anything you want at almost any level. It’s how fast and how efficient do you want to do that, and how many people do you want to give access to doing that. That’s really the difference. We don’t see it as much as we should replace code or we should make it to where you can just come in and pick from only this subset of things and combine those things. We see it as if you truly want to get to a state where you don’t have any code required to build an application that means you have to be able to consume and use all code.
We really take it from the perspective of: What benefit am I providing to the end user of this? I’m providing the ability to build an application faster and easier. I’m allowing you to build it with scale in mind from the beginning. I’m allowing you to consume code that others have created without having to go through the typical process of putting that inside of your application. The normal process is very rigid and very hard to do. It creates very brittle code bases because you have to understand everything within that other code base to make it work properly. Not that you’re not still dependent on that code working correctly. You are. But if we open it up and show how brittle or non-brittle that is to the world and we show how easy it is to recombine and reuse that code, then I think naturally that code will get better on the inside because more people will be using it. It’s a bit like pulling things down from NPM. The ones that use a whole lot, clearly, everyone knows they’re stable and is understanding that, right? We’re saying let’s do that, but let’s do it at a higher level so that not only coders have that ability.
Tom: What types of Web apps have already been delivered with BILDR?
Mark: Quite a few. Primarily to date, back office enterprise applications. When I say that, I don’t mean BPM tool type apps that kind of fit in between things. I’m talking about fully disruptive, complete line of business applications. So systems of record. This is everything from a website – it could be a website – all the way to full, up-and-down, ERP system managing quotes and customers and CRM and order taking and purchase orders and inventory, everything, paying installers, paying vendors, paying employees, connecting to all of your accounting systems, and connecting to just about any system you can think of. We probably connected to something similar to it over the last decade.
We kind of have this full spectrum of really simple, I need a calendar to put my work order on, all the way to I need to process litigation support, or I need to process mortgages in a litigation support process to facilitate expert witness testimony, something really complicated and a set of processes. Then, also, in the ERP systems, those are probably the most complex in terms of scale, number of users, number of transactions running through it, the dependency computation, how complex that is. When you’re doing last in/first out or first in/first out or exact match serialized inventory or all three of those things in one system and you’re tying it into a bunch of other systems to accommodate the rest of the business process, that stuff gets really complicated.
All of that, every system we’ve ever built, has been implemented without writing any code. For instance, we have 1 system that has 31 APIs going between a central office system that we built and a retail system that we built. Those 31 APIs were all configured. No code was written to do any of that on both sides. So the consuming side and the requesting side. Just about anything you can think of has likely been built with the platform at some point.
Tom: So BILDR is more than just a website builder.
Tom: Mark, give us an overview of the architecture of the BILDR framework.
Mark: Sure. BILDR is a full stack framework. That means everything from the frontend delivery of an application into the client browser or client mobile application all the way through the backend database structure, function services on the backend, as well as scaling the infrastructure up to handle whatever comes at the application. So it’s full stack through and through. The structure kind of is broken up into four main areas. There is the client delivery page or set of pages that deliver that actual application to the client. Then there is a middleware piece that handles DNS and resolution down into a specific application. Then all of that is translated from a set of metadata that defines an application for the client browser or client app.
On the other side of that we have two different things. We have data sources, which are inside of Microsoft Azure. These are scalable data sources, sequel databases, for relational databases, as well as Azure table data storage, BLOB storage, all the different file storage that is offered within Azure, as well as third party external Web service accessible data storage solutions.
Mark: I’m Mark Magnuson, CTO of concepture.com and bildr.com located here in Austin, TX.
Tom: Mark, what’s the relationship between Concepture and BILDR, and is this a startup?
Mark: Concepture is a 12-year-old company. We’ve been building custom applications for the entire time of our business. Instead of just building one-off custom Web applications, what we’ve really been doing is building a framework that allows you to build those applications without writing any code. Every one of those applications required some extension of the framework, which does require coding. So really what it is is it’s a framework that consumes code that allows you to build those applications using a higher-level language.
BILDR is the toolset that Concepture has produced over the last decade or so. What we’re doing is rolling that toolset out as a product to be consumed by others. We’ve been using it internally for a long time, deployed over 400 enterprise applications with it, and now we’re bringing that out to the world.
There are two parts to this post -
First – Will programmers no longer be needed?
Second – Should Citizens be allowed to code? (previously posted in the blog but noteworthy here)
Both of these questions come up often when talking about the emerging trend of no-code application development and the impact on programmers. We all tend to get worried to a point of jumping to conclusions when entirely new disruptive ideas are proposed – like – no code application development and promises of creating programmers without having to learn code syntax. What does all this mean?
The truth is programmers will always be needed especially those with deep full stack development expertise and really any programmer with highly specialized experiences. The more time we spend thinking about this new trend, we see programmers benefiting from increased opportunities to work with less experienced programmers using configurations tools that are no-code development platforms.
With software developments tools becoming more sophisticated and easier to use by removing the need to learn code syntax, people will think about problem-solving from a higher level of abstraction. Programmers can share or sell their existing code libraries with non-coders who use those unique libraries as a configurator in a no-code development environment. We see this being the way of the future and it means everyone benefits.
People who have an understanding of programming from a systems perspective and have deep technical expertise in a specific business area or industry can work hand in hand with experienced programmers to do even more complex projects – together. Coders drive the key development of the more complex underlying framework of new tools and more advanced applications. Non-coders can be configurators. This way programmers get to spend more time doing what they love!
Tom: Is BILDR an automatic programming tool that generates code?
Will programmers no longer be needed?
Mark: We’re not generating any code, first of all, and we will definitely still need programmers going forward. Coders are the engine that drive any good framework.
The real key difference here is that – we’ve never been here before either. We’ve never been at a place where you have enough [code] out in the world to where if you just make it consumable if you just take what’s already existing in the world and make it consumable, you don’t have to reinvent the wheel every time.
The previous attempts to do this set out what I believe in a wrong way. They came out saying, “I’m going to create this toolbox, and I’m going to let you modify the toolbox, like adding tools to it, but you have to work in this specific language, in this specific way, and this is your only method of interacting with it.” We’re a much more open framework. We allow you to write code in any language that can sit server-side in the JVM. You can write in C#. You can write in F#. You can write in Scala. You can write in almost anything you want, which is a huge differentiator for our framework.
In addition to that, we believe that the right way forward is not to say coding is dead. It’s that you can abstract to a higher level here, and you can enable hundreds of millions of people worldwide to have access to being powerful within this framework, whereas now to get there, you’ve got coding academies springing up, which are giving certifications very, very quickly to people to learn how to code, and they’re getting some benefit out of that, but the general response from the [developer] marketplace is not what they’re looking for really, what everyone’s looking for. The response is more, “We’ve been doing this for 10 years, and you come out with a certificate after 6 weeks. What do you know? You don’t know enough to be able to help me. You don’t know enough to be able to get in here and really do some hard work.”
What we’re trying to do instead is provide that linear path to bridge that gap. We think that someone after six weeks of certification and in a toolset like ours can be effective. They can go build actually running applications. It may not have every bell and whistle that the coder will come and bring to the table at that moment, but there is nothing that slows them down from getting there either. In fact, we accelerate the path to that. You come in, you build something, you get to your MVP, you either go learn how to code, or you hire experienced coders through the services marketplace to bring whatever it is about that needs to be brought about that you can’t currently do.
So we definitely see it as a different take on this problem. We definitely see it as a problem. We’re at a point now where we don’t have enough developers worldwide to actually facilitate the need that’s out there. We don’t have enough in terms of resources available for other people to learn how to code and learn how to program in an efficient way. We think we’re solving those problems.
Now this second part:
Tom: Do you think we’re entering into an era of citizen developers? What would that mean?
Mark: Like all other buzzwords, it’s a very loaded term. Citizen developers, from a coders or developers standpoint, sort of means like, “Well, anybody can do my job.” That term I think will get a lot of negativity from the developer community. I think what it really means is a positive thing for the developer community. What it actually means, my belief, is that you’re allowing people who can’t traditionally code or don’t know how to code or don’t want to learn or look at that black box of code as a black box and say, “I don’t understand that,” you’re giving them the ability to take part in the process.
What it doesn’t mean is that that person can just be a layman, that they have no engineering understanding, that they have no ability to walk down a logical path and solve big problems. I think a citizen developer still requires you to be somewhat of an engineer. Designers are engineers. Designers go in and take a vision out of someone’s head and implement a design around that. That’s an engineering process at its heart. It’s just that they’re making an artistic version of it, which I also see, by the way, coders as being artists. A lot of people see the term “computer science” and think that it’s just a matter of fact science. Really what it is is it’s a heck of a lot of art. You’re taking a problem, and you’re using your own internal understanding of how the world works, how this language works, and what your problem is, and you’re combining all those things into a package that usable by someone else. I see that as an art form.
It’s just that they’re making an artistic version of it, which I also see, by the way, coders as being artists. A lot of people see the term “computer science” and think that it’s just a matter of fact science. Really what it is is it’s a heck of a lot of art. You’re taking a problem, and you’re using your own internal understanding of how the world works, how this language works, and what your problem is, and you’re combining all those things into a package that usable by someone else. I see that as an art form.
That embedded process in the requirement for building software is never going to go away. You still have to have that understanding even if you’re at some point just speaking to a computer off in the far reaches of where we hope that developer gets to one day as everybody kind of looks out and says, “Well, at some point I just open my mouth and I speak to the computer, and it builds me what I want.” Even in that scenario, you still have to know what you want. You still have to be able to communicate it effectively. Even at the farthest reaches of this, you’re not going to get away from you have to be smart and capable and understand it all.
Tom: Does working at a higher level of abstraction mean we grow the pool of developers.
So citizen development, I see that as this is taking 20 million developers to 200 million developers.
Just like today, there are certain developers who can work in certain parts of the stack and others who can work others, and there’s a very small subset of people who actually can go from binary, from assembly just all the way up that chain and then also write HTML on the front end. Not only are there very few people that can do that, but who wants to do that? I’ve never met a developer who actually enjoys all the levels of that stack. I see this as just one more layer of abstraction.
That’s because the tools got easier.
The language has got simpler. They got higher level.
That’s all we’re doing here. We’re talking about a higher level of abstraction.
Citizen developers will be required. I think the term will just become – it’s just a larger developer pool, which is really, really needed in the world today. If you look at the statistics of how many projects are behind and how many aren’t even getting looked at and you have Andreessen talking about software eating the world, the whole world is sort of coalescing on this idea of we better get more people capable of building these things.
We see toolsets like ours as the facilitating tool for that.