Fog Creek Software
Discussion Board




Flawed Application Architecture?

My client has a large data entry application (written in VB) that has had a lot of problems with bugs.  I believe that the root cause of the large number of bugs is the application design.

The application is not designed to be very domain specific.  Rather they have defined a number of Data Entry processes.  Each of these processes has one or more screens.  Each screen has one or more fields.  When defining the data entry processes, every screen is 'bound' to a data object while a field is bound to one of the screen's object property.  All the loading and saving of data is done using late binding (CallbyName to be precise).  The application is one large collection of custom fields.

The system is complicated further by the business requirements of the domain that they are working on.  For instance, if a user records a certain value on a specific field in a data entry process, the system can activate a peripheral device etc.

When I enquired why this approach was used, they told me that they wanted to have a configurable product (the use can record anything he wants).  They did not want to do conditional compilation for users who need a product that a little different from their standard product. 

The application domain requires that a sizeable set of data be loaded in memory whenever the application is running.  The application also loads it’s own configuration data leading to a large strain on the system memory.  The application is also slow.  Finally, when an error occurs in one area (e.g. configuration), it causes a large multitude of errors in other areas of the application. 

What is your opinion on this matter?  Where can I get more information on this issue so that I can give my client the correct advice?

Ling
Tuesday, March 18, 2003

I once had to work with a system similar to the one you describe. It was a CRM/ bug/ issue tracking system called Helpdesk that was intended to be incredibly configurable without 're-programming', much of the data content and the UI being defined by meta-data. Trouble was dog slow to load and was always falling over!

It sounds to me like there is a fundamental flaw in the design somewhere and that, even although they have tried to make the major components of the system orthogonal, they remain coupled in some way. Somewhere (on Joel's site?) there is a lovely description of coupling in terms of the control linkages of a helicopter - climb or descend and you _must_ alter the throttle and, by the way, the aircraft will also turn!

This style of system inevitably trades meta-data for code. The code becomes more abstract and compact, but at the cost of loading and interpreting the meta-data.  In theory the reduction in LOC should create a less buggy and more maintainable system!

To be honest I'm not sure that I'd want to implement such a system in VB. Some of the problems faced are more easily addressed in languages (plug here for Python or Smalltalk) that are properly introspective and treat classes themselves as objects. This isn't the forum to discuss design in any detail, but if you'd like to send me an e-mail I could let you have some pointers.

David Roper
Tuesday, March 18, 2003

Bad Application design is a real open book word here. It is like the client who says the application is not user friendly. (what the heck does that mean?). Is it bad because it does not do what they need? Is it bad because it is not reliable? Is it bad because every time they change how something is done, the software don’t change with them?

You have to ask if the application is worth enough to be re-factored, and changed into something good, or should you throw it out? Can it be salvaged?

Also, you don’t mentioned if junking the whole thing is a possibility?. If throwing out the application is out of the question, then your choices are certainly limited here..are they not?

Can you throw this thing out? Would you want to?

Anyway, there are number of things I would first look at:

What kind of database are you using? (or is there even a central database, and are we talking about a multi-user system?). Is this 2 tired, or 3 tired  design? How much of the front end can be changed? How much of the application is in the front end as opposed to the back end ?

I mean, perhaps the tables and data structures are very well designed, (or very poorly designed). Was Referential Integrity (RI) used for the table designs at the server level? Or, does the ap have child table deletion code strewn all through out the application? If you have all kinds of table rules and cascade delete stuff in the code, then it really makes any kind of refactoring the system very hard.

A small table change in one place will cause other parts to break when poor table designs are used, or when tons of logic that belonged on the server is strewn through out the code.

Ask any developer what is better:

          Good table designs, and poor code
or
        Really nice code, and reliable code and poor table designs?

You are way better off with good table designs. Every developer says:

      “Show me the data” and I write you the application!!

ONLY when the developer understands the data structures, can one modify the code in any significant way.

When the data structures are right, the application practically writes it self. Thus, any developer will prefer good data structures over poor code. I mean, to really modify anyone else’s code, you need a understanding of the data structures involved . Without this understanding, you really can’t modify the application without knowing what you will break when you change something. Good data designs will thus allow you to easily add on, or modify the application.

So, while the code might not be the best, how are the table designs? And, also, did the developer(s) use a lot of stored procedures etc?  Hence, did they use good table designs, and at least some sensible approach to the data store? This is always the #1 thing I look at.

I mean, even when I code in ms-access, I use class objects for many of the complex business rules, just to force them into one place in the application.

So, do you have a nice table “ER” layout, and were things like RI used? If you don’t have one, you might want to sit down and create a nice database diagram here to see what you actually have. (or maybe you did this already!).

Did they make good use of stored procedures? Your analyses of the data designs is only the starting point, but that really is where EVERYTHING else follows from.

Are you in an actual position to tell the client to dump the application? Is this possible?

Further, what does the code look like? I mean, most of use find reading other peoples code hard. Throw in your lack of knowledge of the data structures, and you really do have your hands full.

I also find the comment about conditional compiling a bit strange? That does not at all sound like any possible solution/problem here?. I am dealing with the problem of “different” code versions of some of my software for different clients. The best solution  is to simply make the application work for all of the clients. Conditional compiling, or even having multiple copies of the development environment (which I DO HAVE right now, and HATE to no end.) is not good.

I just spent the whole weekend re-coding some stuff and actually merged two of my clients software into ONE VERSION. You can’t imagine how good this feels. Now, every time I update the application for one client, I  don’t have to update another copy of the application for another. (I just halved my support time cost here).

Anyway, my ideas here are just some of the things I look at when evaluating software, and if the software system should be sent to the kitchen for further cooking, or to the dumpster where rotten food belongs.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Tuesday, March 18, 2003

I think it was Fred Brooks (of Mythical Man-Month fame) who originally said, "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; it'll be obvious

http://www.redhat.com/support/wpapers/community/cathedral/whitepaper_cathedral-5.html

runtime
Tuesday, March 18, 2003

Ling, what is your long term goal? Are you trying to fix the application - in that case I would recomend refactoring the existing code one module at a time. I would suggest starting with the module that has the most bugs. It's hard to give specific advice without knowing the details of the system.  You may want to (re)read  these articles from Joel:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://www.joelonsoftware.com/articles/fog0000000348.html

igor
Tuesday, March 18, 2003

I have been toying with the idea of re-writting the application, this is too risky.  I'm considering re-factoring the application.

However, even refactoring cannot be as easy as it would seem from the first glance.  The application does not store it's data in fields that you can directly access from the business layer.  You have to go throught an interpreter that  processes metadata.  The metadata provides the translation betweent the database fields, the business objects and the UI elements.

The use of metadata also complicates reporting.  You cannot drop fields from the database into a crystal report without writting complex queries and/or DLLs for interpretting metadata. 

Ling
Wednesday, March 19, 2003

I suggest you just go ahead and start re-factoring.  I'd bet it won't be as bad as you fear it will be.

What do you have to lose by refactoring?

Brent P. Newhall
Wednesday, March 19, 2003

*  Recent Topics

*  Fog Creek Home