Application design

Application Launching — Softly Please

There have been a number of posts made commenting about a recent post on 37 Signals blog about “Why it’s wise to launch softly“.  I always love to see my thoughts in print by others, or to see approaches that I believe in being touted as “good” methods.  Such is the post I refer to, I could have written it myself if I weren’t beaten to it.  (…and had thought of it).  Myself, I always want to launch a project softly — get feedback — know what will work, and what users don’t like, or what is perhaps “clunky”.

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.

Application Over Design — Is there such a thing?

Yes there is ladies and gentlemen!  End of story, NOT end of post!

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?

Application Design for Tight Operator Control

In these days of exceptionally “busy” screens within which operators can usually choose many options (…and sometimes ones which they shouldn’t), I have been placed in a position where I am being asked to create an application with minimal functionality entry screens!  This design approach reminds me of the very simplistic (…also efficient, lean and mean) entry screens of the character-based applications I was designing in the 70’s and 80’s.  No surprise here since the application being designed is truly a system based upon that early design approach and technology — and my customer describes himself as a “control freak”, and describes a co-worker as “even more of a control freak” than he is!

OK, so you’ve now got a general picture of a design criteria — Keep It Simple Stupid!  Continued »

Cost Estimating Ideas for the Legacy Application Rewrite

I promised in my last post “Cost Estimating Rewrite of Legacy Applications” that I would be producing a list of considerations for preparing estimates for legacy application rewrites - this is the post!  The suggestions on my list are really slanted toward the independent developers who are apt to find themselves in many an unfamiliar territory.

• 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.

Legacy Application to Windows - Challenge of design

I’ve discovered the greatest challenge of my application programming and design career,  (Hopefully I haven’t met my match!).  My latest project involves a rather large legacy character-based system which has evolved over the past 20 years or so.  The source code directory lists some 800+ pieces of source code, with close to 500 being actively used, and others that were basically copies of some “active” source with minor modifications - mostly in the screen layouts for entry programs, and header footer changes on reports.  In all, a lot of code to evaluate. Continued »

Can applications be too Automated?

As a custom application developer working mostly with small businesses, users often look at “Why can’t the program do this?”, or “How about having the program add this, subtract this - when it’s this, then add a percentage…” yada, yada, yada.  Perhaps you recognize the pattern.  There can be arguments for doing much in the way of accommodating the requests, but in my opinion there can become a time when an application is too automated. Continued »

Applications - Why User Documentation?

I’ve stated before that my goal with applications I create is to provide an application so intuitive that if one knows the job for which the application was designed that the interface be so intuitive that no training would be required.  This is a lofty goal for sure — and not one easily achieved.  It might be better to set the goal to be more like 95% of the time “…the interface be so intuitive that no training would be required…”, or 98% or something like that.  My first answer to “Why User Documentation?” would have to be that it is what covers the shortfall percentage of design that just doesn’t measure up to the lofty goal.

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.

Data Rot

Here in the Northeastern U.S. it is snowing outside and I found myself starting my day browsing through the myriad of industry emails I watch regularly.  Now, I’ve blogged previously regarding my thoughts on the “paperless office” (See “The “Paperless” Office –  Myth or Real Possibility?).  But this morning I found the article “Paperless office? Ha! How about a paperless life?” — and of course I just had to check that out!

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!

Simplicity is Power

Seems like I’ve expounded on this topic ever since my first encounter with software and software development.  Keep it Simple (Stupid) - aka the KISS approach is, I believe, always appropriate when looking at development of a business application.  It has always been my goal that users of applications which I’ve developed not need any “training” in the use of the application, but rather (assuming they know the job which they are expected to do) they just get into the application and start using it. 

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!).

Changes, Users and Resistance

Let’s face it, software development and design is complex - even when it’s simple

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.