Tuesday, December 22, 2009

Will Java and .NET continue to tough it out ?

.... something else I was reading at Tech Republic :

How will Java SE 7 will fare against the .NET CLR?

Looking at the Java SE 7 feature list, it looks like a good advancement for the system. Is it a game changer? I don’t think so. The JVM and the .NET CLR have been through a ton of changes in the last few years; both have enabled developers to do a lot of things that used to only be the realm of very advanced programmers. While the JVM and the .NET CLR do not always implement the same ideas at the same time, the best ideas in one end up in the other fairly rapidly — we’re seeing this even beyond the runtime level. Hibernate is a huge hit for Java, so .NET got NHibernate. .NET’s closures have made a lot of developers, and it looks like Java will get them too (yes, that’s a language feature, not a runtime feature).

Will one runtime beat the other in the foreseeable future?

While the JVM and the .NET CLR are similar beasts at a technical definition level, both have their own markets, neither of which is very agile. It’s not like someone who has built their infrastructure around .NET servers and IIS can wake up tomorrow and move everything to Java or vice versa. Even if a company did decide to move its development from one platform or the other, it would require replacing the entire development team (or retraining them from the ground up). Even then, there would be severe skills shortages; after all, a senior .NET developer cannot suddenly become a senior Java developer after three months of training. In addition, they would need to keep the current staff around to maintain the existing code base. And do you really think that the staff is going to sit by and watch as their jobs are either about to go away, or their skill set is about to become useless (or less valuable)? Of course not. Making a wholesale switch from Java to .NET (or .NET to Java) would be suicide for an organization. At best, there could be a multi-year project to retrain folks. You still have shops moving from VB6 to .NET, and it has been about eight years since .NET was released.

Is Java development cheaper than .NET development, and, if so, will people move to Java to save money?

If you look just at the tools, my answer is “yes and no.” Yes, you can run Java on a fully open source stack if you want. You can take the Linux/Tomcat/MySQL/Java stack, or the SpringSource stack in the server room, and use Eclipse or NetBeans on the developer’s machines. But let’s say that, for whatever reason, you are not a fan of the open source alternatives (I am not saying the alternatives are not good); in that case, the Java tools are very price comparable to the .NET stuff and, in many cases, more expensive. And judging from the business that companies, including Oracle (through its acquisition of BEA) and IBM (the Rational toolset), are doing, it is clear that many companies see a need to pay for proprietary Java tools. As far as pricing goes, Microsoft is almost always the least expensive enterprise class vendor in any given marketplace.

Plus, you have to look at how much money companies would save compared to the cost of the switch. A copy of Visual Studio costs less than a week’s salary and benefits for a mid-range developer. It will certainly take much, much more than a week for the same developer to learn Java and become as good with it as he was in .NET.

For the sake of fairness, this analysis goes the other way too. The cost of the tools is inconsequential in comparison to the pain of a switch. There are two exceptions to this scenario. The first exception is in the case of a new company (or someone choosing between one or the other), and there is no cost of switching. In that scenario, Java still isn’t any cheaper, since Microsoft gives away free copies of Visual Studio (the Express editions), and if you are a new company, the BizSpark program is a way of getting three years of MSDN and Microsoft licenses for free — that’s not too shabby. The other exception is for a company that has a really high server-to-developer ratio (think Google or Yahoo!). This type of company might have a handful of developers working on an application that runs on thousands of servers. In that situation, the developer tools are not where the savings occur — the server room is. For a company in that situation, Java (and other open source technologies) can have a decisive cost benefit.

How many scripting languages would a Java developer need to know to be as effective as they would be in .NET?

First off, are you doing any Web development work? If so, you will probably need to know some JavaScript and get familiar with the frameworks out there for them, depending on your plans. For the backend work, knowing a dynamic or a scripting language is not mandatory or necessary. That being said, there are a lot of great choices in the Java world for that purpose. As someone who is not currently a Java developer, I do not have any hands-on experience in these, but I have heard nothing but rave reviews of Groovy and Scala. If you are looking for something with a bit more mainstream exposure, JRuby and Jython are excellent options.

The JVM has seen an explosion of non-Java languages in the last few years, and developers can now choose from a ton of options. Learning one of these options will certainly make you a better developer (even if you do not use them for an actual production project) and give you another arrow in your quiver for tackling tough projects.

Will Java displace .NET? Not any time soon. And .NET is not getting rid of Java either. Both ecosystems have advantages and disadvantages. I believe that which one you end up using will depend mostly on personal preference and local career opportunities.



10 Things To Consider About Open Source

I was thinking of argumentative points for a client on Open Source when I came across this article in Tech Republic :

1: Are the open source license terms compatible with my business requirements?

Open source is mainly protected by copyright law, and the license provides the basis for the rights you have on the software. To be classified as open source. any product needs to adhere to the four freedoms: to use, to study, to redistribute, and to improve. However, licenses often include other terms that might be incompatible with certain business models. For example, the popular GPL license asks that any improvements and derivative works you create also be released under the same quid pro quo terms.

While this seems like a reasonable condition and will be not an issue for generic enterprise use, it can be a deal breaker for a proprietary product company that wants to include a GPL component in its product. Thus, it is important to make sure you understand the terms of the open source license before you adopt a component into your enterprise. The Free Software Foundation (FSF) and Open Source Initiative (OSI) serve as guides to open source licenses, and both have pages that validate and catalogue open source licenses.

2: What is the strength of the community?

An open source project is not just about the code, but also about the open community surrounding and sustaining the project. These communities can range from the lone teen developer to a single organization to complex diverse multi-entity communities, such as found in Linux and Firefox.

A well known open source law demonstrated first in Linux is that “with enough eyeballs all bugs are shallow.” What this means is given a large enough critical mass of people in the community testing, maintaining, reviewing, and fixing the code, bugs and security vulnerabilities become less of a problem. A large active, diverse, and responsive community is always a key indicator of the health and sustainability of an open source project.

3: How well is the product adopted by users?

The test of any open source project is how well it has been adopted by various user groups and organizations. Many of the mature open source projects showcase various clients who have adopted and are using their product. This gives you some assurances that the product will deliver on its promises, especially if you find an existing client similar to your enterprise.

Probably the best insight you can get into a product is from another user who has been using it for a while. The best projects have a rich community of users with a dedicated mailing list, where you can seek input on the product from a third-party user organization.

4: Can I get a warranty or commercial support if I need it?

All open source project licenses are provided free “as-is” without any warranty. Based on your need, you could also support it to a certain extent internally and depend on voluntary support from the community. Voluntary support is not expected to compete with commercial SLAs, but the general responsiveness of the voluntary support will certainly improve your confidence in investing in the product. However, it will take you only so far.

Most enterprises are looking for a neck to squeeze in terms of commercial support/warranty, and a mature community includes vendors that can deliver to certain service levels. The ideal open source project has multiple vendors involved in the product that provide different types of support from customization to maintenance to 24×7 production assistance.

5: What quality assurance processes exist?

Many of the most popular open source projects now have the maturity and stability to support mission-critical production environments, but there are still many where the stability does not meet the mark. Of course, stability requirements will depend on where you hope to apply the product.

Whatever your needs, it is always good to check the quality assurance (QA) process being followed by the project in its releases. If the quality assurance processes are not up to your organizational standards, you should consider the cost of conducting the missing QA process either internally or by a suitable vendor.

6: How good is the documentation?

Some open source projects can be very poor in their documentation. The software engineers leading open source projects are often focused on developing the product, so documentation is frequently an afterthought. At bare minimum, products need user manuals and administrator guides. Sometimes these guides are available online in the form of a wiki or even tutorials. Of course, the popularity of the product should have the quality of documentation factored in, but you should always ensure this documentation is suitable for your target user base.

7: How easily can the system be customized to my exact requirements?

Open source, as opposed to proprietary products, inherently means that the code is available for you to customize to your heart’s content. However, the cost of customization varies based on the architecture and extensibility of the system, how cleanly the code is written, and whether the product APIs are well documented.

All good open source projects include a well documented extensible plug-in architecture that can be used to customize the product. Generally, there will be a vendor that can do this customization on your behalf for a fee. However, it’s important to have more than one option available to you (including an internal option if possible). Otherwise, you have not truly eliminated vendor lock-in by going with open source.

8: How is this project governed and how easily can I influence the road map?

There are different models for how open source projects are run and how decisions are made. The best governance model is one that includes all stakeholders — developers, users, vendors — in a transparent decision-making process. For larger open source projects, a dedicated foundation is also invaluable in providing the necessary legal backing and assuring the intellectual property is managed well. Ultimately, the better your ability to engage and influence the developer community as a user, the more responsive the project will be to your needs.

9: Will the product scale to my enterprise’s requirements?

This check is important, even for commercial products. Research case studies and performance tests to ensure that the application can scale gracefully to the demands you place on it. Many open source applications are built on the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) or J2EE technology stack, which is generally one of the most scalable technology stacks available. A lot of the popular Web application portals utilize this stack and have customized it end to end to accomplish great scalability. One of the benefits of going with an end-to-end open source solution model is the long-term flexibility it provides.

10: Are there regular security patches?

A project that takes security threats seriously and is able to fix vulnerabilities before an attack can exploit them will have an established process for keeping track of security flaws and proactively elevating fixes up to the users. Turnaround time from identification to resolution is critical. This is the same for any proprietary project, but the benefit of open source is that you have the right to audit the code base independently for any security flaws and can fix them yourself without waiting for the community to respond.



Thursday, December 10, 2009

scarab reborn ...

scarab is now : ECOSPHERE ... what is it ?

ecosphere= an ecosystem platform where data and content is separated, understood, shared and disseminated as intelligence. Ecosphere consists of a parser, reasoner (Bayesian inference engine), message broker and rules engine. Ecosphere provides intelligence (knowledge representation) via knowledge engineering.” – in other words : ecosphere brings meaning to unstructured, structured and distributed data by enabling machines to understand data and content.

ecosphere : building intelligent systems in a open, heterogeneous, dynamic, distributed environment
system /sys·tem/ (sis´tim)
1. a set or series of interconnected or interdependent parts or entities (objects, organs, or organisms) that act together in a common purpose or produce results impossible by action of one alone.

Wednesday, November 4, 2009

future of the web ... (in 5 years ?)

found this on twine : what the web will be in 5 years. worth looking at ...
I was wondering about where the web will be in 2 years time and someone came up with this. Well, following current trends, anything can happen :).
Oh.. and all you so called "web designers" out there, better read this.

Tuesday, November 3, 2009

scarab's evolution

scarab is evolving from a heavy, memory sucking beast into a lightweight, distributed and fast bird. Or flying insect. scarab was reviewed, criticised, praised and lifted to levels I couldn't imagine that it could be taken to.

Now, all that remains is to let it roam into the commercial domain where money rules. Still, most do not understand what it actually does. scarab is not the answer to world hunger or web 3.0. scarab helps reduce overheads and opex to enterprises where vast amounts of related and unrelated data reside in warehouses, waiting to be netted in, massaged and presented as knowledge that can be manipulated by high level execs in silk ties.

hmmm ranting again .....

Thursday, September 24, 2009

scarab is alive ... barely

2 years, 4 months and 23 days .... that's how long ago I sat down in front on my notebook and fired up my Visio. I laid out the initial data flow plan for scarab. Semantics was always an itch I needed to scratch ever since my studying days. Majoring in AI made the itch worse.
The diagram stayed a diagram for the next 2 months, which was when I used eclipse to compile together the necessary libs needed for web services. Then I started building the inferrer, or parser as some would put it. I was working on black box methods (which was easier). 6 months down the road, I realised black box was not going to cut it.
True inference needed Bayesian methods. That set me back another 3 months. I finally managed to complete the base engine 3 months ago. Then I decided (actually someone in Skali decided) that a vertical demo was required to show what scarab could do. I wanted to be radical, so Flex was chosen as the weapon. Well, today, 24th September 2009, scarab's inferrer is ready to rock!
Actually, it needs to wait until I complete the ontology that goes with it ... not just some freeware RDF off the net. scarab will be live and online, in early October 09.


Tuesday, June 23, 2009

10 skills developers need in next five years

I got this this morning from ZDNetAsia , worth reading .....

"With the recent changes in the economy, a lot of developers are focused on their short-term job prospects.
At the same time, it's important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Hence, here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years.
The list is hardly exhaustive, and there are huge swaths of the industry it won't cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can't go wrong learning at least seven of these skills--not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.
1: One of the "Big Three" (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems--.NET (VB.NET or C#), Java, or PHP--for the near future.
It's not enough to know the core languages, either. As projects encompass more and more disparate functionality, you'll need to know the associated frameworks and libraries more deeply.
2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR.
Flash's competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.
3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to "the basics" their framework provides them with.
But companies have been demanding more and more who really know how to work with the underlying technology at a "hand code" level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.
4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it's getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service.
Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can't work with Web services will find themselves relegated to legacy and maintenance roles.
5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can't change the accounting rules without working with IT to update the systems. And an operations manager can't change a call center process without IT updating the CRM workflow.
Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers--and highly sought after in the job market.
6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren't quite mainstream--but the ideas in them are. For example, the LINQ system in Microsoft's .NET is a direct descendent of functional programming techniques.
Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won't just improve your resume, though; it will expand your horizons. Every top-flight developer I've met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.
7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed.
Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.
8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, "From here, we can also add this functionality fairly easily, and it will get us a lot of value", or "Gee, that requirement really doesn't match the usage patterns our logs show" will excel.
As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.
9: Development "hygiene"
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. "Code cowboys" who store everything on a personal USB drive, don't document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.
10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important.
There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future."

Friday, June 12, 2009

... of beetles and intelligence ...

... thinking of changing SCARAB to a MOCKINGBIRD ... fed up with dung beetles .... cute but they stink ... mockingbirds on the other hand are cute, efficient, fast ... and necessary .... all the bru ha ha over semantics and business intelligence  doesn't seem to go anywhere, not in Malaysia anyway.
Everyone's talking about semantic searches, when most of them don't even know what that means. The same goes for Green IT ; the people who are supposed to have the $ for funding R&D in Green IT think it only has something to do with planting more environment friendly veggies .......
OK. I'm starting to rant again, but all this c**p is just p******g me off. No one seems to want to address current issues at hand; stuff like actual business intelligence such as HR skill set matching, true cash flow tracking, distributed intelligence in governance etc. wonder when everyone is going to wake up and realise that they missed out spending time with their 3 year old while wasting time talking about clearing another 100 hectare forest to plant more palm oil ... Green IT ......



Thursday, June 11, 2009

dreamline ... desperation, hope and realisation...

I was listening to an old Rush album on my way to work this morning, and I wanted share the lyrics from their song 'Dreamline' from the album 'Roll The Bones' ..... please remember these are copyrighted .... it's just to inspire entrepreneurs like me who like to dream big .... :) :


He's got a road map of Jupiter
A radar fix on the stars
All along the highway
She's got a liquid-crystal compass
A picture book of the rivers
Under the Sahara

They travel in the time of the prophets
On a desert highway straight to the heart of the sun
Like lovers and heroes, and the restless part of everyone
We're only at home when we're on the run
On the run

He's got a star map of Hollywood
A list of cheap motels
All along the freeway
She's got a sister out in Vegas
The promise of a decent job
Far away from her hometown

They travel on the road to redemption
A highway out of yesterday -- that tomorrow will bring
Like lovers and heroes, birds in the last days of spring
We're only at home when we're on the wing
On the wing

When we are young
Wandering the face of the Earth
Wondering what our dreams might be worth
Learning that we're only immortal
For a limited time

Time is a gypsy caravan
Steals away in the night
To leave you stranded in Dreamland
Distance is a long-range filter
Memory a flickering light
Left behind in the heartland

We travel in the dark of the new moon
A starry highway traced on the map of the sky
Like lovers and heroes, lonely as the eagle's cry
We're only at home when we're on the fly
On the fly

When we are young
Wandering the face of the Earth
Wondering what our dreams might be worth
Learning that we're only immortal
For a limited time

We travel on the road to adventure
On a desert highway straight to the heart of the sun
Like lovers and hereos, and the restless part of everyone
We're only at home when we're on the run
On the run...


 - geddy lee, alex lifeson, neil peart-




hmm ... imported my old blog and messed up fonts ....

I decided to import my old blog's posts and realised that my posts were in pale yellow (i had a dark background then .... ). Now, I have to change all the fonts .... sigh .... so much for lazy shortcuts .....

Thursday, June 4, 2009

why a new blog?

Believe it or not I've forgotten my email address which used to start analog ravings before. So, now, in roder to bore everyone more, I've decided to move on to another new blog. Anyway, I needed to grow out of my raving moods.
Well, scarab.semantics is supposed to be a place for me to rave (again?) about my scarab project, semantics, AI, ambient intelligence, food, RPG and other stuff most people find too boring to read. And I'm hoping no one would be reading this blog.
Well, here's to another blog from me. Let's hope it lasts longer than the previous one. At least until I forget the email I used to set this up.

Tuesday, March 31, 2009

Learn to Understand Your Own Intelligence

Three years ago I listened to a lecture on cognition that changed the way I
think about intelligence. This is the crux. There are two types of
cognition. The first is normal cognition. This is the ability to
retrieve knowledge from memory. When you are asked a question on a test
and produce an answer, that’s a display of cognitive ability. The
second type of cognition is metacognition; the ability to know whether
or not you know.

Have you ever been asked a question that you knew the answer to, but
you couldn’t find the right word? This is called the “tip of the
tongue” phenomenon and I’m sure we’ve all experienced it. You know that
you know the answer, but you fail to produce it. If someone said an
answer, you would know instantly if it was correct or not. In these
cases metacognition exists without cognition.

In short, cognition is knowing, metacognition is knowing if you know or not.
Both can exist together, but many times they don’t.

How Does this Affect Intelligence?


So what importance does this have and how is it relevant to self
improvement? The fact that there are two different kinds of cognitive
ability means that there are different types of intelligence.

In traditional education, intelligence is measured by cognitive
ability. For some people this is works well. They can easily produce
everything they know on a test. But for others it doesn’t work out so
well. The people that know something cold but can’t find the right
words on a test are awarded with poor grades and considered inferior.

But does this inability make them any less intelligent? They know
the answer. If the question came up on a task, they could refer to a
book or a quick Google search. In reality they’re just as effective as
the people that aced the test. They just can’t prove it as easily.

The Importance of Knowing what you know

Unless you’re taking a test or playing Jeopardy, metacognition is
more important to success than cognition. In real life, when you’re
faced with a question the first decision is whether you know the answer
or not. With strong metacognitive ability this is easy. If you know the
answer, but can’t come up with it, you can always do a bit of research.
If you know for sure that you don’t know, then you can start educating
yourself. Because you’re aware of your ignorance, you don’t act with
foolish confidence. The person who thinks they know something that they
really don’t makes the worst decisions.

A person with poor cognitive ability, but great metacognitive
ability is actually in great shape. They might do poorly in school, but
when faced with a challenge they understand their abilities and take
the best course of action. These people might not seem intelligent at
first glance, but because they know what they know, they make better
decisions and learn the most important things.

Clever but mediocre people

At the opposite end of the spectrum are people with great cognitive
ability but poor metacognitive ability. These people are proclaimed
geniuses at a young age for acing every test and getting great SAT
scores. Unfortunately, they’ve been ruined by poor metacognition; they
think they know everything but they really don’t. They are arrogant,
fail to learn from mistakes, and don’t understand the nuances of
personal relationships; showing disdain for persons with lower
cognitive ability.

So who is superior? In a battle of wits the higher cognitive ability
prevails, but life is not a single encounter. It is a series of
experiments in succession, each building upon the last. Learning
requires knowing what you don’t know, and taking steps to learn what
you need to. People with poor metacognitive ability never realize that
they don’t ‘get it’. They also don’t realize what’s important.

This doesn’t preclude them from material success. But, perhaps
that’s a poor measurement of intelligence as well. There are many
people who become rich and successful by their cleverness and cognitive
ability, but as human beings are quite mediocre. Is the man that makes
a million dollars, but is cruel and abusive to his employees and
family, really more intelligent than the poor man who lives a modest
and loving life? I don’t intend to demonize wealth, only to state that
it should not be the measure of virtue.

Use your metacognitive ability

So what do we know and what do we not? And how can we tell the
difference? There is so much to know in the world that the most
brilliant human minds can grasp only the tiniest fraction. For this
reason we should always be in doubt of what we know. The closed mind is
oblivious to its surroundings, while the open mind absorbs them. Like a
sponge, it soaks up observations, becoming fuller and more robust.

But we can’t live in total doubt. If we did we would never act,
paralyzed by our inadequate knowledge. We must trust our intuition. If
something makes you feel a certain way, that feeling is real and must
be respected. Act based on your own convictions, not those of others,
and keep an open ear for new ideas.

The most important mental power is the ability to know what you
don’t know. The recognition of a fault is the first step to
improvement. Don’t try to hide a lack of knowledge. People will see
through it and you’ll appear foolish and arrogant. If you admit your
ignorance, people will help you learn and respect your humility. For
intelligent people this is the toughest lesson to learn. We are used to
being right, and consider being wrong shameful. We’re afraid to lose
status by looking stupid. This vain arrogance is a great weakness and
the source of many problems. To crush it and embrace humility is the
mark of true wisdom.





Tuesday, January 27, 2009

Intutive Software?

Found this article on Tech Republic while browsing my junk mail just now, and found that this is not junk at all ..... :


Would you want your brakes installed by someone who is on their first day on the job with no training and expects fixing brakes to be intuitive? I didn’t think so. But this is essentially the expectation that we have been perpetrating in this industry for years now.

Somewhere along the way we lost track of the fact that software is often used to accomplish some very complex tasks. As a result, this expectation has turned into a curse. Users now feel entitled to sit in front of any given piece of software and instantly understand its every nook and cranny. And if they can’t, it’s the software developer’s fault for not making intuitive software. This is an unrealistic expectation, and it’s time to start reversing the trend. Below I present what I perceive to be the problems that have perpetuated the myth of intuitive software, as well some potential solutions.

The problems

The first part of the problem is the idea that users who have no experience or understanding of the field of knowledge the software addresses should be able to use the software. If I sat in the cockpit of a 747, I would not expect to be able to fly it after glancing at the controls (even if I did put in countless hours of Wing Commander), yet this is the first mistake users make when blaming the software developer. “I don’t know what it means when it asks me to enter my IP address, so this software is hard to use.” Would users prefer for the software to ask for their system administrator’s e-mail address, and then automatically e-mail that person and ask them to reply with the IP address? Or, would the user want the software to provide a short tutorial on networking? If the user does not understand what an IP address is, no application should be teaching it to them; the software should be looking for a way to get the information without the user’s help.

The next part of the problem is that even users who are knowledgeable in the problem domain are not necessarily going to “get” a piece of software if the domain is sufficiently complex. Word processors are a great example. A word processor is a piece of software designed to do hundreds of tasks — everything from writing grocery lists to legal briefs to screenplays, all of which have different workflow requirements, formatting needs, and so on. Needless to say, any piece of software designed to do not just one complex task but hundreds of complex tasks is going to be complex. Given the complexity of these pieces of software, why would we expect someone who is good at writing essays out by hand to instantly “get” a word processor right away?

ERP and CRM applications are some of the favorite punching bags in the industry. It is common knowledge that a huge number (some studies show the majority) of licenses sold for applications like SAP go unused. These projects have an astoundingly high failure rate, and when you consider their sticker price, that is really unacceptable. One of the typical causes for a project to be declared a failure is that it is “dustware.” That is, after a year-long integration and millions of dollars in consulting fees and license costs, the users fire it up, stare at the screen for five minutes, shut it down, and it sits on the shelf for eternity. Well, not to give these enterprise-class vendors a free pass, but I do not think that plopping a user in front of a complex piece of software untrained and with no documentation is a good way to get them to use it. If I expect a crane operator to be trained in that piece of equipment before using it to lift 10 tons of steel, I think it’s reasonable to think that someone should be trained before using a piece of complex software.

What is most frustrating to me is that things were not always this way (at least, that’s my recollection). WordPerfect 5.1, which is often remembered with a mixture of fondness and disdain, required you to purchase a keyboard overlay, a 100 - 200 page Quick Reference guide, and have a 500 page in-depth manual on your desk to be well-equipped to use it. But the simple fact was, you really needed to read a few hundred pages of text to get the gist of what was happening before you could sit down and do real work. That was also an era when there were local users’ groups for users to get together and help each other out. In addition, companies also sent their employees to computer training.

Now employers are looking for computer savvy and computer literate employees, which seem to mean, “I can use Google to find Gmail.” Instead of teaching true computing skills, such as how to form effective search queries, how to discern which Web sites are credible, and how to maintain security of private data, schools are letting students play on Facebook and LiveJournal, and saying, “Oh, the kids are learning how to use a computer.” Nonsense. The students are learning, at best, how to use a particular Web site that will be different by the time they graduate.

Proposed solutions

Our industry needs to do more about this issue. Sure, we occasionally throw our hands in the air and spew forth a loud “RTFM!” Which would help if “TFM” wasn’t often so useless. After all, why bother writing good documentation when the only people who care to read it are those who can figure it out on their own? It’s a catch-22. So first up is the documentation. If your application is addressing complex tasks, you can’t count on an intuitive interface.

A complex task will require either a ton of walk-through style wizards (which power users hate and even beginners eventually outgrow); or an interface like a command line; or a toolbar crammed with buttons, lots of keyboard shortcuts, or some other way of packing a lot of functionality into a small screen space. And with interfaces like that, the documentation needs to be better. Unlike a wizard-driven interface, you do not have a paragraph to explain each choice; at best, you have a tooltip to explain what function the icon represents. Users in these situations need to be able to rely upon the documentation to give them in-depth information.

A fallacy is that in order for software to be intuitive, it needs to be different from the “hard to use” products on the market. Networking devices are a good example. If I were to market a networking device, I would do my best to emulate the Cisco IOS to the most minor detail. Even though the Cisco IOS is not intuitive (in fact, it is one of the most consistently miserable pieces of software I have ever dealt with), nearly every network administrator has spent a lot of time learning the intricacies of IOS. By emulating a really obnoxious system, you are actually working with existing user knowledge. You see this a lot in the *Nix world. Because so much of *Nix counts on pipes and redirects, applications tend to implement the I/O patterns of existing applications in order to be a drop-in replacement, even if they support their own (and probably better) I/O as well. If you are trying to break into an existing market, you will want to provide a UI that looks like the current king, even if you have a better one as an alternative. If possible, try to use both, with an easy way of switching between the two.

We also need to stop counting on the community to provide support for us. A huge temptation, particularly in the current economic climate, is to put some freeware wiki or forum software on a server, link to it from the Support section of the Web site, and expect that users will train each other. I am not saying this doesn’t happen or telling you not to set up a wiki or a forum. I’m saying that even with these tools, your staff will need to spend a lot of time on the wiki or forum and provide many (if not most) of the answers — at least until you get a number of MVPs on board and editing the wiki.

Also, I would like to see more new user and experienced user modes for software, particularly in super-complex applications. It would be even better if the software could seamlessly transition on a feature-by-feature basis. For example, once a user does Task A a few times without too much help, the software stops using wizards, but the first time a user does Task B, the software still has him in training wheels mode. I think this would be a great way to combine the promises of agent-based systems with the guidance of wizards and hands-on tutorials.

Finally, let’s get honest and drop the “easy to use” bullet point in our marketing materials when possible. Instead, we need to start putting in good tutorials and have our sales reps offer free (or highly discounted) training. What do you think costs your company more money: sending a trainer on site for a week to get new users up to speed, or not having a customer renew its license because no one ever used the system and then bad-mouth your software to boot? In the long run, it makes more sense to give free (or highly discounted) on-site training to big accounts and free online training to smaller accounts than it does to lose the upgrade fees.

In conclusion, software does not need to be intuitive to users who don’t know the field; and even for users who understand the work, complex tasks are going to have complex software. But, software developers need to keep finding ways to make sure that users get up to speed and can fly on their own.

..Original article appeared on MSDN by Justin James, this is a commented and edited version by analogkid..