The curse of the Development Framework
I’m currently working on a really cool and challenging project, in which we’re using quite some API’s and frameworks that are new to me. I already know WebDynpro for ABAP. I also know FloorPlan Manager pretty well. GUIBB’s are no rocket science to me either.
But there’s one thing that annoys me with every new framework I learn.
Every development framework limits the possibilities for the developer.
You see, WebDynpro for ABAP is a really good framework, which allows ABAP developers to focus on the functionality code, and model the frontend via click ‘n point.
Terrific, you can create really nice web-applications, without any knowledge of HTML. Great!
Except if you do know HTML really well and want to do some funky stuff. No-go in WDA.
I know, there’s the HTML5 islands, but those weren’t around when I first started WDA.
In any case, I don’t want to rant about WebDynpro. I do very much still love the entire framework. It forces a developer to split out business logic from the view, and to work according to the MVC principle. I like it. It’s perfect for what it was intended to do: uniformize SAP based Web applications both in look and feel, and software architecture.
Once you know the framework, you can do really cool stuff with it.
Once you get to know it. That’s the catch.
I’ve trained plenty of people in WebDynpro, and the typical classical ABAP developer can have quite some difficulty in learning it.
And there’s plenty of frameworks to learn..
Our current architecture looks like a stack of Jenga blocks and contains lots and lots of frameworks. Somewhere in there, you see webdynpro, which itself limits the developer, but you get a lot back for those limitations:
- Session persistency
- Data binding
- uniformity across applications
So with WebDynpro, there’s a positive trade-off. You lose quite some flexibility, but you gain a lot out of the box.
Floorplan manager, in it’s purest form doesn’t limit you too much either. You can just compose a complete floorplan with freestyle applications.
But then there’s the GUIBB’s. There are only a dozen of UIBB types, which mean they further limit the developer possibilities.
And then there’s the FBI, generic feeder, which only comes in two flavors: A form, or a list.
Just the idea of a generic feeder class already puzzled me. A feeder class was to intended to let the developer create the field-list definition, actions and data retrieval. A generic feeder class means that you pushdown the ABAP code even further down into some other framework, and try to strip out again, as much code as possible and replace it with configuration.
Sound like that old tagline again: “No developers required!”
Fact is, that every framework indeed further reduces the possibilities of a developer, up to the point that the developer can only do some really basic stuff and is practically obsolete. But then the complaints start coming in. The product is too limited. We want different behaviour…
So you ask the developer to implement these changes. Except that, the framework doesn’t support it. So the developer has to work around the framework, which usually doesn’t result in a nice solution, and is probably quite error-prone…
And that’s the curse of the framework: too little, and your developers go awol, too much and it renders itself obsolete. The more experienced your developer, the less he needs a framework, but the more he choses certain prefered productivity frameworks.
I like the WebDynpro framework, it manages to keep the balance, but can we stop adding more and more layers to it?