Is the coder dead?

Who needs coders when you can use a development platform? LV='s Rod Willmott and Hargreave Lansdown's Chris Worle debate the pros and cons of app platforms

Rod Willmott (pictured), director of fast track in innovation at insurance firm LV=, says the company is now completing IT projects five or six times faster than it used to, and the difference, he says, is all down to the company's use of the Mendix app platform.

Working on a range of applications, from launching application products into the consumer market to building portals for brokers in-house with "complicated interfaces", Willmott makes the company's use of LV= sound varied, and hugely successful.

Having announced Salesforce connection just days ago, Mendix seems to have become a particularly popular take on the "no-code" development platform model, and Willmott apparently couldn't be happier.

"You can't do it without some technical knowledge," says Willmott, perhaps squashing one of the many myths about such platforms, "however, we've been achieving five-to-six times the velocity of a traditional project, and there are reasons for that.

"One is that with the Mendix environment and those of its ilk, you can start putting something in front of the user extremely quickly.

"A person who is going to use a complex project of ours [when it's completed] can be looking at a fully-formed interactive screen, more or less the bones without the finer details within days," says Willmott

Comparatively, he continues, at the same stage users would be looking at just "a PowerPoint slide and a dialogue box".

He continues: "It was literally much faster to start with and it's flexible in terms of being able to change it."

Early dialogue with a "customer" on the end-result of an application and the ability to ask, quite literally, "is this what you actually meant?" now means it takes days rather than weeks, claims Willmott.

One-click deployments between environments and the removal of "low-level stuff you don't need to worry about" as well, says Willmott, enables many other applications to use " building blocks off the shelf" to get a massive leg-up as they're built.

"It takes out a whole, massive chunk," he says. "Not of coders, but technical people that would normally be involved in that stage of transition: things like workflow applications or internal operational capabilities were much repeated in our organisation."

Willmott says it comes down to, "what applied to department A will apply to department B very easily, as we're getting very much into a configuration space there - just really needing a facilitator who can explain how you go about setting it up, using components we've already used".

An alternative view

Chris Worle, head of digital at financial services firm Hargreaves Lansdown, doesn't agree one bit with the idea any part of a development project can be approached in such a project-agnostic, iterative way.

"It's a nice idea and something we'd love to be able to get to, but I think once you're at enterprise level - or even anywhere near, to be honest - then we've always found across the board on both web side and app side, that in practice all these WYSIWYG and ‘easy to use tools' don't really cut it.

"If you're aiming to deliver anything innovative at the heart of it, then from what we've seen, you're always going to be making too many compromises along the way."

Worle says that he "dreads to think how many weeks and weeks of time has gone into thinking about user journeys and specific UX [user experience]". His team - joined by external mobile developer Mubaloo - has been producing iPhone and iPad apps over cycles of several months, capable of highly idiosyncratic functions to meet the company's business case.

"I don't think you'd be able to get those minor details in an off-the-shelf product," he says.

[Please turn to page two]

Is the coder dead?

Who needs coders when you can use a development platform? LV='s Rod Willmott and Hargreave Lansdown's Chris Worle debate the pros and cons of app platforms

But Willmott's argument has already contradicted this point. According to him, having underlying code and conventions already organised by Mendix leaves plenty more time for these things, as well as apparently being faster. Worle won't be drawn on the speed element either, however.

"I think, ultimately, we may have been able to deliver something quicker [on a platform such as Mendix], but I think we would have delivered it with about one-tenth of the functionality we are delivering to our site and apps," he claims.

"If you go down that route, you're limiting yourself to building on the blocks someone else has delivered, and other people are working with, so it's always going to constrain you," he adds.

But Willmott feels constrained only by the level of expectation the rest of the business seems to have from his new, super-charged development team.

"If you've got a tool that allows you to develop something very quickly with very little effort, you have a very small team by necessity on it," says Willmott.

"Therefore, if you're running a project - and we can run quite large projects with Mendix - with one person delivering on it, when that person's absent from the office, the response from the business can be interesting."

Next-day delivery

Willmott explains how "even though something is now delivered in days, not weeks or years" it can raise complaints if the single person who is now building the project is off for two days, and the short project runs two days over.

Are raised expectations the only drawback of a non-coding platform?

Well, almost. While Willmott at LV= finds involving end users in development to be an advantage, Worle is happier inviting fewer cooks into his kitchen, reducing the risks to the quality of his broth, so to speak.

"I've always been slightly reluctant about giving too much information and control to too many people around the business, because I think you end up with a carnage of different people getting involved and having a play, and being able to change too much," he says.

"But often they don't have the knowledge or understanding on some aspects of it. So control is certainly an important aspect for us as well."

Worle perhaps sounds like some of Willmott's more dyed-in-the-wool coders. LV= isn't without its fair share of those who are finding transition a challenge.

"While we haven't got to the extent of replacing or moving anybody in terms of physical head numbers at the moment, it has changed the way we go about the business," admits Willmott.

"We were a fairly traditional waterfall methodology company, but now this rapid throughput is facilitating proper collaborative work with the business. So we now deliver projects without the overhead we had before."

Rather than deploying a business manager and a technical project manager, a single project manager will do the job, for example.

"And this also delivers much more synergy with common sense decisions rather than just throwing things over the wall," he says.

But not all coders find it easy to adapt to this approach.

"We've found if you take a .NET developer, they're perfectly capable of working within the toolset," he says.

"They don't find it difficult, but they do find it frustrating that they don't have ways to - say - manipulate the memory management modules. But we tell them they're not here to do that - they're here to deliver business functionality, and can do it faster this way. But that's not always the way they identify themselves," says Willmott, describing a "juxtaposition between business objective and traditional programmer self-image".

Graduate recruitment

Controversially, though, Willmott explains how "a graduate can be taught this technology very quickly, and we make them fully-functional in the environment within three to six months.

"New graduates generally have a very hybrid approach to delivery, so they can go and sit with the business, work out what the process is, do the modelling and tune some of the underlying, more technical pieces of the journey.

"When you take a developer who's been through a traditional environment and is used to sitting in a dark room coding, they don't adapt to that very easily. So you do need a different breed of people to do this stuff."

While both companies offer robust arguments for their respective use cases, the debate really does hinge on the end result, and how it suits a company's vision. But development time doesn't lie - LV= really does seem to have nailed turnover of quality applications in mere days.

However, from a skills view point, could such transitions be causing a new, even more serious problem to bubble under the surface as skilled coders begin to feel devalued by an off-the-peg environment?

That's a conversation for another time, but stay tuned to Computing as we touch base with coders in coming months to find out more.