Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Danny Severns, IT Director for Dunn Tire and knee-deep in COBOL business systems.
Who are you?
My name is Danny Severns. I'm the IT Director for Dunn Tire, a tire distributor and retailer with 35 stores in New England. Although I'm currently working at corporate headquarters in Buffalo, New York, my Dallas twang gives away my southern roots.
I came into coding by accident, but I've stayed because coding offers the creativity that was lacking in my previous career (accounting/finance). During the first part of my programming career, I worked with business systems, coding applications primarily in COBOL. Now, I'm currently modernizing legacy applications (primarily COBOL) and systems.
What do you do?
The process of modernizing legacy apps generally encompasses three layers: business logic, data and presentation. The types of projects I work on include typical business transactions, from Point of Sale (POS) and order entry, to warehouse distribution and inventory, to accounting and billing, and so forth.
To understand the business logic behind the apps I'm modernizing, I like to watch the way users work with their current apps. I believe in getting down to a street-level of understanding of how the business processes flow. A case in point is order entry. How do orders come into the company? By phone, fax, e-mail, Internet? Business processes tend to be fluid, and change frequently and easily, whereas apps don't change as frequently over time.
In addition to looking at the business process flows, I analyze the data side (for example, where the data's been historically stored) and how the data is architected. In a modernization project, I'm often moving data from a flat-file to a relational database. So, I make decisions about what to do with the data. As an example, any kind of transactions or temporary files (journals, transactions files, etc.) need to be processed with high-performance technology designed for speed, while historical data (for reporting purposes) typically needs to be moved to a relational database for easier querying.
At the presentation layer, I'm typically converting character-based applications to GUIs. I believe the purpose of GUIs should be more than wanting something to look spiffy. GUIs should help make users more productive by enabling them to multi-task versus the linear single-tasking previously imposed by legacy models.
My overarching paradigm is that the apps I create should be flexible and able to change without touching or changing the source code. That is, the tbusiness logic, data and presentation layers should be kept separate, to allow myself or other future developers to easily change any one of the layers without changing the others. For instance, if a great new browser interface comes along next year and I want to update to it, this shouldn't make a difference to the existing business logic or data layers.
What I like so well about programming is the variety. A task I predict will take 10 minutes actually may take four hours, and the task I had allocated four hours for may take less than 15 minutes.
What is your development environment?
Over the years, I've learned five programming languages, and C is my favorite for its power.
However, I work primarily in COBOL. Nothing beats COBOL for business apps. I can give three primary reasons:
From a data perspective, COBOL was created to handle business data in a way no other language has been set up to do.
Generally, business applications are transaction-oriented, and COBOL excels at handling large volumes of transactions.
COBOL is record-oriented.
A primary reason that I've stayed with COBOL and an important attribute of it, is that it runs on all platforms with one code set. A lot of developers who know very little about COBOL wrongly believe this was not possible until Java came along, but COBOL developers have been taking advantage of this important feature long before Java.
Because I've always supported multiple OS environments, COBOL's complete portability is a significant reason that I've stayed with the language.
Because COBOL is a business language, it does not lend itself to interfacing with the OS or hardware, although many features have been added to the language to handle those issues and insulate the developer from the complexities of those interfaces. But when there is not a compiler feature available to provide an OS or hardware interface solution, one can always handle the coding issues with C/C++ because COBOL interfaces well with those languages, as well as others.
I use SlickEdit tools in a Windows environment, but I'm developing for apps running on UNIX/Linux. Since the early ’90s, I have used Flexus GUI tools that allow for the use of a Windows GUI interface across all OS platforms when using their software, thin-client technology. The Flexus tools are OS and compiler independent, making the presentation layer as portable as the business and data layers.
At Dunn Tire, my team and I are in the process of converting apps from Micro Focus COBOL to Veryant isCOBOL. Veryant compiles to Java class files, so we're really in the process of migrating from pure COBOL to Java by leveraging our legacy code base, without modification.
Although we'll be using straight Java for future new development, because we use OS-neutral tools, we're not forced to convert or rewrite our legacy code.
To reduce the potential for disruption to our day-to-day business during the migration, we use the FairCom c-treeACE database, which has a broad spectrum of APIs, both legacy and modern, and a flexible development environment that allows our team to move seamlessly between relational and non-relational systems with no consequences to the source code. As part of my current project, my team and I have converted the existing Micro Focus COBOL to c-treeACE files in its ISAM layer. One reason for doing this is because ISAM delivers the speeds required for point of sale, where customers buying snow tires have no patience for waiting on slow processing of their work order or credit card approvals, especially at the height of our busy season. C-treeACE also has a SQL layer that lets us query, mine data and build reports that would be otherwise difficult using a non-relational system.
I've been looking at Oracle Swing as a Java framework, because my team will be incorporating mobile devices into our warehouses for distribution, inventory tracking, etc.
What is your coding pet peeve?
I, along with probably 95 percent of all coders, would have to say documentation is my coding pet peeve. Documentation is like the big mess in the kitchen that waits after the enjoyment of cooking and eating a fantastic meal.
The naming convention I find "handy" (I can't say I have a favorite) is Hungarian because it has shortened things up for COBOL naming conventions by taking out the dash requirements and using abbreviations with upper/lower cases.
Because I'm modernizing apps that may be as old as 30 years, I run into abbreviations that make sense only to the original coder. As a result, I don't like highly abbreviated short names that don't give a good idea of what they represent. I'd like to think that the future coders who will modernize my code will know better what they're dealing with when they're looking at my apps!
How did you get started programming?
As I mentioned at the beginning, I came into programming by accident. I started my career as a CPA, which led to Controller and CFO positions at three different, multi-national companies.
The first of these companies used a service bureau for data processing (DP). During my tenure, we brought DP in-house. Because the service bureau wouldn't sell us its apps, we decided to duplicate them ourselves. For several years, the DP manager and I worked together to duplicate the functionality of the apps.
After completing that project, I moved to the next company, where the general ledger systems had been coded by an EE and, unfortunately, they functioned like code written by an EE! (Guess it takes a financial professional to recognize that.) Because I could never understand why the DP guys claimed it would take 20 man years to change a date on the left-hand side of the ledger to the right-hand side, I decided to take matters into my own hands by enrolling in programming courses. In those classes, I discovered I liked the creativity of programming, and so I've been programming ever since.
The developer community is great at helping each other and sharing their knowledge and code solutions to business problems. I've used special listservs or forums to stay in contact with other COBOL developers, seeking and giving help in resolving problems and applying current technologies.
I've not used social media forums like Twitter, LinkedIn or others, as a source for exchanging technical information or discussion.
Over the years, I've been the most active on the Flexus listserve, and it has been an invaluable tool. I've been able to contribute to the knowledge base that has been developed over the years.
I'm also an active reader of the CodeProject Daily Insider, which has led me to many helpful resources. I've relied on Code Project for help with C/C++ issues over the years. Because C/C++ is not my primary language, I haven't felt I could contribute much to the forum. Perhaps I'll be able to do so in the future with respect to Java.
What advice would you offer to an up-and-coming programmer?
It's essential to keep an open mind and learn as many programming languages as you can, so you have a full coder tool box to solve business problems with.
Nowadays, most people aren't staying at jobs for more than five years, if that long, and they never know what the next company will need in terms of skills. So, instead of thinking C# is the only language worth knowing, build up your language skill set. You never know when you'll be asked to write a driver or something requiring procedural coding. C# will frustrate you if it's the only language available to you for this kind of task.
