SOFTware is HARD

Life is full of constraints. It seems like you can never simply "have your cake and eat it". In Product Development , we have the following Project Triangle: Good - quality of the delivered product Fast – time taken to deliver the product Cheap – cost of designing/ developing/ delivering the final product We are told to pick any two! In System Development , the Project Management Triangle follows: Scope – the set of functionality for the system or the work to be performed Schedule – time taken to complete the project Cost – cost of implementing/ delivering the final system We are told to pick any two! A variant in System Development, a Project Management Triangle (more like a Square) follows: Scope – the set of functionality for the system Schedule – time taken to complete the project Cost – cost of implementing/ delivering the final system Performance – the ability of the system to take load and be responsive We are told to pick any three! For distributed systems u...

Machineries need oiling after some time; building structure deteriorates due to natural forces; facades need to be repainted; the Golden Gate bridge needs to be repainted; vehicles need to be maintained; what does that mean for systems? I’m inclined to believe that software systems, like all other things, need to be constantly maintained, oiled, cleaned, before they deteriorate. How does deterioration look like? Deterioration may appear in these forms: systems become slower progressively systems crash/ become unavailable more often systems become more bloated (larger codebase, more storage space required, etc.) The system was originally deployed and tested fine so what went wrong? How does deterioration happen? It typically happens due to the following forces: user-base increased post-deployment to a number that was not intended/ tested for smart users found ways to use the system that was not originally intended for operation/ support team did not make it a point to upkeep t...

This wonderful metaphor by Ward Cunningham reminds us that doing things in a “quick and dirty” manner or taking shortcuts sets us for a debt which, when not repaid promptly, incurs interest in the future. When developing systems, enhancing existing ones, or even fixing bugs, we will typically arrive at a crossroad: should we take the time to do it right; or should we take shortcuts and deliver quickly? It is generally in the interest of the business folks to roll out changes quickly; while the development folks would choose to properly design, implement and test changes before delivery. Fortunately, It doesn’t apply to everything (e.g. code smells or design flaw).  It requires a deliberated decision to do something that is not sustainable in the long-term, but yields a short-term benefit. The result of which is not in the interest of the system's ongoing maintainability.   Examples of technical debt Some common examples include: hardcoding values in source code postpo...

Most popular logging frameworks (e.g. Log4J, SLF4J, Log4Net, EntLib) allow for several logging levels to be instrumented. A common question is: What logging levels are appropriate under what scenarios? The following lists some common log levels are their usage: Fatal - Service/ application/ process about to terminate. Unable to proceed with normal operation. Force a shutdown to prevent (further) data loss. Examples: No more system resource (OOM) Error - Unhandled or unexpected system error has occurred. Current operation/ thread to be aborted. Issue needs to be fixed. Still able to continue with normal operation (at least for other users/ sessions) otherwise. Examples: database deadlock Unexpected/ unhandled exception Runtime errors Transaction aborted Can't create file Warn - Things are generally working fine. Recoverable conditions. Transient environmental conditions happened. Something happened (but was handled) that may potentially ...

Let’s admit it: any form of system documentation is not up-to-date . The moment we start producing it, it is out-of-date. If that is the case, we should do with minimum (perhaps, lean) system documentation that is kept current. This begs the next question: How little is enough? If I imagine myself taking over a system from someone else, I believe the minimum/ lean system documentation should contain the following: Solution Design description of the high-level process flow description of the main modules/ services in the system what are the architecturally significant use cases or main functions of the system? what processes/ components make up the system? E.g. Are there web-based applications? Are there batch processes? what are the databases in use? What are the primary (entity) tables in use? what output is generated by the system? E.g. Are there printed output? Are there output for system integration? Are there messages (emails/ SMS) sent? what systems are integra...

With respect to the Weblogic server, there are several runtime states that are interesting. In addition, certain events/ commands lead to the transitions to other known states. I attempted to capture the state transitions and events into a UML state diagram for easy reference. States in brown are end-states while those in yellow are transitional.

There are 3 main concerns that performance testing seeks to address. These concerns form the acceptance criteria or metrices for the tests. They are: User concern – Response Time Business concern - Throughput. E.g. requests/ sec; calls/ day System concern - Resource Utilisation (often overlooked). E.g. processor & memory utilisation; disk I/O; network I/O Purpose of Performance Testing Depending on what has been done, performance testing helps in assessing: release readiness infrastructure adequacy software performance performance tuning efficiency Some Definitions Performance Target = Performance Goals Performance Requirements = contractual obligation, SLAs that cannot be compromised. = Performance Thresholds Workload = Stimulus applied. E.g. number of users, concurrent users, data volume, transaction volume. Types of Performance Testing Load Testing - testing within anticipated production load/ volume Stress Testing - testing beyond expected production load/ v...