Launching softly provides ability to “tweak and revise” easily — something that the “big bang” launch doesn’t provide.  I’ve experienced my “Big Bang” launch thank you, never want that again!  August 1, 1999 is permanently etched in my memory as the implementation from Hell, as it is with others I shared the experience with.

While doing some “cleaning up” around the office recently I ran into a design spec that I had the misfortune to encounter some 20 years ago.  It was submitted as a “Preliminary Draft”, weighed in at about the birth of a child (…only kidding, but over 100 double sided pages of small print), and was supposed to describe (as an overview) the specifications desired for a new manufacturing and inventory control system.  The project was scrapped after a number of months as not “fitting the budget”, which come to find out really couldn’t possibly have supported much more than that design specification itself.  I kept the document around to serve as a reminder to me of how NOT to design an application.

If a picture is worth a thousand words, then I figure that had the specs been graphically portrayed in that specification document, rather than verbal, its birthweight might have been reduced to that of a rodent.  As a side benefit, it may also have been read (…resulting in understanding)!  What a concept!  Then there might have been more of a budget for actually getting the project off the ground!

However, at that time the powerful time-saving and graphical development environments we have available today were more a dream than reality.  While I knew of COBOL programmers who seemed to think in terms of 80 or 132 columns and 24 to 80 row grids, and thus could very quickly place items properly on screens and reports, they were a special bunch!  Todays tools very much support the ability to a certain extent, to “design-as-you-go”.  It’s a wonderful time for development!  Anyone ever wonder what we’ll be using 20 years from now?

OK, so you’ve now got a general picture of a design criteria — Keep It Simple Stupid!  Purchase order entry for this application has boiled down to finding the item in a lookup list, giving how many you want, and setting up a schedule for delivery.  There is no vendor choice as an item purchased is always tied to a specific vendor.  There are no field over-rides, no additional comments allowed, just how many and when!  Not even cost entry is allowed when creating a PO.

But oh those master files!  Only a select number of employees get to setup the data in the master files.  Throughout the application it is the design of the master files and the information contained within them that dictate the information which appears on any purchase order, manufacturing document, shipping or invoice document.  All the data integrity resides in proper setup by the few with authority to do it.   This is in place to maintain absolute tight control over operator errors.  (There is an assumption that a shipper/receiver can count).

That brings me to the transactional entry screen design.  The KISS approach seems like such a waste of screen realty — maybe 3-5 forms on an entry screen, some display only info based upon selections, and maybe a “Save” button — all on a 1024×760 monitor?  These highly simplistic entry screens lend themselves very nicely to an AJAX browser design approach — an approach not yet into design of this project for this customer.

• Is the industry using the application familiar to you or your development team?
• What is your / your teams experience with applications in the industry?
• Is ALL of the legacy app source code available?
• Can the legacy app “play nicely” with the new app — or must the new totally replace the existing  immediately?
• What is the ratio of data entry and processing to reporting?
• Are there existing interfaces to external functionality for which no source or documentation is available?
• What are the time constraints for the project?
• What is the total size of source to be recreated?  How many bytes?  How many lines?
• Relational database or non-relational?
• How many tables involved?
• How about relationships between tables?
• What might you NOT know about?
• Is the new application to start fresh (empty data files), or will some data transfer/cleanup/modification be required?

Each of the above considerations (listed in no particular order by the way) are especially appropriate to the re-creation of an existing legacy application.  I’m sure there are other considerations not listed, and I would welcome your comment and suggestions.  Also, as with all software development whether a brand new app or rewrite of an existing app, all the considerations of application purpose, user experience, industry expectations and the myriad of other design considerations should be added to the considerations.

In a future post I will expand upon the above list with additional comment.

Of course, being a procedural language (thank goodness it isn’t cobol — I’m too rusty with that!), the source seems to have the expected number of “goto’s” and returns to “markers” in the code – all of which has reminded me of some of the cobol spaghetti code I’ve seen – and also early day Progress 4GL code.  Flow seems to twist and turn, help is non-existent, BUT — it has worked day in and day out for years!

Well then, why change?  Certainly going to a graphical interface with ability to have easy “lookups” for data, more capability to “cram” a screen with more information than can possibly be used (there’s my sarcasism again), scrolling windows, mouse clicks, right clicks, double clicks, mis-clicks — why not update?  Then of course there is the “tab” key instead of the “Enter” key.  Ever watched users as they move from character based entry screens to a windows entry screen? (It’s often not a pretty sight !).

All of these challenges with a little under 3 months to have a working program “live”, running a “real” business, “real” time!  The new program is to mimic the existing application entry screens as closely as possible so that users working with the legacy system will not be totally “lost” when trying to utilize the new application.  This probably is not the “best practice”, but I suspect that the users will come up to speed with the new application much faster and with less stress.

This tended to happen I believe in the early years of programming applications.  The programmer provided 100% of the step-by-step sequence presented to the user – users couldn’t skip anything – they were tightly controlled.  Today the user can go anywhere, and the program must accommodate such “jumping around”.  Anyway, I have been working with some early 80′s era program source code – a custom application developed strictly to do the task required – without consideration of the requirement for minor “variations” in the performance of a task.

The more closely I look at the code the more areas I find that were obviously added into the processing as these “variations” in requirements arose.  These variations might be triggered by different customer requirements – and they were “hard-coded” into the program – IF this cust, do this, ELSE do that.   Further, these exceptions then became nested – IF this custid, do that, ELSE IF this custid, do the other thing.  You get the picture (at least if you’ve ever worked with non object-oriented code). 

Coming back to the idea of applications being “too” automated – I believe that many times in the development of an application not enough consideration is given to the nature of “exceptions” to the business process the application must handle.  I would consider any application with specific processing coded into the app for a specific customer to be heading into the “too automated” category.  Yet, building a process which allows for multiple “variations” into the application – in a horizontal manner rather than vertical is certainly appropriate.

Secondly I believe that most applications will have those activities which are only seldom performed, or performed only as a “fix” to something gone wrong.  The infrequently performed operations which just don’t fit into the everyday flow of the business function, and therefore also not of the business application should be documented for users.  Of course, any documentation available will be only as good as its availability.

Ready availability of documentation for an application, or more explicitly documentation specific to a particular operation is crucial.  As long as I’ve been around applications this has always been an issue.  First off, creating good user documentation (read this as usable user documentation), is not an easy task.  It can also be a costly task.  Ineffective and it won’t get used, unavailable and it won’t get used, confusing and hard to find answers and it won’t get used!

More often than not what I’ve seen is an attitude of “Why document – nobody ever looks at it anyway”, or, “Document the obvious, don’t worry about the details – let them (users) ask!”.  Personally I think application users deserve more respect than that.

While mulling over the “…paperless life…” idea I recalled how yesterday while watching TV in the morning I was introduced to the term “Data Rot” in a CBS news story.  I’d never run into the term but I immediately could relate to the terminology, as well as the concept of data formats “going away”.  (I was enthralled with the “wire recorder” and “reel to reel” recorder when I was in my ‘tweens!). 

Anyway, “Data Rot”, the “paperless office” and “paperless life” all are interesting topics, and looking back at what I’ve seen for changes in my life, I can’t help but wonder what our lives will look like in 2080?  One thing I’m sure of, however, death and taxes – not necessarily in that order!

I’ve written before about how simplicity at the interface and user level does not necessarily mean simplicity behind the scenes at program core, but that in fact many times it adds to the complexity behind the scenes, putting more responsibility on the developer.  Certainly consideration must be given to the complexity behind the scene as well that it not become a tangled, unmanageable mess of what has been dubbed “spaghetti code”.

Todays emphasis on simplicity has really been brought to the forefront as the result of checking out a book recommended by Avery in a previous post reply.  The book,  Getting Real by 37 Signals triggered my mind into over-drive thinking about how strongly I believe in simplicity of design.  You might want to check out the link for yourself. 

Actually, it seems that I made reference to Getting Real in my post a year ago entitled “Getting Real” is UnReal!.  (I knew I had remembered something about less being more!).

There are some areas where it seems that no matter what is done there will be unhappy users – at least for a while.  I found myself in that category last week when it was announced by Data Access Corp that their beloved newsgroup forums were going to be moving away from the “old fashioned” newsgroup format to a new web-based format for their Dataflex and VDF (Visual Dataflex) groups.  Almost immediately the resistance began showing – and I was surprised to see myself as one of those initially disappointed to see the move.  I had a lot of company!

Once I realized my resistance I immediately recognized my behavior as like that I’ve experienced from users of my custom applications.  “If it ain’t broke…” – you know the rest!  I realized that I had become very comfortable with the status quo – after all, it had been in place for many years, was reliable, and known.  I have become proficient working with it, using it in the way I most needed to – it has been serving my purposes just fine.

However, as with the rest of life, change is inevitable.  While we welcome some changes, it is our nature to be disturbed by others – we get to make the choice of how we make the most of it.  The reasons for change may vary greatly, but through my rose colored glasses I find that most are made for good reasons (…though not always reasoning that I agree with ). 

I suspect that once the changes are made to the Dataflex newsgroups I will become comfortable with those changes, but until then I’ll be one of those grumbling.  Hopefully it will help me to tolerate better those resistant to the changes in applications which I make.