Tuesday, July 24, 2018

The magic roundabout....

“Computer Associates (CA), where products go to die!”

If you were around in the late 90’s and early noughties, the statement above was industry standard and after a brief rename to the COOL range from Sterling Software prior to the CA acquisition in 2000 the tools known as Synon (now CA 2E) and Obsydian/Plex (now CA Plex) have been maintained and supported by CA.

Correction from above…. CA did in fact (the early years) innovate with the tools quite frequently and with good features and enhancements.  CA were responsible for the introduction of the Web Option, Triggers, RPGILE Generator, numerous SQL’s updates and Web Services for 2E as well as .NET Generator for CA Plex (no small feat), Web Services publication and consumption as well as keeping up with a myriad of technology platform refreshes Plex required. 

All in all, a reasonable job. 

Perhaps a 6 out of 10.

Okay, 5.

The point being that these products didn’t go to CA to die. However, in recent years with development budgets reduced and key personnel leaving the rate of change has stalled significantly.  So much so that nowadays a release highlight are items that would have been reserved for minor features or even bug fixes in years gone by.

Whilst the tools haven’t died they are clearly in maintenance mode.  CA moved this group of products to sustaining engineering.  This has a negative context whilst a product is in decline and I feel that other low-code options with better target platforms coverage have emerged into a space once dominated by case and code generation tooling.

Last week Broadcom announced a cash buyout of CA Technologies for over 18b dollars.
Broadcom doesn’t do software…they are a semiconductor business so what does CA provide them:-

  1. They may be diversifying their offerings and product range.  Perhaps there are some key products in the CA range that assist in their growth or CA has strong alliances with certain business verticals or a client base the parent organisation may wish to gain access to.
  2. Or this is purely a financial decision.  They may have too much cash to burn and need to spend it quickly.  They buy a solid company with a long and attractive maintenance trailing revenue stream and secure long term (almost guaranteed) recurring revenue.  Most likely this means they won’t need to pay any corporation tax for the next year or two as they assimilate this monster of a business.

Perhaps a mix of both but my money is on the second option and that this is merely a financially driven strategic purchase.  

There certainly isn’t any institutional importance for the CA development tools business i.e. CA 2E, CA Plex and CA Gen.  Although these areas are likely to show very high ROI i.e. cost vs revenue on the reporting charts I very much doubt they’ll get anymore focus than they there are currently getting.

Now it would appear, that the final resting place for these (once wonderful and genius) tools is going to be Broadcom.  The new statement being “Broadcom, a place where CA Technologies development tools go to die!”


Hopefully not, I hope that the residual value and with opportunities in a safe pair of hands i.e. a company with a low code focus. It is possible to recapture the essence of CASE and reinvigorate these tools.

Probability?: < 10% if Broadcom don’t want to relinquish these tools.

Lee’s take out!

Sadly, it’s probably time to work out what the next big thing is… These tools are now compliance/maintenance focused (at best) and will be stabilised (cease to be supported) as soon as the revenue trail drops below x, whatever x is.  

x for CA or Broadcom is far higher than x for a passionate low-code only vendor.  I beg Broadcom to review the business units at CA and seek a buyer (at a fair price) so this technology has a chance to thrive once more.  These tools practically invented low-code.  In my eyes they are 20 years ahead of the rest.

Thanks for reading.

p.s. I wonder what theynew name will be....Broadcom Plex doesn't have that good a ring to it.....

Sunday, June 10, 2018

You have 'Function Options' you know....


One of the first things that are discussed when you did (if you did) the Action Diagramming course for 2E is PODA.

PODA is an approach to effective function design.

  • P is for parameters and the interface.
  • O is for options (Function Options)
  • D is for device design (Screen/Print)
  • A is for action diagram.

The concept being that these all influence the function and getting them correct will mean you’ll write less code and won’t be wrestling with the template (prototypes/patterns).

Bare this in mind for the rest of the blog post.

I was at work the other day and was maintaining some code where once again I could be heard saying, “Whoever wrote this should be shot!".  It’s my preferred (go to) phrase when I see badly written/designed/architect-ed code.

Anyhow in this instance the code was quite simple and generic so I can share it here.

The reason for my comment above was why is this code inside a subroutine called Subroutine?  The actual function ‘Perform Substitution’ was itself and EIF (Execute Internal Function).

I thought to myself, it is okay someone probably wanted to be able to *QUIT from one of the case blocks below…..  NO!!!

Hmmmm.......Perhaps someone was being a dunce!

Anyhow, depending on you model default and EIF can be generated as either inline code or as a subroutine.  I am thinking that this code might be quite old or that someone simply doesn’t understand how the code is generated in 2E. (Probably the later).

Most of you know that you can share subroutines and reduce code bloat using the ‘Share subroutine’ option.  And EIF also has an additional option called ‘Generate as subroutine’.

In the instance above we could have achieved the same result with omitting the sequence block and simply setting the value.

Let’s explore the generated code for a much simpler example.  I have an EEF (Execute External Function) calling and EIF.  The EEF is setting the local context for LCL.*JOB DATE to JOB.*Job Date and then calls the EIF which in turn set the WRK.*Job Date to JOB.*Job Date.

With ‘Generate as subroutine’ set to No we get inline code. (See below).

Taking the original example (see top), if I put the internal code inside a Sequence block I’d get a subroutine. 

See code mock up below.

So although this code looks a little neater, it still isn’t perfect.

Setting the option Generate as subroutine’ to Yes generates slightly difference code.

Overall, in this instance it didn’t matter too much as there were NO *QUIT’s to worry about and the routines weren’t (or couldn’t) be shared etc.  But it does highlight that following PODA can make your programmer life easier, not to mention mine..... as I mop up after you....

Thanks for reading. 

Wednesday, May 16, 2018

2E Code Review - pet hates - part III

7. Bad field names.

I've banged on about this many times but fields called 'Current Balance' or 'Count' simply do not cut it.

Call it as it is and don't be afraid for adding more fields.  Especially, as we can now search much easier than before.....

8. Copies of functions (just in case).

RTV All (Copy).

WHY! WHY! WHY! would you do this.  Just take a version or install version control system.  It is even worse when these are external functions that eventually get generated and promoted (but never used).

This is a very amateur mistake and you'll be shocked at how prevalent this is.


Happy to take ideas but be quick as this blog is likely to be closing soon.....

Thanks for reading.