Technology As Innovator

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.

Apart from motivationally writing for the web, I have been invited to universities as a motivational speaker to talk about the IT industry and IT occupations with IT students.

What question do you think is most frequently asked?

What programming languages and tools are currently used in your company?

It is not a surprising one because the same question has been asked much more frequently on technical forums and newsgroup and has caused so much debates on T-tool vs. U-tool and more heatedly, X-language vs. Y-language.

And my answer is

“It is nice that you are preparing the knowledge and skills that you think your potential employers will seek. However, skills and experience in a particular programming language is not the only technical skill employers seek in candidates. They’re also looking into the foundation technical knowledge, such as but not limited to: Object Orientation, Design skills, Software Methodologies, Data Structures and Algorithms, Database Design, Architecture, Computing Theory, that empower your programming skills. You may do programming with, let’s say, Java relatively well in some situations without the above knowledge, but if you are thrown into a more complex project to build a huge product, the risk is high.

One example. You spend two to four years in college polishing your skills in X language that you predict will (still) be hot in a few years when you graduate. When you do graduate and apply for jobs, if they say “Sorry, X is old. We’re needing Y people”, what will you do? Spend the same amount of time learning Y? No, it’s not the way it should work. Foundation knowledge is the root, languages and tools are leaves. Equip yourself with the foundation, and when technology changes (is IT a slow changing area that does not change every 6 month or so?), you can adapt more easily.

When you have mastered the foundation knowledge, and possessed significant experience in using programming languages, which IDE is not a bug big issue.

Besides, about recruitment, technical skills are not the only evaluation criterion. Think about soft skills and attitude too.”

I was thinking about my profession

The number of Business Analysts and System Analysts required in software companies is not that many compared to developers; in some smaller companies with less formal process definition, some developers take the Analyst role. If the need for Analysts were higher, this question could have been asked: “What modeling languages and tools are currently used in your company?”

The answer is simple: Unified Modeling Language. UML itself has been a well-established language for modeling. More of a reason why it has become so popular is due to the promotion of UML by RUP.

But once again, UML is a language. The case is not much different from that of programming languages. Knowing UML is not enough to perform all tasks Analysts do, Business Process Modeling for instance - and a new standardized set of notations named BPMN (Business Process Modeling Notation) is being proposed.

Underlying UML skills are Modeling skills. Modeling languages are used to present information in a more visual (and structural?) way. You need to know what model or diagram should be used to present what kind of information at what time in what situation to whom.

Model is one kind of information. In order to develop solid Modeling skills, Information Processing skills and Data Analysis skills need to be developed first or in parallel.

With all those skills at hand, you will be able to guess how shapes are categorized and may quickly locate the right notations you need in Modeling tools, no matter if it’s Rational Rose or Visio or Enterprise Architect or so on.

After you have created a good piece of model, you may want to present it to customers or other teams in your project. Presentation skills may help.

Side discussion: Model vs. Diagram

Throughout this article, I have used Models consistently, without mentioning diagrams. The may raise question since “UML diagram” is a very common terminology. The reason is because Analysts produce visualizations which are not diagrams too. Organization charts, map, prototype are just a few to name. ‘Model’ covers all of these, of course including diagrams. Also, one trivia is that the word may remind the fact that information systems actually model the real world.

Conclusion

So to conclude, foundation knowledge is required in any profession. Technology and tools change so quickly, but concepts do not as quickly. Build your internal strength should be the higher priority.