Sunday, March 15, 2009

Why bad design sucks! - Part II

Hmmmm,

As I suspected a couple of weeks ago once you open your eyes to a subject and commence blogging about it you have it constantly in the back of your mind. My post on bad systems design and planning has had this affect on me.

I am minding my own business at my local quiz night when a question was read out by the quiz master or perhaps mistress as she is a lady. "What day of the week was Valentines Day in the year 2000?" Now as I am not the romantic type so I certainly couldn't recall this answer based on an event, although a friend 'H' was adamant he knew the day.

I decided the simple solution was the mobile phone calender so I plucked out the phone. It is a reasonably new Motorola Razor phone. So you know the routine, Menu, Organiser & Tools, Calendar. Voila.... The calendar is showing February 2009 (the current month when this event occurred).

"Excellent", I said (I remember the excitement), I can now work it out by counting back. Then I thought what about the leap years? So at this stage I decided to press the previous month button again and again and again working my way back in time faster than Marty McFly in his time machine and I didn't need a flux capacitor.

You get the idea, November 2008 came and went. July 2006 soon appeared but a few more key presses and my phone stopped working. It got as far as January 2005 and it stopped. No message, no nothing.

Bang. Another blog appears out of the blue. And a lot of questions.

Why did it stop at January 2005? How am I going to answer the question? Anyhow another of the team had an older phone that could go back further and we got the answer right in the end. fyi it was a Monday.

This got me thinking a little. What is the upper limit for this phone. After hundreds and hundreds of key presses (1007 to be precise) I got my answer NOVEMBER 2088. December 2099 I can understand as it would have covered a century but NOVEMBER 2088, what a strange limitation.

That works out at 83 years and 11 months or 30,650 days and I can't for the life of me think of a reason why my phone wouldn't be calculating this on the fly. It is not showing holidays. Leap years can be identified by a simple formulae. I certainly can't see a contraint in computing terms that would cause this to occur.

If someone can tell me why the programmer decided to restrict the dates in this way I'd be keen to hear your comments. It might be because they assumed that the phone was made after 2005 and therefore didn't need to go back for storing calendar entries. Fair assumption. But why put it in? Another unneccessary computer programmer/designer limitation I think.

Other friends on the night had different limitations on their phones and a colleague at work with a cool new blackberry had no issues at all with date range restrictions far in excess in both directions that he was prepared to sit around trying to find.

I don't think you have heard the last of the 'Why bad design sucks!' series....... It does worry me that people still impose design limitations.

Thanks for reading.
Lee.

Sunday, March 8, 2009

2e Development Standards - Screen Functions (Part II)

Part 2 in the series around screen function types will concentrate on the Select Record (SELRCD) function type.

This is often overlooked as a valuable function as it always appears to be generated on your behalf by 2e when you create a file. However, it has a few useful quirks that require a little thinking and I have often seen everly complicated logic added to them due to a lack of understanding where a simple workaround works quite nicely.

Below I summarise some of the key points when using the SELRCD:-
In general there should only be one SELRCD record per file, the default. I propose you rename your default select per for to '*SLT filename'. (See posts on naming standards). However, there may be occasions when it is necessary to select by a variety of different styles, or by a different key value. For example, where the primary key is a surrogate#.

These reasons may justify having more than one selection program, probably built over different ACPs. All other selects other than the default must be name SLT name and not *SLT name. This ensures correct ordering in the file. If using a different access path I would name them 'SLT By access path'.

The *SLT function is named this way as it will be used by the generator when building implicit field prompting code. The routine is also used to validate a record existence in relation checking. (The check restirction within functionaity). As such a default select must be first on the file and also never have its parameter interface changed unless the keys to the file changes.

CA:2E always regards the first SELRCD it finds on the model file as the default. If an alternative SELRCD should always be called for certain relation checks then that should be assigned via the Access Path relation settings. This situation might arise when a file refers to itself. E.g. Horse Refers to Horse for Mare and Horse Refers to Horse for Sire. At the relation level for the access path it is possible to set a default select record for each relation. Therefore the ordering considerations for the generator to substitute a select record are Function Level – Access Path Level – File Level (First on alphabetically on file).

The standard SELRCD should only perform a selection facility. That is, X=Select. However, a display option may be necessary in some cases as is F9 to Add a record.

Selection logic is usually performed one entity level at a time. Therefore if the SELRCD is for a lower level entity, e.g. 'Owned by', then the high order part of the key(s) will normally be RST.

The standard SELRCD should not pass back values other than the selected key. Validation and passing back of attributes is best left to standard RTVOBJ functions since the user may bypass a selection prompt and enter key values directly.

The SELRCD should not be modified to do anything unusual. If a user exits with *Exit key the default SELRCD will always exit program with return code Y2U0016='no value selected' and also send the same completion message. This processing should not be altered.

The parameter key values passed back should have NOERROR set. This is because CA:2E does not treat a 'no value selected' exit (Y2U0016) as an error when called implicitly. But it would be an error if called explicitly in an action diagram.

Closedown option should be set in the context that the program would be called.

If a SELRCD is not sufficient because of action diagramming restrictions then a DSPFIL may be used instead. But it should have a naming convention of 'SLT By or filename'. It should follow the same logic that a SELRCD would do, i.e. Same parameter definition and same action diagram style. This is often used if additional processing like F9 = Add is required.

The advantages of the DSPFIL method is it allows increased flexibility. But if you do choose this approach then this function will never implicitly be used and developers need to handle the output parameters. That said you could template this kind of function.
Tip

Using a Neither MAP input parameter does allow you to set CTL values for additional filtering.

Thanks for reading.
Lee.

Sunday, March 1, 2009

Why bad design sucks! - Part I

There are many areas of computing that have been let down by poor design.

Actually that may be a little harsh.

However, poor assumptions have definitely led to numerous designs that in hindsight could be considered questionable at best. These decisions have in turn led to systems that have suffered due to higher than anticipated volumes or longer than expected life spans.

A few examples that come to mind are:-

The millennium bug. Everyone knows this story. Developers designed systems in the 60s, 70s and 80s with 6 character dates ie DDMMYY or MMDDYY. The assumption being that storage is expensive and this system won't be around in 20 or 30 years. Well we all know how much effort was involved ensuring that airplanes never fell out of the sky in the late 90's, not to mention the contract rates for COBOL programmers that went with it. So I guess the lesson learned here is short sightedness.

http://www.trademe.co.nz/. Another example I heard about was for a very popular auction trading site here in New Zealand. The founders at a Microsoft TechEd conference a few years ago talked candidly about the early days of the business. They were describing growth of the business and unexpected challenges for the fledgling company.

The site was adding customers at a nice steady state when one day the system stopped working. No more new customers could be added.

They were a little concerned at first. After all they had just added their 32767th customer.

The issue was that in the early versions of their database they hadn't considered the domain of this particular field to carefully. i.e. the size. They had reached the limit for the integer field type on their platform. Now that the site is the most successful site in New Zealand and has made the creator a multi-millionaire, I am sure they have used at a minimum a long integer. The lesson learned here would be factor your wildest assumptions into your database designs.

www.Virtualrugby.co.nz. A sports predictions site here in NZ that has just rebranded again with another sponsor but suffered the ignominy of poor application performance and a whole host of players unable to access the site. On one occasion I was advised that the server was unable to make a connection because the limit of 111 connections had been reached. This is for a site that had over 100,000 active participants the previous year. I will go as far as suggesting the infrastructure suppliers arrangement may have changed as a result of the sponsorship change. Hopefully they'll get it sorted.

The lesson learned here. Never underestimate your audience and your processing peaks. Most of all ensure that your test systems have a reasonable subset of data to stress a mass participant application. Three guys in a room pressing the submit button as often as possible is not load/stress testing.

IPv6. Another in a long line of bad designs, or is it? It is alleged that we are to run out of IP addresses in the next few years. Some claim that this is the millennium bug of the 2000's. If it is and given the age of computing in general, we might have a few more yet. Sounds not too different to the 100 year storm scenario that happens every 4 years in these days of global warming.

I guess this one could have also been avoided but the caveat once again was when IP addressing got going the internet was quite young and connected devices were at a far lower number than they are today. Lesson earned! What do you think?

......

With all these though, IMHO it was human expectations that were at fault or shortcuts being taken to save a few bytes here or there. My advice to all application developers is to ensure that all your applications have database fields that are capable of supporting data sets beyond your wildest dreams. And to ensure that your application architecture is fit for purpose.

Bad design really does suck. Ask your end user(s).

Thanks for reading.
Lee.

p.s. I titled this Part I as I guess that now I have finally got this off my chest there will be other scenarios out there that will jump out shouting - BLOGGERTUNITY. Actually, one has just emerged but I will save that for another day.