I have spent most of my professional life battling application bugs. Although I have undoubtedly introduced some, I have spent most of my time searching for, discovering, fixing and educating developers about such bugs.
It really comes down to one thing: experience. Or rather: lack of experience.
When developing software, it is possible to take "shortcuts" - places where you deliberately deviate from the established procedures and best practices for some purpose, with the full knowledge of the consequences. The problem is that some organisations are blissfully unaware of the consequences, and thus make such shortcuts far too frequently.
But some things simply have to be done properly.
The Dodgy Database
The database structure has an enormous impact on the application.If you have ever tried to change the database structure for an existing application, you will have found out that this can mean updating lots of application code. Why is this? Because much of the code in the application depends on the database structure.
This strong dependency has one very important effect: Changing the database structure becomes difficult: It cascades into lots of application changes, which means lots of testing, time and expense.
Typical errors at the database structure are:
- Trying to minimize the number of tables: This does not reduce complexity. Instead, it increases complexity, since the purpose of each table becomes much more confused. Normalize your data, and you will end up with well-defined tables.
- Making columns nullable: The default for many tools are to make columns nullable, unless specified otherwise which encourages nullable columns.Many applications deal badly with NULL values.
- Using phantom values to represent "unknown": E.g. using -1 in a numeric column to indicate that the value is not known. Sooner or later, -1 will be a valid value. Just use NULL instead.
- Choosing the wrong data type
- Not implementing refential integrity
So: get your database structure right. This will save you a lot of testing, debugging, time and expense in the long run.
The Damn Documentation
This is almost too obvious, but nevertheless, it is a real problem. Nobody likes doing documentation.The lack of documentation will catch you out sooner or later - and always before you think.
I have actually seen places that do document things. And I have seen places that document their releases.
The worst I've seen, was one site where only releases were documented. The system as a whole was never documented. The result: Any new starter had no chance of understanding the system - and any change was bound to break things because regression test was impossible. The slow decline of the system shouldn't really surprise anybody.
The Missing Unit Test
As any system grows in functionality, the size of the regression test grows too.So the development team can choose between 1 or more of
- Cutting down on the regression test
- Spend more time testing
- Automate the tests
| < Prev | Next > |
|---|
