11.25 Signs of Trouble
Many of the previous points mentioned problems that may slow down the development of application systems. This section describes some specific signs that indicate a problem is occurring in one or more or the previous areas:
- Large teams, continually adding more people to the team.
A classic sign of an approaching deadline. The root cause of the problem is most likely to be many or all of the points previously mentioned acting together.
- Too many files in database.
Over normalized database. Lack of experience with database design has caused a completely normalized database (straight from logical model). Concessions to performance may be required, unless a commitment to sufficient hardware is made in early stages of design.
- Too many fields in files.
Under-normalized database. Too many concessions to application performance. No knowledge of relational techniques. Emulation of existing systems is also a problem here. A balance between hardware costs and maintainability of applications is required.
- Too many files open in application.
Result of over-normalized design in use, OR, too much complexity in individual applications. Again, this requires a balance between the design and the available hardware.
If you are using a system that is operating near to this "knee of the curve" you will find that a relatively small increase in the machine load will dramatically degrade the response time of all online users and batch jobs.
If you are using a system that is operating near to this "knee of the curve" you will find that a relatively small increase in the machine load will dramatically degrade the response time of all online users and batch jobs.
- Too many logical views.
Probably the result of an under-normalized design. If you are continually using more than 5 views per physical file then the underlying database probably has no normalized components. For rarely used views, use OPNQRYF or SQL.
- Continually creating large programs.
Symptom of many problems. Some may include: 3GL emulation, 3GL translation, 3GL coding, 3GL logic, "fighting the natural architecture", "ego based" dialogue designs, "ego based" programming techniques, retrofitting of major design changes, not using CUA, not using templates, validation rules in programs, poor knowledge of RDML facilities (lists, subroutines, etc.). Biggest problem is most likely to be a designer insisting on his/her own dialogue design, rather than using CUA and standard transaction resulting from application templates (shipped or in-house). This may be hard to overcome because of the "creativity" aspect.
- "Second Guessing" the enabler at every turn.
Hand coded error handling. Duplication of many features that are automatically provided by the 4GL product. Symptomatic of a 3GL method. The tool is "not trusted" or "not investigated" so everything is duplicated in long coding streams. Another symptom is that the automatic feature is "never exactly right" so the feature is duplicated in long code to achieve minimal or totally negligible benefits. The perceived benefits are usually only apparent to the programmer and do not affect end users in any way.
- No rules in dictionary.
Self evident. Larger programs, harder to maintain.
- No prompting programs.
Poor knowledge of new techniques. Rejection of CUA. Failure to see benefits of consistency. Repeat of large tracts of "search select" logic in every program.
- Fights natural flow of new technology at every turn.
Example of "ego" design. This is a very real problem. The designer sees the application as an expression of his/her own creativity. Rather than follow a corporate or global standard for dialogue design (like CUA), they evolve their own design and then generate many lines of code to fight the natural CUA flow built into LANSA. Every application developed is then different to every other application. Also a symptom of resistance to change: "This is always the way it has been done and this is the way it will always be done". Sometimes this problem is not actually caused by the designer, but rather forced on him/her by the end users of the application.
- Much time wasted in screen panel layouts.
Typically the entire program is functionally complete in just one day, and then the programmer spends five more days trying to make the screen panels do things that are outside his/her capabilities. Real (as opposed to perceived) benefits to the end user are small or non-existent.
- Overloading of development environment.
Large programs, too many developers, deadline panic, poor work practices and unrealistic expectations usually combine to produce this type of development environment.