Low-code tools may be a developer’s best friend, according to experienced coders-turned-entrepreneurs in the field. Mark Roemers, founder of the pharmaceutical-centric SCM applications and hardware provider AntTail, successfully used new, low-code tools to help him get his company off the ground, and he has some crucial advice for enterprise-based developers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
AntTail’s job is to produce and maintain both the software and sensors that help users keep track of important pharmaceutical deliveries and make sure that they arrive both at the right time and at the right temperature. But by leveraging the support of a low-code solution provider called Mendix, a Boston-based PaaS provider that is now available on IBM Bluemix Roemers said he is able to rapidly develop either apps or portals for his customers that can specifically target the precise needs of their customers and integrates with the sensors they produce.
And even though Roemers is an experienced programmer, he still was able to find value in the capabilities provided in free, low-code tools. He admitted that he had not programmed for close to 20 years, but despite that fact — and his initial skepticism — it did not take him long to learn how to use the tool and produce a quality portal. Now he says he can produce a portal in three to four weeks, all without the typical backend support and overhead that is usually associated with enterprise portals.
Does it really work?
Roemers said that there is a steep learning curve for those even those experienced with languages like Java, but that it took only a few weeks to become extremely productive with Mendix’s services. He advised that other developers should look into these low-code tools as a way to create valuable proof-of-concepts without reaching into either their company or personal budget.
“You can get yourself up to speed and knowledgeable … without incurring any costs,” he said. “As a company, you can build a complete application [and] demo it as a portal or an application on a tablet,” adding that his company did not even purchase any licensing fees until they had their first paying customer.
Roemers said that the time spent developing is brought to a minimum with the tool. His entire “team” consists solely of him and one other partner, and they do not even spend the majority of their time writing code or building the apps.
“I spend about maybe 10% of my time programming, and it’s basically adding little stuff that people ask,” he said. “So we do a release about every four weeks.”
Moving out of the dark ages
Roemers strongly believes that better productivity can only come from utilizing better technology, likening old, large-team development processes to the use of dikes for water as opposed to the use of modern water-management technology.
“That’s a bit how we make code. If you’re coding Java or Angular by hand, let’s say, it’s a bit like shoveling a dike,” he said. “Now we use pumps and sand and water and large shovels, large equipment … it’s more efficient.”
Time for a new image?
The other aspect of development that Roemers stresses is the inclusion of coders in business meetings. He believes it’s important that the coder be able to sit in on a meeting, have someone lay out the business needs and have the coder put together a working prototype as the needs are being laid out. Roemers does, however, recognize the fact that this is a change from the usual “image” developers have maintained.
“It also asks for a different kind of programmer,” Roemers said. “He needs to wear a tie, use some deodorant and sit in a business meeting to understand the logic behind the coding that goes on.”
Roemers also stresses the fact that developers need to be able to show some kind of tangible business value that can be achieved with their creation. Without it, he says that developers are almost making an empty promise. A database that can hold millions of records may be impressive, Roemers said, but unless it can serve a specific business function, it can’t be considered very useful on its own.
Maybe developers don’t need to start wearing a suit and tie just yet, but it may be a good time for today’s coders to think about how much they are communicating with those dictating the business needs. Or, in some scenarios, maybe it’s worth considering the option to “jump ship” and dictate your own business needs.