Deciding Correct Problem Solution

When designing a system, it is a usual situation that there are multiple solutions for same problem. Each solution may reside in different software layers. This is a very interesting pattern that can be experienced every time when facing a problem and designing its solution. Designing is really a special effort in engineering which is beyond the problem solving techniques. Designing a good solution begins with deciding the good solution choice for the problem.

At the first stages of our ERP development, I had always a mantra that I insist on whenever we meet multiple solutions for a problem which is “Single Touch Point”. As long as it is logical, keep everything in one place for “Single Touch Point” principle. It would keep programmer focus and accelerate productivity. For this slogan to become true, we should pull the programmatic artifacts to Java source code as much as possible.

Let me summarize some design decisions for that principle:

If possible, don’t use XML: If we can do our job with Java source code, why do we bother to make many software pieces that need to integrate on XML manipulation and conversion. One example for this is our rule engine definition files. Many rule engines generally used XML as a rule definition format but I feel that it should be in Java. Many rules are written by developers and why do we disturbing the programmer focus? One reason for that was dynamism that we can also achieve in Java language. There are many examples, no need to explain all of them.

Database View Construct Abandonment: Yes, we don’t use views instead we use View Java objects. View Java objects are placeholders of database views with validation and criteria support plus security. I read many articles about why views are good but I think drawing views into persistent layer has much more benefits to keep it in database layer.

Database Stored Procedure Abandonment: We also don’t use stored procedures. We have business events and programmers can write event handlers in Java instead of writing code in database non-portable proprietary language. Stored procedures are not a bad thing but we tried to keep code as much as in Java.

Server-side Validation: To make a single point of validation, we decided to use database objects the sole place for validation. For that reason we rarely used client validation. This is again a benefit for programmers for “Single Touch Point” that they don’t have to struggle with JavaScript.

There may be many solution alternatives and any software would follow a path among them. There is no single answer but selections determine the faith of the software product. For successful software, every selection would not be true but true selections should be much more than the rivals’ true selections.

Let me list some of occasions that requires delicate selections:

SQL versus Application Code: Yes we know when to write in Java and when to write in SQL but interestingly there are some cases that you can achieve same function both in Java and SQL. For example a join may be achieved with both Java and SQL, which one to use? This is an intersection point between solution contexts.

System versus Application: This is a classical case that every software team meets. You have a problem that can be solved both from your application and from system (server machine). For example your application has poor performance and you think that you made every possible performance tuning in your application. What do you do? Do you want the system administrator to buy more CPUs and memories or do you re-check your application for better performance? The decision would depend on parties involved and problem agility.

User or Application: Again, you have problem that can be solved by your application or by user’s action. Let’s say your application have a double-submit leak in an application page. What would you prefer whether to inform user that he mustn’t double-click or you solve the problem of your application? There are many examples even further the buggy situations. Second example is a user requirement for Excel-like functions in a data entry screen, would you develop that application or just want the user to use your ultra-fast input application?

Administrator or Application: Again you have a problem that needs some actions by administrator. Dou you want system administrator do the job or add it that feature in your applications? Let’s say your administrators complain about system management overhead of your applications. Would you develop a new application server embedded your application to ease system management (a desperate path) or explain them to get more training?

Spreadsheet (Excel) or Application: Let’s say that your users want a super formula system in your application? Would you add that function into your application or just lead them to use spreadsheet programs for that task?

JavaScript or Java: You have a problem that may be solved in both front-end and back-end. Which one would you prefer? For example, with AJAX technology you can load everything onto JavaScript. Let’s say you need a fast validation requirement, would you ignore the server-side validation for the sake of client-side validation while fearing the possible security vulnerabilities?
That list goes on, I’m sure there are much more to add to the list. Selections are much more important than it seems. Problems may be solved for today but we eventually face our decision results in the near future. For sound decisions to become a good “Solution Architect”, we need to learn, inspect, try and analyze and ponder over the problem more to reach best selections among multiple solutions. After a good solution selection, story continues with good solution design characteristics like extensibility, maintainability, adaptability, learnibility etc.

Even in programming, there are many alternatives to solve the same programmatic problem. Sound solutions always live longer and weak solutions may live till test phase and require a rewrite again. It is a fact that sound solution need more time and more experience.