ResQSoft

The Contractor Silo Problem

noreply@blogger.com (Big Iron) — Fri, 21 Oct 2011 11:00:00 +0000

Let's suppose that you have a large system you'd like to redo for the web. You could get it translated, but you don't want the likely performance and maintainability problems associated with wholesale line-by-line translation. In fact, you don't even want the new system to look like the old one: you want slick graphics, customized and stylish menus, dropdowns, radio buttons... the works. In other words, you want to rewrite it.

If the system is big, you might at first consider giving it to a big integrator to redo. The first problem with that approach is that nobody has 80 highly productive developers just sitting there waiting to start your legacy modernization project. Firms may have a few, but not enough good ones.

Another approach is to divide the work and give it to 3 or 4 or 5 firms. Not a bad idea, because they will compete, and you won't have the "entrenched contractor" problem that we hear so much about. There's only one difficulty: how do you get them to write the code in a consistent style, so that it all fits together and looks like one team wrote it? Because if not, you will get 3 or 4 or 5 "silo" implementations, with the interoperability and maintenance problems that go along with it.

You can't solve this problem with a paper architecture, but you can solve it by implementing an architecture for the entire system and directing the contractors to use common code and put their unique business logic on one place. That's what ResQSoft(r) Engineer gives you -- you can have all the routine code written automatically, including the architectural code for the entire application, and then the contractors can fit their implementations into the correct spots. After all, getting rid of the silo implementations is one of the main reasons for legacy modernization in the first place.

Engineer gives you a best practices, MVC style architecture in Java or .NET -- not on paper, but in working code. That's the only way to tie it all together!

COTS Software

noreply@blogger.com (Big Iron) — Thu, 25 Aug 2011 08:49:00 +0000

We get a number of inquiries about Commercial Off the Shelf (COTS) software. The reasons vary: some want to know if we can modernize the COTS software they are using, and the answer to that is "Yes". Some want to know if we can modernize their existing software, saving them from the expense and disruption of buying and installing a COTS software package - and the answer to that also is "Yes".

Some organizations who have old software believe that their only alternative is to buy a COTS package. And many advisors advocate doing exactly that, because our industry has a poor track record when it comes to rewriting software, or writing new software from scratch. The internet and trade journals are full of stories about software project schedule and cost overruns. And in most of those stories, the vendor blames the customer for changing the requirements or some other fault.

We can avoid those problems for you. We can give you a new system, fixed price, according to a schedule that we will meet. If you are running an older COTS package, we can give you the same functionality without ever needing to work with the source code to the old package.

COTS package implementations have their problems, too. The software never does exactly what you want "out of the box"; any major software COTS package needs customization and programming to make it work in your business. And your workers have to adapt to the new system, which probably will have rules and restrictions that are different from how your business currently operates. A DMV customer service representative takes 6-9 months to become truly productive, for example; what do you think will happen when you give them an unfamiliar system that works differently from what they are used to?

If you take 5 years of COTS software package license cost for comparison, we can save you money. Sometimes, we are less expensive than 2-3 years of licensing cost. And always, if you take the full cost of the COTS solution, including the hardware and training and customization and business impact, we can almost always save you money.

Why not have a new system, maintainable, easily modified, that you own completely and that works just the way your workers are used to?

Demo, Demo, Demo...

noreply@blogger.com (Big Iron) — Mon, 22 Aug 2011 18:36:00 +0000

We get a lot of requests for a demo. And there are a lot of vendors who will demo "at the drop of a hat". It's even possible, and reasonable, for the vendor to record that kind of demo and make it available to run anytime. After all, a canned demo is a canned demo -- so there's no real difference between a recorded one and a live one. Over a Webex, you don't have the opportunity to look under the covers anyway.

But, looking under the covers is exactly what a customer needs to do. We produce modernized code that looks like programmers wrote it for a new development effort -- there is no trace of the old Natural or COBOL or other legacy code unless we're asked to include it as comments somewhere. And of course the new programs have a completely different structure from the legacy code. That a big and important difference.

The two big risks in modernization are performance and maintainability. If you're coming from a mainframe environment, probably the users are used to snappy screen response, even if there are thousands of users. If you give them a system that is slower than they are used to, do you think they will be happy? Of course not.

If you translate the old code line by line, there are shared functions and classes that can become a bottleneck in the new application. Performance problems typically surface at user loads of dozens, or perhaps hundreds, of users. The other issue is maintainability, which we talked of in another blog post.

But it takes a technical assessment, and looking at code, to understand the difference. If you just go with the fanciest demo, and the slickest sales pitch, and the discounted price, the rude awakening could be 6 months down the road. We won't always do a slick demo, but we will explore all the technical issues with you and show you all the code.

Some of our best customers went down the wholesale code translation path first. We invite you to join them and experience the benefits of our freshly written, high performance code for your mission critical applications.

Out of the Frying Pan...

noreply@blogger.com (Big Iron) — Tue, 05 Apr 2011 16:14:00 +0000

Some legacy system owners are suffering from license fee increases of 20% per year, and this is fueling renewed interest in modernization. In the past, there have been a number of vendors whose proprietary software product (or company) has been bought by a large firm whose clear intent is to keep raising the license fees until the last customer is driven away.

For a long time, COBOL was thought to be immune to this kind of price increase. After all, no company "owns" COBOL - it was invented by a committee of members representing 6 computer manufacturers and 3 US Government agencies, sponsored by the US Department of Defense. But from what we hear, customers are starting to experience these same kinds of price increases with COBOL. One particular customer was hit with a 38% price increase, we're told, and we hear of 20% per year increases from more than one source.

There used to be many different COBOL vendors. First, all of the older hardware manufacturers provided a compiler: IBM, CDC, H-P, Burroughs, Univac, Honeywell, DEC, Wang, and others had their own versions that ran on their machines. Then there were the independent vendors: Realia offered a great compiler and CICS emulator, Ryan-MacFarlane had RM/COBOL, AccuCOBOL was available, and even Microsoft offered a COBOL compiler. Now, it seems all but one are gone, except for a couple of mainframe COBOL offerings.

We see companies offering "modernization to COBOL" for users of Software AG Natural, IDEAL, and other proprietary languages. But today, when you want to run COBOL on anything other than a mainframe, Micro Focus has the overwhelming market share. And their licenses are not free.

If you want to get away from paying hundreds of thousands for programming language and runtime licenses, or even millions... is it a good idea to switch to the COBOL market leader? Micro Focus makes a great product; but do be sure you fully understand the current and future software license cost, quite apart from the fact that almost all of the Baby-boomer COBOL programmers are ripe for retirement now.

Maintainable Code

noreply@blogger.com (Big Iron) — Sun, 03 Apr 2011 09:38:00 +0000

Maintainable code: everybody wants it, very few modernization customers get it. But rigorously defining what is maintainable code is somewhat difficult. However, there are some good guidelines to go by:

1. Maintainable code for web business systems does NOT have the same structure as your legacy mainframe programs. In Natural and COBOL and MAPPER, for example, it is possible to mix the business logic in with the presentation or view (the screens and reports). That's not how we write programs for the web, and forcing the Java or .NET developers to forget most of the best practices they learned in school and follow the unstructured ramblings of a 30-year-old programming hegira is NOT what we mean by maintainable. Maintainable code is properly structured down to the class level -- it's not just a matter of throwing a bunch of spaghetti into the "spaghetti layer" and calling the result maintainable.

2. Maintainable code has meaningful comments -- not just duplicating what was in the legacy system, because that is only useful if you also duplicated the structure of the legacy application. Otherwise, the comments would be in the wrong place, wouldn't they? The comments should tell the programmer about the Java or .NET programming choices that were made and why they were made.

3. Maintainable code uses modern frameworks like Struts 2 and Hibernate and the facilities of Visual Studio 2010. It may not use the absolute latest versions, but it should not use versions that are obsolete or are on the verge of becoming so. Vendors who have translators that were written 8 or 10 years ago often don't keep their output up to date, so what you get is code that looks like it was written 8 or 10 years ago. Can you say "Web Forms" and "legacy Java?" We knew you could.

4. Maintainable code today is object oriented. It has a good design that follows the Microsoft MVC recommendations and the Sun Blueprints. It is not enough to throw everything into one big procedural class and say the code is object oriented -- it's not.

5. Maintainable code includes all the code you need to build your system from scratch, with no vendor hold-backs. You should not have to go back to your vendor when the operating system changes, or when you have a performance problem in your application.

Those are the "Top 5" things you should look for in maintainable code. It's also good to run code quality checkers from companies like CAST and to ensure that you do not have routines with unacceptably high cyclomatic complexity. But at the end of the day, the knowledgeable customer will know maintainable code when he or she sees it. If you'd like to see how very maintainable your new code can be, talk to us!

We'll Just Refactor

noreply@blogger.com (Big Iron) — Wed, 23 Mar 2011 09:37:00 +0000

There's a word that crops up more and more in the modernization community: refactoring. When a customer realizes that doing a wholesale line-by-line translation of an entire application results in duplicating the old application structure in Java or .NET, they understand that what's a good structure for the mainframe is NOT a good structure for modern web applications. When they ask about this, some vendors say, "Oh, don't worry about it, we'll just refactor."

You should worry, in fact.

Here's the problem: Refactoring doesn't really give you a good structure most of the time. It's like taking a pile of Jello and trying to make it look like a horse and rider without having a mold. The bigger the pile, the harder it is to do.

The other problem is that anything other than superficial refactoring takes a lot of hand effort. Refactoring to make the whole application look as if it were hand-written by properly trained .NET or Java developers is almost as much work as rewriting it from scratch in the first place. So, what will happen to you is that you'll be shown the "refactored code" in a demo or a small proof of concept, but when you contract for the entire project, you will discover that what you get is not at all the same as what you see in the demo -- unless, of course, the project is done under an hourly labor contract instead of fixed price. If your checkbook is wide open, you can get as much refactoring as you wish!

In contrast, we start with the proper structure -- like starting with the mold, not the Jello. We can produce all the structure for a 700-screen application in a matter of weeks, using the latest Model View Controller design patterns. And we can do that for multiple languages - COBOL, Natural, Oracle Forms, Powerbuilder, and so on.

Building this capability takes years of work. Anybody who tries to take their "workbench" style product, meant for a single developer, and expects to scale it to handle 700 screens at a time so that they can do good quality code in volume, is going to be in a lot of trouble. Why? Because there's a lot more to it than just creating ASP or JSP or JSF files. In order to be effective, you need the plumbing like Struts and Spring, you need data management, you need business services, you need data element validations, and it has to be proven in large projects. Otherwise, you will discover that you're either in for a lot of hand work, or you have software that won't scale.

Don't buy the "refactoring" sales talk -- ask them to do it fixed price and verify code quality by running the results through a code quality measuring tool. Faced with having to fix all the problems in hundreds or thousands of programs, and not being able to stick the customer with the bill, most vendors will back away.

We won't refuse that challenge, we've been doing projects with millions of lines of code for years. All maintainable, commented, and ready for you to take over and run with it.

It's Not Y2K... Or Is It?

noreply@blogger.com (Big Iron) — Sat, 29 Jan 2011 02:35:00 +0000

A friend sent me an article the other day. The intro says, "States' shrinking IT workforce: The worst is yet to come: A survey by the National Association of State Chief Information Officers finds that states are facing critical shortages of IT workers, made worse by furloughs, hiring freezes and stagnant salaries. And the retirements of many older workers loom." Of course, the big impact of this situation is on the ability of the States to support their legacy applications. The people who are retiring are not the 24-year-old Java or .NET developers, they are the 58-year-old COBOL programmers. You can read the article here: http://gcn.com/articles/2011/01/27/states-it-worker-shortage.aspx

Unlike the "Year 2000" or Y2K crisis, the date for hitting the wall is not always clear. Right now, the 50-and-up age group is the only one where employment is actually increasing. Why? Well, too many people are discovering that with disappearing home equity and the decrease in other investments, they can't afford to retire any more. But, if the economy ever does truly pick up, or if they just get tired, you can bet those older workers will leave in a heartbeat.

For the States, this situation is very serious, but not urgent. Nobody is running around like Chicken Little... yet. But, the only way out of this situation that keeps the systems running and the services delivered safely and reliably is to modernize those older applications. We can typically redo a system in a year, but others take longer (perhaps 2 years, perhaps 3). If you look at a 3-year window, and you don't start until your staff actually retires, the results will be painful and embarrassing.

It's time to get moving. The people who went through the Year 2000 crisis with comfort started in 1997 or earlier. Don't let the aging workforce catch you by surprise!

Not Just a Software Tool

noreply@blogger.com (Big Iron) — Mon, 24 Jan 2011 02:34:00 +0000

Some people look at our technology and focus immediately on the tools. While we think the tools are great, successfully building software has a lot more to do with your process or methodology than it does with your tools. You can do automated redevelopment (what we do) or wholesale line by line translation, or rewriting by hand: but if you don't have a process for getting the job done, the odds are that the outcome will be a failure.

Our software development methodology, QuickStep(tm) has a number of features specifically for modernization, but it also handles new development (just like our tools). We also have a software application called ResQTrack that supports the methodology and even helps to enforce certain aspects of it. QuickStep is repeatable, and is tailored to each project; it supports multiple teams working together, and they can be located anywhere in the world. Using ResQTrack, we not only enforce the process, but we monitor it and measure the results.

ResQTrack allows us to assign and monitor tasks, collect labor and cost data, maintain and allocate requirements to tasks and tests, maintain and share a secure project library, keep a record of technical communications, and publish process documentation and design information. We would have to install 5 or 6 external software packages to do the same thing, and they would not be integrated.

This way, we have good support for the software engineering process, and can give a customer up to the minute visibility into the project. Let us know if you'd like to give it a try.

Welcome

noreply@blogger.com (Big Iron) — Tue, 18 Jan 2011 10:44:00 +0000

Blogging... in some cases, blogs seem pretty self-indulgent. Narcissistic, even. Do you spend time reading blogs? I usually don't, unless the blog tells me something interesting. So that's going to be our guideline here.

My forum name, Big Iron, pays tribute to my background as a mainframe programmer. In the old days, we had titles of programmer, systems analyst, and project manager. We didn't call ourselves "developers", far less "software engineers". I wrote my first program in IBM Autocoder on a 1401. Using coding sheets and a pencil. Seriously. And it even worked!

Over the years, there was a lot of FORTRAN, COBOL, PL/I, SAS and SPSS and RPG. Then came the transition to client-server computing, mostly on Sun and Data General, and then the PC platforms. And now, I help people rebuild those old systems using new technology, for a new lease on life.

I may say things here that are controversial. Sometimes, I may take a position to promote discussion and argument. Hopefully, whatever you read here will be thought-provoking, and will contain something of value that you can use in your regular work.

Welcome to our blog!