In 1999, I started my professional career at a mid-sized German hospital. In 2000, we had succeeded in bringing our at-the-time already ageing patient management and billing system through the Y2K madness that was happening all around without too much effort. Then the news came – although the system was Y2K-proof, it wasn’t built to handle multiple currencies, and the vendor had decided to discontinue the product. Looking for a replacement, we finally ended up using the combination of FI, CO, IS-H for patient management, PM for our building services and maintenance department. A bit later, MM and especially i.s.h.med for the clinical aspects were added as well. At the time, one of my main tasks was to implement various forms and additional reports. I already knew several programming languages at the time and had some experience with Oracle, Interbase and other RDBMS, so taking a dive into ABAP development was a natural choice. This was back in release 4.6D. Since then, I’ve worked for a few years one of the companies that make i.s.h.med and which is nowadays part of the Siemens AG. During that time, I had the chance to learn a lot about ABAP development both in customer projects and for add-on and product development. Since 2009, I’m with one of Germany’s largest inpatient and rehab healthcare providers. Today, I’m responsible for the development team that extends and enhances i.s.h.med and connects it with surrounding systems – but since the team is small and I can’t resist it anyway, I still write quite a bit of ABAP applications.
I actually knew quite a bit about Eclipse, even in conjunction with ABAP systems, before ABAP in Eclipse emerged in its current form. For my bachelor’s thesis, I designed and explored a modeling solution to generate “stuff” (a common technical term) in the i.s.h.med system. During that project, I learned a lot about Eclipse and its flexibility and extensibility – not only as an IDE, but also as a starting point to develop your own applications. Sadly, the prototype was never developed into a full project. At the time, I used cheat sheets to guide first-time users through my application. Although simpler and a lot less interactive, cheat sheets and the ADT Feature Explorer follow a similar basic principle that has proven to be very valuable to support new users.
Since I’m rather familiar with the “traditional” ABAP development environment, there was no real incentive for me to explore the ADT in its first stages. I use data dictionary objects a lot, and most of our development is still screen-based (dynpros), which are both unsupported. For DDIC objects, that will change, for screens it probably won’t. Combine that with the fact that you were basically cut-off from the existing documentation (descriptions and documentation texts) in the early releases of the ADT, and I think it’s understandable that I decided to concentrate on other issues and give the ADT some time to mature. At this year’s TechEd && d-code in Berlin, I took the opportunity to visit the DEV165 session and familiarize myself with the current state. I’m still not using ADT for my day-to-day development, mostly because nobody else in my team is and we’d lose a lot by splitting up the toolkit right now, especially since a full two-way transfer of the documentation is not yet implemented. However, I will be presenting the ADT during our team meeting tomorrow, including cristina.jitareanu, graff.christian and a number of colleagues who unfortunately haven't yet found the time to use all aspects of the SCN. I would also recommend it to daniel.vlkerts but I know that Daniel actually has had the opportunity to take a look at the ADT earlier than me, due to the fact that we have to support far lower releases.
