being switched

To ensure that a software you help to architecture does not start to disintegrate upon entering a stage of testing is a massive effort. Maybe it's just me, my phobia, my paranoia. But being in the knowledge of inefficencies and insufficencies of the framework, and worse constantly finding more tells me that my fears are real. One comforting fact is that the frequency of discovering such items is decreasing.

As such items are getting more difficult to find (which is good), that basically implies that one have lesser to do (predicted). So it's natural to be reassigned to something else, say development of business components. It's a welcome change, a switch in the thinking process. But I must stress that it's a painful switch. Business component development requires a more top-down thinking process, making sure that all the if-else rules are done in the correct order and before any action is taken. Coming to the action, data must be retrieved or updated in the correct order (and remember to handle exceptions so that they can be rolled back as well). In fact, I don't miss business component development.

Framework component development is more focussed at a single task, and it have to do it well. It should not care whichever order it is placed in the entire process. It only needs a very clear and concise interface, preferably the same interface as other similar components, and I stress again, does its work well, very well. Designing for a clear and concise interface shared between different components is not an easy task. Expect constant changes, sometimes a complete overhaul. Maybe that's a sign of a poor design phase, but there's no alternatives, if it requires to be changed or upgraded, it just have to be done. Each component then have to be ensured that it can stand on its own 2 feet, and handle every possible scenario that can pass through it, and not fail unexpectedly. Almost every possible error have to be handled properly.