The Great 3GL v 4GL debate - Part III

This is part III of a trilogy of articles regarding the usage and evolution of software development languages. Part I can be found here and part II here.

All of these technologies have issues to address. 20 years ago we were all happy with green screens for business applications with centralised platforms, then came client server with Windows and the distributed computing model became mainstream. Then along came the Internet and the return to HTML thin clients and now the evolution once more learns towards Rich/Smart clients.

The irony for me as that I have witnessed many people move on from the 4GL world of the nineties to emerging 3GL (albeit object based) technologies i.e. J2EE (Java) and .NET compatible languages etc.

With the extra layers of complication (some call it abstraction) added due to business usage of the internet I am seeing more and more tools coming onto the market that claim ‘code generation’ capabilities. You only have to look at the OMG’s ever growing list to see that once again people are looking for the holy grail of application creation as projects overrun and costs escalate.

I do see a trend towards total code generation once more. IBM has launched a 4GL called EGL. This looked quite promising and might me worth a look but to me it is not yet as mature as others.

The difference between tools like Plex/2e and this new breed of tools is that the ‘so called’ newer tools generally only cater for the singular environment and often really only create the initial code that requires manual intervention and coding in the generated language. In my mind, these tools have yet to evolve as far down the road as Plex/2e.

Plex and 2e both have their unique selling points.

2E is pretty easy to use and probably has a 3-6 months learning curve for a developer to become very proficient. Quicker with excellent training and in-house support. Software development room 101. Item 3. Always spend decent money getting a guru to help you set up your environment and train the developers. Too often mistakes are made is the early stages of application development. This is especially true when using new tools.

Plex will take longer (12 to 18 months) as it supports inheritance, shipped and customer business patterns, meta coding and many more target development platforms. It really is the Daddy of ARAD (Architected Rapid Application Development), hence the learning curve but the payback after this is judged in weeks, months or even years off a development projects timeline. And with the great pricing of the tool and generators nowadays, it really is an option to help protect you against the constant upskilling costs associated with other technologies.

When you also consider that the tool has localisation, application version partitioning built into the tool. From the single skill set perspective your developers will always remain current. That said, you would always create the optimum patterns and platform level code if some of your developers have the lower level skills.

I have been programming computer systems in Plex and 2e for 16 years and these systems have used the best aspects of these tools and have always been database focused applications.

These have been in Finance and Banking, Debt Management, Mortgage Application and Processing, MIS, Project Management, Time Recording and Environment Management. These were deployed on System I (now IBM Power System with ‘i’ as the operating system (RPG and RPG ILE code), Java, C++ server code all with either C++ or Java (Swing) clients.

With the plans for these tools heading towards .NET C# clients and the C# server code in 6.0 already available. The recent announcement of the WebClient partnership between ADC Austin and Websydian means that the future looks really bright.

Time will tell what will happen and often these battles are not won or lost by the technologies, often they are decided by the marketing budgets.

However, I know what playground I want to play in. And if you need a guru to help you. You should contact me.

Thanks for reading.
Lee.

Where's the dishcloth?

Bugs!!!! Love them or loathe them, realistic developers understand that bugs are part of our everyday life. We have technical bugs, environment bugs, business logic bugs, integration bugs, somebody elses bugs and god forbid, stomach bugs.

Now apart from the stomach bugs. Who is responsible for clearing up this mess?

There are numerous approaches depending on the product(s) you have developed, your organisational structure and your focus on bugs in general. I prefer the ‘zero tolerance’ approach to bugs, however, others are quiet happy to have a level of bugs in their code and apply risk and cost ROI calcualtions to determine whether the bug is recitfied, and if so, when. I feel there is a whole post on that subject alone and I’ll save that for a slow news day.

Moving back to the tactics around who should be responsible for clearing up this shoddy code. If you work as part of a small team of developers or lone wolf it is likely you have little choice other than to get the developer who wrote the code to fix it up (look in the mirror). You are unlikely to have development support teams who act as dedicated bug fixers or access to a stream of developers on the graduate recruitment programme that fix up the bugs as part of their development induction process. The later two are certainly perfectly valid approaches although a little old fashioned in my view, after all, who trains up new recruits in the process of only showing you how not to write good code.

Personally, I believe that the developer who created the code should be the developer who fixes the bug. Obviously this won’t happen if they have left or are away on annual leave or a significant amount of time has passed, but in general it would be good practice to follow this process through. There are many fine reasons for either approach and no doubt I will conclude with some views around this a wee bit later.

For now, I prefer to use the anology of those everlasting worksurface ‘tea rings’ when referring to bug clearing methodologies.

“Tea Rings!!!”.

Yes you heard me correctly. Consider the communial kitchen in your office. You probably visit this vicinity between 4 and 10 times per day to make that cup of espresso stimulus or the relaxing afternoon chai tea.

The process is quite simple. You will carefully choose the serving vessel and may even warm it through first. You will likely compliment your brew with milk or cream and sweeten to taste, unless of course you actually listen to the advice of your dental hygienist and drink water only. Whilst queueing patiently for the kettle to boil like the quintessential englishman you will definitely have pondered your preferred order for mixing these ingredients. Water or milk first probably being the most important choice and certainly the one that has polarised the tea drinking world for generations.

More often than not this process is repeated throughout the day and with the exception of having to raid the dishwasher for a preloved teaspoon it generally goes without a hitch time after time after time. Software development generally pans out this way too. Once a developer becomes productive and uses your best practices they will be able to make a good brew (code) with no mishaps (bugs).

After all the effort analysing, prototyping, designing, creating and ensuring adherrence to your quality control processes you are finally ready to move your code (brew) to production or systems testing. From time to time though there is that unsightly spilage around the base of the cup as you pick it up. These are those tea rings that are etched on every spare post-it note pad on your desk or the coat the surface of that old CDR you are using as your cup coaster, the same coaster that once contained the backups of your companies servers.

So who is the best person to clear up this mess. As the creator it should be a small matter of picking up the nearest dishcloth and wiping the worksurface clean. But wait. When you look at the mess you notice that there are other tea rings there, some sugar mounds and a spattering of breadcrumbs from that cheese toasty you could smell from the other side of the office earlier. At this stage do you clean this lot up as well.

You may elect to wipe clean your own mess only, expell a little more elbow grease and time and clean all of it or choose to ignore the tea ring as in the whole scheme of things, it is hardly noticable in amongst the remainder of the mess. For me there is only one satisfactory approach and that is to deal with the issue as soon as it arrives.

It only takes seconds to analyse the problem and take effective corrective action. If you choose to mop up all the mess then you must be aware of the dependencies of fixing up all the issues. What appears quite simple may take longer and if the mess is particularly ingrained you could actually damage the efforts of others.

Doing nothing though really isn’t an option either as this creates an environment that bugs are satisfactory. Housekeeping is just as important in the office kitchen as it is with keeping your code and products bug free. If you do favour seperate teams or graduate programmes for doing the teams dirty work, imagine for one moment how they feel knowing that they are merely cleaning up other peoples mess.

Lastly, how are your developers ever going to get better and improve your product if there are no consequences for producing shoddy code in the first instance.

Thanks for reading.
Lee.

The Great 3GL v 4GL debate - Part II

This is part II of a trilogy of articles regarding the usage and evolution of software development languages. Part I can be found here.

So what are the benefits or otherwise of using a 3GL over a 4GL and visa versa. For me it certainly depends on all the usual factors that drive any technology decision. Cost of product, support, flexibility, the human factor, tool lifecycle, vendor direction and target platforms being a few that come to mind instantaneously.

The Pro’s of a 3GL

Embedded or mission critical applications like Air Traffic Control systems are generally handcrafted and more suited to a 3GL environment, as are operating systems, 4GL tools themselves (debatable), communications, hardware drivers and generally non database applications. As the developers have access to all the API’s and are that step closer to the CPU, they generally have wider usage opportunities.

Accessibility to wider developer pool. Whilst there are probably thousands of developers for your chosen 4GL, possibly even tens of thousands. These tools simply do not have the numbers associated to mainstream development languages and IDE’s. There is an estimated 4 to 5 million developers following the evolution of Java and no doubt Microsoft can boast even more for its most popular products. That said, of course, this also means that it is also harder to find a guru within that skills ocean, not to mention, filtering out those who have spent 15 minutes in the IDE and now claim some form of exposure on their curriculum vitae.

3GL’s are quicker to react to emerging markets and development trends. Generally the suppliers of these 3GL tools are inventing the future. They don’t often agree with each other but they certainly have the advantage over the 4GL creator. These guys have to wait and see what technology actually matures beyond the marketing hype and into mainstream best practice before committing to provide code generation for that area.

Flexibility. Languages at 3GL level, depending on the targeted platform, have virtually no restrictions with the type of application that can be written and how they are written. This means that applications where speed of performance is the critical measurement of success then it is most likely that a 4GL will fall short of the handwritten targeted code.

The Pro’s of a 4GL

Business rules focused development. Once you have learnt the code generators quirks you are in a situation where you mainly tackle your development from the business domain and you allow the code generator to handle the technical implementation. With this comes a significant reduction in the amount of time required to build an application. Many will say that there are standards and frameworks that help with 3GL development. This is actually quite true, but, also be aware that the code generator vendor will be skilled with the major best practices and will write more consistent code. Some may argue that the code is not as neat as code written by a good developer and in the regard, I quite agree. I will say that the underlying code will be written in the same way and style, therefore, after a while all the developers will become conversant in how the code is generated, that is, if they want or need to understand. (See Below)

Complexity avoidance. A 4GL will protect the majority of the developers using the tools from the underlying complexities of the generated language. When you couple this with the ability to influence how the code is generated using patterns, have the ability to take the design model from the 4GL and transform that into other language code, your business logic can truly be ported from platform to platform as trends become reality and your technical needs change.

Impact Analysis. For me this is one of the key features of using a 4GL tool. Generally these tools use a database to store design and program artefacts that are then transformed in the language code. Every reference for every field, File/Table, Access Path/Index/View, Function/Object/Program is stored in the repository and a developer can track each and every item through to where and how they are used. This is a powerful feature that cannot be overlooked versus manual reviewing of language source files.

Trusting the generator. When I train people to use CA 2E or CA Plex the defining moment for gauging the developers progress and understanding is the day that they learn to trust the generator. As with any tool, a badly constructed function in 2E, for example, can create badly generated and non compilable code. Once the developer realises that it is generally their fault if a generation of code fails they’re ready to move forward. If have seen far to many 3GL programmers migrate to the 4GL paradigm only to get bogged down into the details of the code produced, yet they will trust the compiler without hesitation. With the ability to change a shared function or the domain of a field and then apply detailed automated impact analysis to identify all affected programs, press a button to regenerate and compile all programs and database files affected is a very powerful feature.

The Con’s of a 3GL

Slower, more expensive development. The very nature and size of modern 3GL languages and their flexibility is also their Achilles Heel as there are so many ways to resolve a programming issue with literally thousands of opinions and many directions. In a nutshell for certain types of applications, particularly those that involve the extensive usage of a database, the ROI for using a 3GL versus a 4GL is very poor indeed. To contra some of the cost debate, 4GL tools are generally more expensive to purchase. The most expensive item in any development team is the human, even if it has been outsourced to an emerging development powerhouse.

You will spend more time debugging the application. A very good ex-colleague of mine once said “If the art of debugging is the removal of bugs from programs, then programming must be the art of putting them there in the first place.” Because we are relying on the developer to code all aspects of the application it is likely to cause some issues along the way. It is generally the developer’s prerogative to deal with memory leaks and usage in languages like Java or C++ but with a 4GL it would be the code generators responsibility.

Complexity. Once again due to the size of the languages and their strong reach it is unlikely that you will find developers that know all the aspects required to complete an application. Your staffing needs are generally much higher and the learning curve for the 3GL would be very significant indeed. This means that the developers must understand many technical as well as business problems.

The Con’s of a 4GL

Vendor lock in. Depending on the vendor this can be quite a significant issue. If the vendors are too slow to react to emerging technologies you will find yourself with a heterogeneous development environment and you will lose many of the advantages referred to above with regard to complexity protection and highly detailed impact analysis. Worse still, your vendor may well decide to stop production of the 4GL or chose other directions as the options with technology deployment balloon. These tools are often criticised as proprietary.

Flexibility. There will be limitations with the scope of applications that can be created by a single 4GL. There are of course others that target different platforms and purposes. Their flexibility is often measured in the lowest common denominator for which they have to support/generate code for. For example a generator that generates code for three different platforms may have to limit what can be done in one language due to limitations in another. For example different languages may have differing maximum field lengths meaning that for generic code construction in the 4GL platform x and y can only size fields to the limits of platform z.

Source Code. Many 3GL developers will argue that the code is not user friendly, bloated and often too generic in comparison to hand-written code. This can be true of some code generators and is certainly something that needs to be considered when choosing an approach for your development.

All of the above are by no sense of the imagine a definite list. Given time, I believe that I could have produced a list of 20+ Pro’s and Con’s for each approach.

Part III will discuss trends, fads and conclude the 3GL and 4GL debate with my own personal viewpoint.

Thanks for reading.
Lee.