The OpenEdge Hive

Changing the programming culture can eliminate many problems, without the need to develop skills and expertise for a new tool.

So, follow the call to revolutionize your development department's culture and usher in a new era of productivity and quality...

Introduction

Lately, I had worked at a Progress shop, where a top-down approach was demanded. That is, everything is in one program. You start reading at the top, and finish at the bottom of the file. Whatever needs to be done, is being done right there. They have thousands of programs, most of them copies of other programs, containing further copied and pasted code-snippets from even more programs. There are no naming conventions in the DB. I haven't seen such a situation since the early 90s!

In an attempt to solve their problems, they are now switching to Oracle.
And that makes me very sad. You see, the real reason for their problems is not PROGRESS, but their approach, the culture.

Maybe, switching to Oracle will solve some of their issues, as the Oracle culture is being formed as we speak. The PL/SQL guys are using a different approach – and are allowed to do so.

The folks of the old culture, however, are forced to deal with this ancient methodology, and are being frowned upon when things go wrong. I dare to suggest, that if they would move to the 21st century, and train their programmers in structured programming (not OO, just plain and simple structured programming – i.e. separating UI from backend, standardizing and encapsulating certain logic, instead of copying and pasting) they would solve most of their problems, too; without collecting a whole boatload of new problems, inherent in Oracle, and by using two systems in parallel.

Change in Culture Without Disrupting the Business

Here's a step-by-step guide to modernize your application development culture. It is much less risky, costly, and disruptive than switching to a different tool:

1. Step: Making the decision and explaining it to the developers

We are all afraid of change. Especially, if it involves acquiring new skills. It is so much easier to accept and embrace change, if we understand what is happening and why. In order for this endeavor to work, the buy-in of the developers is needed.

2. Step: Providing training and mentoring

People have to learn the new approach. Learning means training – there's no way around that. But you do have a choice about what kind of training you want to pay for:

• Trial and error: tell the folks “you gotta do it” and let them scramble to figure it out by themselves.

• Hire a person who is both experienced in the new approach, as well as capable of teaching it to your developers (like myself, for example :) ).

While the first option saves you the expense of a consultant, the second saves you the expense of failed trials. Also, the second option provides an immediate, clear direction.

3. Step: All new programs are following the new approach

Obviously, any program that is written using the new approach doesn't add to the problem, but is part of the solution. It allows the developer to practice the new approach, without having to worry about regression risk (which is an important concern when touching existing programs).

4. Step: Identifying and standardizing common logic

Anything, that used to be copied and pasted in the olden days, now goes into a standard procedure, which can now be used by any program that needs it.

Note: So far we haven't touched any existing code! However, the culture has been changed, and the bleeding has been stopped!

5. Step: Modernizing some of the existing, old-fashioned programs

“If it ain't broke, don't fix it!” However, if a program needs to be fixed, enhanced, or adjusted anyhow, depending on the magnitude of the necessary changes, it might be worth restructuring the program to follow the new style.
Important: Before doing so, I would suggest to find a few test-cases and write a test-program that can be used on the new version, to ensure that the overall function of the program wasn't unknowingly modified.

You might wait for a 6th step, asking to rewrite existing programs. But, I don't think this is necessary. If a program doesn't need to be modified due to changes in the business needs, or due to bugs, there is no need to touch it. Just leave it as is. That, to me, is one of the biggest advantages of a culture-change, versus a tool change!

Main Advantages

I think the advantages of such a culture-change are easy to see:

• very inexpensive – aside from hiring a consultant for a few weeks to help getting started, and a temporary reduction in productivity of the developers (which is partially outweighed by the increased quality of their work) while they are getting used ot the new approach, there are no further costs.

• Very easy – no new technology has to be researched, acquired, installed, learned, and integrated/connected to the existing system. The technology stays the same, only the way you use it changes.
• Very smooth transition – there's no need to worry about which module to convert first. There's no disruption of service, when switching to the new system, since the new system is the same as the old one. Only individual programs are following a different style. But that style is transparent to the rest of the system.
• Much easier to find new employees – no young kid wants to do top-down programs. Most don't even want to do anything but OO. However, smart kids can make a transition to a nicely structured procedural approach. Also, most of the ABL developers that worked on applications that were started after mid 90s are familiar with structured programming. These folks usually have a very hard time being productive in a top-down environment, not to talk about them being excited about their work.
• Future-proof – Ah, this old slogan! :) What does it mean? Is it possible anyways? I find, that by separating the logic from the UI, no matter what UI comes around, you'll be better off, than if your UI and logic are in the same program. So, hey, at least you won't have to rewrite the back-end, but only worry about a new front-end. I guess, that's as future-proof as it can get...

Conclusion

So, in short, before considering switching to a new tool it might make sense to examine your departments culture. Maybe a change in culture can eliminate most of your problems. It is far easier, and far cheaper.

Thank you for your attention and your comments. And much success in making the worlds best application using OpenEdge!