R.I.P – Steve Jobs. You influenced and touched the lives of a lot of geeks and non-geeks in profound ways! We are indebted to your inspiration.

Another interesting option is to use the open source library of jni4net. It is an interesting option because it allows for Java to interact with .Net classes via proxy generation and loads the CLR into the same process as the JVM.

I created my .NET API in C# 4.0 and used the proxygen.exe to generate the Java equivalent proxies of the C# API. The proxygen uses introspection to create the equivalent Java classes and compiles the new classes in C# and Java to create the intermediate layer.

Once this is done, you can reference the proxy classes within the Java program and the calls to their methods and then handed off to the equivalent C# classes.

There are some gotchas that one discovers with this approach. Not all classes on both sides have equivalency. For example, if a method returns a string from C#, its easily translated into a string in Java. But same is not true for Exception class. You cannot trap a call in Java in a try catch block and catch a .Net exception.

But for most implementations this library worked great.

Observation

It starts with observation. Observation should start with shadowing people, taking notes, taking photographs, and taking videos. This stage will establish the overall context for the problem solving exercise. The context will establish the end user as a human being instead of a faceless “user”. The problem has to be framed in the terms of the overall context. Instead of simply focusing on specific tasks, start with end user goals – broad and ambitious goals. These goals should guide the development of the applications throughout its lifecycle. What you shouldn’t start with is interviewing users on what they want. In my opinion, the interviews tend to focus on specific pains within the context of the existing applications. Interviews tend to generate ideas that solely focus on fixing the pains that exist right now. Instead, start by interviewing people who may provide the organizational perspective, and the departmental perspective. Once a broad view is established, dive into observation mode by shadowing the users in their day to day activities. Connecting the dots that emerge through this activities provide invaluable insights into what the users are trying to accomplish. Armed with still and video cameras – even something as simple as a phone camera or Flip recorder, you can start to piece together a picture of the user environment, their goals, their usage patterns, and how they interact with their computers, phones and other teammates.

Once you have had a chance to assimilate all the input, go back and interview with more specific questions to help guide the vision for the new application. However, don’t put the users in charge of the innovation. Solicit opinions on their pain points, but use these points as another source of input, not the sole guide for new features.

Ideas

Part of observing includes picking a diverse group of users to bring in as many ideas as possible. There is nothing wrong in copying ideas from other sources that have inspired you. However, encourage diverse and outlandish ideas. At this stage, the mission is to generate as many ideas as possible. Don’t underestimate how hard it is to go through a brainstorming exercise without overt criticism. Team may have the tendencies to start debating ideas as soon as they are generated. The art is to simply log these ideas to come back to them at a separate time. By separating the sessions for generating ideas and judging ideas, you can encourage lateral thinking in the first session.

Rapid Prototyping

Mocking up everything is the key. Ideas can come to life when mocked up and it helps in the narrowing of the choices.

Narrowing down the ideas

In this session, the objective is to focus on those ideas that are executable and the best ideas out of all the ideas generated in the previous session. This session is where the team can debate pros and cons of each idea and get a collective buy-in on what needs to be done. Involve end-users in helping narrow down the choices. Get the buy-in from the project sponsors and executives at this stage. Instead of just focusing on the screens, branch in role-playing the end-users and how “a day in the life of” scenario might work with the new solution.

Implementation

Implement in an iterative way and make it a point to involve the users at frequent checkpoints. Simplicity is hard to achieve. Keep focus on the end user goals and demonstrate the partial product on a frequent basis. Solicit additional user experience feedback and plug it into the enhancement queue.

From the CNN article, “Money, it turned out, was not an object for Hulu. In May, Providence Equity Partners offered a cool $100 million for a 10% stake – giving the nascent operation an astonishing valuation of $1 billion.

But the secret of Hulu’s initial success – the thing that made believers out of the skeptics – is the power and simplicity of the website itself. Hulu’s creators focused with almost obsessive attention to detail on the user’s experience.”

So how do companies become great and create ground-breaking products? The answer partly lies in the underlying philosophy behind the organization.

Here is an excerpt from “What defines Hulu”: “We are passionate in our opinion that the world has long since exceeded its quota in the mediocrity department.

We believe our professional calling is to deliver quality. And not simply run-of-the-mill, five-star quality. For Hulu, nothing less than brain-spray awesome quality* will do, down to the finest detail. This atypically high quality bar leads us to sweat every pixel, every second of transcode, every customer.”

So when you are making your next product, ask yourself this question: what is the definition of quality for you? Will your product get a response like “My first hulu experience made my head explode in a brain-spray of awesome.’

Second, all untrapped exceptions must be logged as defects automatically by the exception handling code. Now how do you determine if the same defect is already logged and prevent a flood of the such defects?

One easy way to uniquely identify a defect is Line Number of the Code. Every time an exception occurs it originates at a certain line of code in a certain class. Thats the unique identification.

Before opening a new defect, the bug tracker should check if a defect exists with same class and same line number. If it does exist, then the new event gets appended to the existing defect instead of creating a new one.

Want a bug tracking/project tracking software that already does all of the above? Try FogBugz.

Imagine you are building a user interface for the Army, for a battle decision control system, where pushing wrong buttons could result in loss of lives. Now rethink the interface from the army commander’s perspective – how would you present this information. Suddenly you become sensitive to throwing more drop-downs, text boxes and buttons on there. I think you have started to see the picture of the impact of your user interface on the day to day life of the end user.

How do we innovate our user interfaces. Certainly not by “asking” the users what they would like. Innovation is creative solutions to user pains that may come by “observing” the user, their context and their larger world in general. It cannot be accomplished simply by “asking” the user. “Why” is a friendly weapon in an innovator’s arsenal to determine what the user motivations are, and what the current pain points are. Of course, it takes creative software development team to convert the idea into working software that resembles something that understands the user. This is why it is my firm belief that great software can only come from teams that have user empathy at the core of their effort, whether their contribution is that of a requirement writer, designer, developer, or tester. If every single person on the team cannot envision their product in the hands of the eventual user, they will not be able to build a very effective piece of software. Every small decision that a requirement writer, developer or tester takes has eventual impact on the usability of the software. It is virtually impossible to make software development “factory like” work with specifications, in my opinion. The states that the executing code be in at any given moment explodes once developers start converting requirements specifications into executable code. At this point, developer make conscious decisions on the behavior of the software, sort of “reading in-between the lines” of the specifications. How good the product will end up to be will depend on what developer wrote and what the tester interpreted as the requirement to be.This is as much art as much it is science. The quality of your people will determine the end result.

So we owe it to our teams to teach them to write software with less interface and coming up with innovative ways to solve the problems that the users don’t know need solving yet.

Let me illustrate this transition by hypothetically taking away some of your favorite thick client applications. Imagine your boss comes in one day, and tells you “We are getting rid of all thick client applications because this is 2008 and we will be moving all application to web based interface. So tomorrow you will be receiving new computers that will only have a web browser (kinda like the machines you see if you ever used Denver Public Library computer).

No more MS Word or Excel or PowerPoint or even Outlook. Eclipse? ha! use an online text editor. Instant Messenger? use web based chat.

Just imagine going one day by just using web based versions of your favorite applications. Not a pretty picture. Why is this? Many reasons, but primarily because most web based applications do not provide the same user experience as a thick client does. That and our need for speed. Many web based application still perform poorly compared to their thick client cousins.

Web usability guru Jacob Nielsen talks about response times highlights pretty interesting facts:

1) 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

2) 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

Jacob also provides some useful advice on how to design the interface so as to make it more responsive to user needs. Notice that there is a difference between actual response times and perceived response times. What matters to end user is perceived response time.

So when rewriting an existing thick client application to a web based interface, these challenges must be kept on top of list or the application will be what Outlook for Web Access has become. A nice to have alternative that you will use only if Outlook thick client is not available.

Consider a call center customer care application. If your boss comes to you and says “I need you to plan a new call center. Let me know how many people will you need to answer calls and manager those who are answering calls”, you may naturally ask questions such as “how many calls do we receive on average and peak times?” and “what types of calls are coming in?” and “how long does it take typically to get through a single call?”. Since you are a math genius, you figure, you will do some math and take number of calls on an average day, multiply by time it takes to handle a single call and divide by 8 hours.. and ta da you should have a magic figure of how many people you need. So some years pass by and existing application must be replaced with a new application. How is your life as a call center manager going to change?

Is the new application making the customer service representative take longer to get through each call or its making their life easier by taking less time than before? Is the application high friction and making the life of the customer and the service representative much harder?

So how do performance and usability play into this? Performance testing in isolation is only step one. Step two must be a combined usability drill during peak load conditions to validate that the new application indeed makes life better.

If you were the customer paying for the new application, wouldn’t you expect this validation?

1. Time taken to do reviews(all artifacts – requirement specs, design spec, code, test cases etc)
is directly proportional to application quality and inversely proportional to number of defects.

2. Definition of “Done” = QA executes the software with acceptable types and amounts of defects.

3. “Working code against tiny database” != “Working code against production size database”
or “Tested against tiny database or tiny files” != “Production Ready Application”

4. Cross vertical understanding by developers is directly proportional to code quality in a given vertical.

4a. Business understanding by developers is directly proportional to Quality of software.

5. Agile development != Automatic Quality and Success
or Speed of agility is directly proportional to Risk of Architecture shifting requirements discovered late in the cycle.

6. Not integrated software = Not working software.

7. Nightly Trunk Building, Deploying and Smoke Tested = Stability.

7a. Nightly Master Build = Successful Compilation + Successful Unit Tests + Successful Integration Tests + Successful Deployment + Successful Smoke Testing

8. Number of Branches is indirectly proportional to Stability of Code.

9. Duration of Branches is indirectly proportional to Stability of Code.

10. Developer Estimate != Commitment

11. Contract = Commitment

12. Probability that Estimate in Contract is in vicinity of accuracy = 0.

13. Probability that Contract will be altered as project progresses = 0.

15. The usability of a product is directly proportional to the hourly salary of the intended end-users.

16. Defect Fixing – Root Cause Analysis and Addressal = Lost Opportunity for better quality.

17. Probability of defects slipping in is indirectly proportional to build, test, deploy speed.