Technology As Innovator

Putting invention(s) to practice

Re-organization: costs and risks

Origins of Innovation

Supply-pushed Manufacturer Innovation

Formal R&D

Management Innovation

Demand-led End-user Innovation

Technology As Innovator

Technology creates value

When the old economy has been saturated, technology comes in place

A Commitment

Bridging technology and business

Since its development from 1979, e-learning has increasingly played an important role in training of many organizations.

Traditional classification of e-learning is categorization. Courses are put into common categories such as: business, soft skills, technology, social sciences

From Horizontal to Basket

However, categorization gradually fall shorts in the need of real organizational training. One professional should have a combination of knowledge and skills across various disciplines. For example, a Project Manager should have Project Management skills, Leadership, Technical skills, Interpersonal and Communication skills, Client Management skills, Time Management skill, Coaching skill and so on. All these skills belong to different categories like Management, Soft Skills, Accounting, Technology. Any organization may want to standardize the training “basket” for each position. A basket contains courses/programs/articles that one person should acquire in order to perform a role.

then moves on to integration

Now, let’s take a look at the system as a whole. Training is one important part of an organization. Because it is important, it needs tracking and measurement. Key Performance Indicators can be used on Training as on any other departments.

Then an idea crossed my mind: the computer can be taught to ‘know’ what the employees need to learn in order to

• Follow their career plans
• Satisfy the organization KPI

e-learning should no longer stand alone, it should be integrated into other systems instead.

What technologies are available?

Can Portlet do that? Just a suggestion. I’m leaving this to the experts here.

Have you been bitten by an ant? Did it hurt much or was it just itchy?

Have you imagined being thrown to an ant nest? People might get killed from a whole herd of these small creatures.

The same visualization happens to the quality of software products.

Cosmetic and Severity

In a software project, Severity of a defect is often weighed on different levels. Through the terminology might vary, four levels are usually used: Critical, Major, Minor, and Cosmetic.

• Critical is when the defect hangs the program or stops the business completely
• Major is when a the program yields an unexpected result or a business rule is violated severely
• Minor is when an unexpected result can be neglected or a word-around can be used
• Cosmetic refers to usability issues, misspelled words, graphical designs like indent or color palette

Critical ones always receive highest priority to be fixed immediately. Major and Minor ones depend on the complexity and cost of the defect.

What I want to discuss here is Cosmetic defects.

Cosmetic are trivial

Since Cosmetic defects don’t normally stop the business or make transactions go wrong, they usually receive lowest priority. Next, because everyone is busy, every team is busy, these defects might never be solved and just stay there in the bug-tracking system.

“Cosmetic ones are trivial to fix”, said many developers. Yes, one defect on font size or misspelled word may take no more than 5 minutes to be complete flushed. And yet, it is trivial to be fixed…

However, on some occasions, cosmetic defects are one of the hardest ones to debug. It happened once when my team was developing a state-of-the-art system on .NET 3.0 beta in 2005. Because the platform was still in beta, many controls such as grid were not fully supported. When data in the grid could not be managed, the R&D team managed to code the control themselves. It took the three men 2 months for this task. 66 man-days was not an easy number, but since the customer wanted it so badly, on the way they went… Half a year later, the control were fully supported by Microsoft!

Well, the story above is just one exception, let’s get back to our commonly accepted perspective: Cosmetic defects are so trivial they simply itch rather than hurt anyone.

However, from the other side of the line, things are 179 degree different…

The customer simply doesn’t see as a developer sees, or vice versa

The time of “give me a useful application” has long passed. Customers nowadays yeld for “useful and beautiful suites”. Sad but true, users take for granted the functionalities a system has to offer; they don’t care the perfect architecture the development team may be very proud of. This is true it hurts.

Quick ‘n’ flick Google products, highly elegant Apple products and glossy Web 2.0 design are some of the things that plant the desire for beauties in software users today. Presenting users a messy, inconsistent system with easy-to-spot mistakes upsets them greatly, and expect recession in sales figure.

To make things worse, with more communication channels than ever information travel so fast within vertical communities that the brand of the software might be severely “injured”.

Conclusion

Is it time we reconsidered how critical Cosmetic defects have grown to be? I believe no time is better than now to sit down and put our hands on these trivial, 5-minute improvables.