Skip to main content

Rapid Business Change and ABL Productivity

Printer-friendly version
Background
From its earliest days in the 1980s, ABL’s allure has been its productivity. Progress Software, then Data Language Corporation, was one of few companies which championed the advantages of fourth generation languages for increasing programmer productivity. It was the only company which succeeded in creating a 4GL good enough to write entire applications in the 4GL without resorting to coding difficult areas in C or other 3GL. Other 4GLs could get high productivity producing those parts of the application which could be written in the 4GL, but lost productivity when having to write 10-15% of the application in C in order to fulfill requirements. Not only did this C code greatly impede easy maintenance, but overall productivity was substantially reduced because the hardest parts of the application were still coded the old way. Thus, these languages were the worst case of the Pareto principle3, since the productivity gains were realized in the part of the application that didn’t take a lot of work to create anyway and the part of the application which was hard work was done the same as it always was4.

Naturally, languages have evolved since the 1980s. ABL has become less 4GLish (adding language constructs for finer grained control, e.g., to support the ABL GUI for .NET). Traditional 3GL languages have gained higher level structures like data sets which provide a greater degree of abstraction from the computational implementation. Perhaps more importantly, substantial evolution has occurred in tool support of 3GLs and in creation of libraries and frameworks to support these languages. Any code in a standard library or framework is code that does not have to be written, not only reducing the new code necessary to implement any requirement, but often providing some of the most difficult and time-consuming code. Thus, 3GL average productivity has risen relative to ABL. While studies are rare and many dubious, anecdotally this is a shift from perhaps a 10X productivity advantage in the 1980s to a 3X productivity advantage now.

Thus, one naturally asks the question of whether there is some development which would restore the relative productivity of ABL and, more importantly, help make ABL a language which provides the necessary productivity and nimble responsiveness needed to meet the needs of modern business.

ABL Productivity
The remarks at the Partner Summit resonated strongly with me since programming productivity has been a major theme in my career since 1979 when I created my first 4GL to speed development of business applications in AlphaBASIC5. In 1983, I developed and marketed a code generation tool for the OASIS CONTROL Toolkit. This quest for productivity was one of the main lures of the Progress product for me in 1984. In the early 1990s I created a tool called Specification-Driven Development (SDD) which produced ABL code from specification files and ABL code snippets. SDD was designed to result in no-compromise applications and resulted in very high levels of productivity and very stable and easily modifiable applications as well. During one large project the productivity of SDD for new application development was tested at a rate in excess of 1000 lines of integration test ready ABL code per programmer per hour, though admittedly with a less structured analysis process than I would use today.

AttachmentSize
RapidBusinessChangeAndABLProductivity.pdf73.88 KB