The Way of the Developer

If you’re working in IT you probably have heard this urban legend of Rapid Application Development frameworks being the silver bullet for delivering great software at unprecedented speed.

It’s understandable that the business would love to simplify and accelerate the development of software up to the point where trained monkeys are able to do the job; yet software development is  a craft to be mastered and hence it remains questionable if ever quality software can be developed by simply “clicking it all together.“

Sure, it may be desirable to reduce the complexity of software development and hereby reducing the time to market. Yet, betting on shiny tools sounds like betting on a dead horse to me. We may be better off acknowledging that it takes skills and practice to develop quality applications and start treating developers with more respect. In times where Software is Eating  the World – Developers are the new Kingmakers – and business better let go of the dream of inexperienced developers being able to deliver the next “killer app”, just because of a oh-so-shiny tool or framework.

With this blog post I want to shed some light on the mindset of developers and provide some arguments why I believe that it will always require skilled coders to build great (enterprise) applications.  The way I see it there are  three commonly seen problems with Model-Driven Architecture (MDA) and Rapid Application Development (RAD) tools:

• Hiding complexity
• Runtime dependencies
• Lack of extensibility

Let’s have a closer look on all three.

Hiding Complexity

Simply put: no magic tool can reduce complexity. They may be able to hide complexity by applying defaults to support the most-common straightforward scenarios and use cases in a given domain. If model-driven tools would support the whole set of functionality provided by the underlying programming model or API they would be equally complex.

So, what happens if you need to do something outside of the supported standard scenario? For many hyped tools the answer is: you  will waste the productivity gained using the framework trying to somehow make the damn thing tool do that one thing it cannot do out-of-the-box.

A related problem I see is that many developers only familiarize with the tool and never bother to look behind the scenes to truly understand what exactly it is doing. Those developers will never be in control, but  depend on the tool. Hence, there will be zero room for optimization. And be warned, sooner or later in your project leaky abstractions will surface and your project will be doomed if no one actually understands how things truly work under the hood.

Consequently, most  developers I know would always favor a well-documented API shipping with source-code over a shiny model-driven tool, because it allows us to look at the code and understand what it does. There’s nothing wrong in using libraries and frameworks (the opposite!) as long as we can have a look at what they do and how they work. This way, we actually learn and master all these layers of abstractions we use and build on top of!

Runtime Dependencies

The worst breed of development tools comes with runtime dependencies. Why? Because they are the prime example of proprietary technologies resulting in vendor lock-in! A Rapid Application Development tool that actually accelerates the process of coding during the design-time is a great thing – but only if it is just generating the code people would have typed in manually. No more, and no less!

And let’s be clear, “writing the code” is hardly the limiting factor in developer productivity! Either we know the syntax inside out or we got code-completion to help us out. “Writing code” is the least amount of the job… in fact, we spend much more time thinking about how-to best implement the requirements and how-to best integrate our code into the overall project (spells: Software Architecture).

Another kind of my ‘favorite‘ tools are those that actually generate coding! Seriously, let me say this loud and clear: blowing up the code base with redundant coding blocks is the least thing we want (unless you pay us by lines of codes!) Such coding blocks are much better refactored into a template, which one calls passing the unique parameters. (Have a look at Spring templates if you want to see a great example of this!)

Lack of Extensibility

Last, but not least any tool or framework that wants to win developers hearts better be extensible or provide means to write plugins. If a tool restricts the feature set and hereby limiting our choices, it’s heading into a dead-end street. Allow us to integrate our own favorite tools, plugins and frameworks and we will fall in love with the framework. Even better, we even help improving it by adding new capabilities. Hey, we may even start talking about it and spreading the word – increasing its user base!

There’s Hope

Now, don’t get me wrong here. I’m not saying that MDA or RAD tools are bad and useless per se. If they avoid the pitfalls outlined above they can be of great use! There are actually tools out there that do get it right, yet they may look different from what one would expect. And that’s because they target developers and not chasing the dream of having business-oriented people clicking together enterprise software.

One of my favorite RAD tools out there is Spring Roo: it’s console-based with first class code completion and hinting, it generates standard Java code and all runtime features can be simply removed if one should decide to continue the trail without Roo. It is extensible so the developer community can integrate new features.

Speaking of which… we actually just did that! Thanks to SAP Research we got Spring Roo Add-Ons for SAP NetWeaver Cloud, which support creating full-fledged web applications incl. persistence, exposing RESTful interfaces and MVC within mere minutes. And just a few days ago they released another Add-On allowing developers to add backend connectivity via Gateway with just a few console commands.

Now, that’s the kind of RAD tools developers love to use!

Synopsis

I fully agree that the “developer experience is broken”, yet improving the tooling is only one side of the equation. Improving the processes is equally (if not more) important. Let’s remove the barriers between business, IT and development (think of DevOps, Teams of Ten, etc.) Let’s embrace agile methodologies instead of making developers suffer from endless change requests following the waterfall approach.

As technology is accelerating it is more important than ever to provide developers with a bit of room to explore the new possibilities in order to keep our skillset up-to-date. Give us good training material and well-documented APIs and frameworks to use. Grant us the required time to up-skill the team – prior to development! And provide us easy access to  software/APIs to freely test-drive the technologies to familiarize with them.

When it comes to tooling there are more important things than nice looking modeling frameworks. Give us platforms that support hot-code deployments to reduce turn around times (aka “batch processes“). Give us better debugging and analysis tools. And give us tools that make it simpler and more efficient to develop in parallel across distributed teams.

If we talk about accelerating the process of developing and shipping quality (enterprise) applications (and not flashy PoCs, demos or prototypes) then we may be better off questioning the status quo of today’s common practices and not just tools. Stop rushing products out the door. Stop turning proof-of-concepts into products. But most and foremost: accept the fact that software development is a complex business and that it needs skills to do it!