Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor


Among other things, Latvia is known for its numerous political parties: 8 major parties share the scene with 15 minor ones, all this with the population less than 2 million. As one joke goes, “2 Latvians make 3 parties”. 🙂

The same can be true about the programmers and IDEs (Integrated Development Environment): there are as many opinions as there are programmers, and more.

In the ABAP world, we currently have a choice of two IDEs: traditional SAP GUI environment (commonly referred to as SE80) and ABAP Development Tools (ADT) for Eclipse.

SE80 is the familiar environment, with many features custom-tailored for ABAP development. Data Dictionary (SE11) and class editor (SE24) are still superior to similar features in ADT. On a flip side, it’s no longer improved by SAP and is essentially on a life support. Also, the Mac users can only use SAP GUI for Java, which does not support new ABAP editor (a major drawback).

ADT is, of course, cool, shiny, and new, SAP is investing in the tools and eventually it can become the only IDE available. (Although with the recent “renewal of vows” between SAP and Microsoft I wouldn’t discount ADT for Visual Studio as a contender.) It offers better support of OOP (except SE24 part), unit testing, and refactoring. It is a universal IDE with features that never existed in SE80. This can be a blessing and a curse since it comes with busier UI and sluggish performance.

So, which one is better? That’s a loaded question, as evident from the recent Twitter storm and a follow-up blog by florian.henninger. But does it really matter? As honorable enno.wulff wrote in a blog comment, “The tools do not make a good programmer! The programming skills do.”

New is not always best and old is not always worst. Finding what works best for specific use case is the key. How do we avoid mistakes on this path?

It is OK…

…not to like an IDE

There is no point arguing about personal preferences. One thing to keep in mind though: while SE80 is as good as it gets, ADT tools keep changing. If you didn’t like it before, give it another try later.

…trying to “convert” others

If you are an ADT enthusiast, show others how to do things better and more efficiently in it. Don’t be discouraged if your point of view is not immediately and universally accepted.

If you are an SE80 fan, show what makes it more productive for you. At minimum, others will learn from your experience. At maximum, SAP might listen and incorporate the desired features into ADT.

It is not OK…

…to restrict ADT use by your development team

Unless it’s not available for your SAP version, there should be no reason to restrict the use of ADT. One of the principles of adult learning is that knowledge needs to be applied on practice in order to “stick”. Developers need to learn new things and the best way to do this is at work where they can use new skills right away.

…to force adoption of ADT

I liked the philosophy outlined in one of the ABAP presentations: “Make ADT available for those who want to use it. Don’t force anyone to use ADT.” Education and positive reinforcement are much better tools and not just for parenting.

…to not be willing to explore new tools

If by this time you haven’t tried ADT in Eclipse even once, I hope you’ve already saved enough for retirement. You don’t have to like it (see above). But there are no more excuses to not even try. If for any reason it’s unavailable where you work, the ABAP Trial version comes with both SAP GUI and Eclipse ADT. And there is a completely free download version available, although CAL option is much more convenient and inexpensive by the US standards.

* * *

IDE is not the means to an end, it’s just a tool. Whether one uses ADT or SE80, it doesn’t tell much about their programming skills or personality. Instead of the “IDE wars”, can we focus on washing our hands, err… writing clean(er), testable code?