Software development, that is… it is getting repetitive:
- Design the database (the database schema represents facts, but those facts will be incomplete)
- Code the business logic (Queries, queries, queries, in uncomfortable semi-standard SQL, there will be problems with:
- performance (inefficient queries, lack of indexes, degradation because cascade updates or deletes or because of integrity verification)
- concurrence (overwritten data, death locks, inaccurate reads)
- code maintenance( SQL is ugly, cumbersome, hard to refactor, hard to modularize)
- ORM is either inefficient with rich domain model, or efficient and with an anemic domain model
- Code de User Interface
- If is a heavy client, it will be ugly (because people erroneously think that only web based applications can be pretty)
- If it is built in HTML as they current hype dictates it will have browser compatibility problems
- It will not map easily to the database model / domain model (specially report like stuff).
- If it is a web application, it will use convoluted and not type safe communication between the different screens (server side navigation) or, it will use lots of JavaScript and essentially will a a one page application, and therefore it will become :
- In heavy clients all navigation will be deceptively simple and type safe, but that will lead to spaghetti like dependencies between the screens.
- Test
- Security concerns will be left to the end, and most queries will need recoding because what data can be seen is always dependant on the privileges of the users.
- Queries will return the wrong data when they are cross compared (a summary report like screen will say that earnings were of the day were $1352, but if you sum the amount of each of the sales, it will be $1456, or $1265, or something else. The most common reason? a status field that you forgot to take in account and that indicates that, for example, one of the sales was canceled, or one of the sales was in a foreign country money, or you forgot to take in consideration a discount.
- Dependant UI controls (like chained comboxes) when used in an unexpected order will fail (or, if used to save data, might fail when editing that data).
- Some controls that are only comfortable to use if the list of rows displayed in them is short (less than around 25 items), will have list of more than 250 elements, sometimes even thousands of elements, and will need to be replaced by search screens.
- Nobody will test the performance of the applications for the large amount of concurrent users that will use the system in productions.
- Production
- Some tables, with supposedly immutable data, will need CRUD functionality, since there is no time to create the CRUD screens, data will be inserted directly using POSQL (Plain Old SQL) , and sooner or later someone will have to edit or delete some data, make a mistake with the WHERE condition, and destroy a large amount of rows. The last backup will be a lot of weeks old, and data will need to be recaptured.
- Since there were no performance tests, the processor will go 100% and RAM will not be enough, the server will be incredibly slow, or plain crash.
No comments:
Post a Comment