Quote of the Day and Happy Chinese New Year Everybody

Sometimes through heroism you can make something work. However, understanding why it worked, abstracting it, making it a primitive is the key to getting to the next order of magnitude of scale.

-- Robert Calderbank
Princeton

Congrats to Java finally cracking into hard real-time environment

David F. Bacon from IBM research published an article Real Time Garbage Collection on recent ACM Queue magazine. In which he introduced project Metronome at IBM that successfully delivered a JVM implementation that removed three major road blocks that’s been keeping people away from using Java in any hard real-time environment (even with the real-time JVM specification extension):

• Undeterministic garbage collection
• JIT compilation
• Dynamic class loading

The Metronome project has been adopted in the new Navy’s DDG-1000 destroyer. This is pretty significant breakthrough since now people will have a choice to facilitate safer language features such as garbage collection in not just soft real-time but hard real-time system like the weapon control system on a DDG.

It’s an exciting time again for programmers

About a couple of months ago, during the farewell lunch of mine at my previous work place one of my colleague asked me the question “What is the most exciting thing you think will happen to our field (as programmers) in the next 5-10 years?” To my surprise, I did not even pause for long (considering I am usually not very good at this kind of prediction) before I giving out my answer “The increasing parallelism in the hardware”. Now several months have passed, not years, you can already see the movement almost everywhere from hardware to software, from industry to academy. Just when you think Moore’s Law no longer applies to the modern processor design any more, it seems morphed into a different dimension, although the processor speed increase slowed down, the number of independent cores is currently increasing at a dazzling speed. Intel just releases its showcase an 80-core processor prototype. Now just imagine the challenge for software engineers to utilize this kind of concurrency and calculation power. Presently even with some of the natively thread-friendly language such as Java or C#, programmer still had hard-time to build robust and highly parallel software to utilize 8-16(16-32 cores) CPUs in some high-end servers; now imagine 5 years from now not only the high-end servers but almost all the computers even the pocket size ones will have multiple cores. The reality is calling for a new mechanism to deal with this unprecedented new challenge and that’s why Sun is working on Fortress (designed to work with tens of thousand processors, petabytes of memory) and IBM is working on its own X10 language (designed to help people moving from Java platform) to harness the power of this growing beast. Recently an excellent article Unlocking Concurrency was published on ACM Queue magazine, a very interesting read if you are looking for a peek into the future, but nevertheless this is probably the most exciting time for programmers since Object Oriented Programming was invented in 60-70’s.

Talk about requirement engineering (RE)

Recently I read a so far the most comprehensive research paper on how requirement engineering improvement benefits other aspects of both upstream and downstream activities in software development life cycle. This paper "An Empirical Study of the Complex Relationships between Requirements Engineering Processes" by D. Damian and J. Chisan in IEEE Transaction on Software Engineering July 2006 Issue presents the empirical findings from a case study conducted at Australia Center for Unisys Software (ACUS) during a RE improvement initiative aimed to move its RE practice up from CMMI level 1 to CMMI level 2. Before the initiative ACUS performs its RE process by simply gather its requirement in a primitive one to two sentence feature description list, due to this vague definition mechanism ACCUS suffers multiple RE related problems such as feature creeps, incorrect implementation, inaccurate estimation, and eventually lead to budget and schedule overrun as well as low customer satisfaction. This research is exceptionally interesting to me since one of my recent project suffers from exactly the same RE challenge which resulting to a somewhat project failure although there are many other contributing factors, the RE problem is definitely one of the major factors. ACUS's initiative is fairly straightforward without adopting any rigid RE methodology but instead an optimized process roughly based on RUP which contains the following elements:

· Feature Decomposition

· Requirement Tracability

· Group Analysis Session

· Cross Functional Team

· Structured Requirement

· Testing According to Requirement

According to the research, to the researcher's surprises the Group Analysis Meeting and Cross Functional Team were rated the top contributors among engineers, and on the other hand Feature Decomposition and Requirement Tracability occupied the top 2 places among managers. This conclusion is consistent with the widely accepted belief that Agile practice such as Group (Paired) Analysis Meeting and Cross Functional Team benefit mostly to the engineering team result in quality and productivity improvement, and formal techniques such as Feature Decomposition and Requirement Tracability mostly benefit managerial effort and overall controllability.