New Maxims I learned from my latest project
….until newer Maxims demolish old ones:
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.
This entry was written by , posted on August 3, 2008 at 8:21 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Developing Great Software that Changes People’s Lives
Software development is not just about using technology to solve problems. Rather it is about offering tangible value. A good software developer hopes his or her effort will result in something that will be liked and used by someone. However the truth is that a vast majority of the software out in the world produces one common emotion in people – frustration.
I am considering two different types of software applications in this article. On one hand, we have shrink wrapped software written by some independent software vendor (ISV), and on the other we have applications written by the software department of a non-ISV to support the firm’s internal or external business processes. There are interesting differences between the two.
Lets consider the non-ISV software first.
In today’s world, the workforce is a moving target. Under such scenarios, software built to support internal processes are primarily of two types. Commercial Off the Shelf (COTS) or custom developed applications.
COTS is some software vendor’s idea of how your business might do its business with customization. Custom developed applications are a result of the workforce’s idea of how business must be done, or at least the idea of someone in the workforce.
If the workforce is changing, then present reality may not be real tomorrow. Hence by definition the internal systems will lag behind the changes occurring in the business place. The systems will not be proactive agents of change.
Inevitably, such systems will lead to frustration for people using them as well as people responsible for their upkeep.
For ISVs, its challenging to build something for a huge indeterminate audience. Using software essentially involves engaging in specific behaviors. To a large extent, the software will force the users to choose from a some specific set of behaviors.
This scenario by definition means change in user’s habits while interacting with the computer.
A great software product is a pleasure to use, irrespective of the goal you are trying to accomplish. Whether it is a customer service representative, recording the call or a commodity trader making a trade, the interaction should induce a sense of fulfillment.
Any repetitive task will eventually get boring. I do not know of any school of software which advocates boring programs. Yet, product after product are churned out barely making the grade. Why? It due to the fact that most software designers cannot imagine seeing their user in action, not just for a day but day after day of interaction with their software applications.
Why does the typical software application have the appeal similar to a mathematics problem solved on a page in a notebook? Add a new customer, edit details, update your account etc. Endless such programs are created causing emotional nausea among users.
Who among us knows of users that exclaim that the part of their job that they love is the opportunity to use the software to “Update Customer Detail” or fill endless computer forms without feeling stupid or someone telling them that “they do not know how to use the software properly”.
Fixed context problem solving approach.
Whenever a new application is written, it is from the viewpoint of a fixed domain, or fixed context. “We need a customer management application, Bob.” It should be able to interface with our multiple vendor systems, our inventory systems and our data mining applications. Great! Yet another piece of misery inflicted upon some wheel in the process workflow, forced to submit to the software’s dictates, entering information, producing reports, wondering why they didn’t take up the art as a career instead.
Instead, what if the executive were to say, we need a software application that makes it fun for customer service representatives to manage our customers, gets the job done in the simplest possible way, and actually makes it visible to the representative what impact did the actions make, while making it fun for them.
How about a trading application that actually allows me to become a better trader, not simply being the fastest trade and real time data enabler. Isn’t that my primary goal, be a better trader to be able to make more money? Now, such software would be truly revolutionary.
For most software developers, the computer and the person complete the equation in terms of the context. Well, we couldn’t be more wrong when approaching software applications. The entire domain of workplace is ignored in most software applications.
Where your customers are? Why are they there?
Are people talking to other people while using your software? Does the user have ten instant messaging windows open? What if they have to leave the work half-way and evacuate for a fire-drill?
A fifty field form submission is denied because the software does not like the way you entered your zip code. If zip code was absolutely essential wouldn’t you get all the letters back from the Post Office saying, “Thanks for making the trip to the Post Office and dropping your letter. Unfortunately, you forgot to write down the zip code, and you must complete this and drop the letter again.”
Writing an application for commodity traders to trade and an application for a point of sales clerk to complete a transaction, completely different scenarios, yet we can hear the argument, well only the user interface is different. Any good developer can write all the other parts for the application without any problems. But it is the whole environment which should guide the application development from end to end. We cannot isolate it to just user interface differences. Different environments, different needs and hence completely different understanding of how to build that software that could change people’s lives.
“It’s something that I cannot live without”. Is your software producing this emotion in your users? It’s important to ask this question again and again during development and subsequently as well. It will allow you to get rid of annoyances from the beginning. A lot of time I hear in development meetings, “Yes I know this will be annoying to the user, but…… “. How can we even dare to keep our users in contempt and follow such sentences by something that’s usually making our (the development team) lives simpler.
Such mentality results from partly the way technology progresses.
In the software marketplace, there are companies that are creating the mass production framework and technologies which hungry IT houses and ISV devour till the technology runs out of steam or something new comes along. A firm that I worked at, spent couple of decades building a large unwieldy infrastructure in one platform only to start abandoning it in favor of newer technologies. How do they expect innovation and a quick ROI if no proactive and adaptive frame of mind existed for over two decades?
There is a great lag between building software and keeping it exceeding user expectation on a continuous basis. Most software companies do a poor job f letting the customers even feed into the priorities and expectation for future version of the software. Imagine a company that sells you some software with a promise that within one and half month of your initial purchase and use, you will see another version of the same product fitting your needs more closely. Wouldn’t that be an exciting proposition?
Of course, you cannot let the users direct the innovation your company is producing, but can you at least take them along on the ride and let them feel that their concerns do matter and will be addressed. I find that lacking tremendously in most packaged software out there. Something of this nature would be a nightmare to implement with a hardware product (imagine buying an Ipod with the promise that within a month, they are going to give you a better version based on your usage of the product).
It is not only possible but must be done on a ongoing basis. Imagine a company that doesn’t leave you once your credit card has been charged. Wouldn’t this spawn off some new methodologies for building software packages. Millions of dollars are spent on creating, maintaining and running expensive software application. I cannot imagine how little of this money goes into an active feedback cycle upon deployment.
The truth is that we as users expect very little from software. Majority of users are not demanding. They submit to the whims of the software rather than be more demanding. Only eight percent of VCR owners know how to program it. Why? We simply found it too challenging and did not demand simpler ways to program it.
I don’t know how many developers I have seen who have no real desire or passion to put the product into the hands of real customers. They are well meaning people, but beyond solving a particular software problem, the interest wanes on seeing it in action in user’s hands. That’s someone else’s job in their mind. They could be building the most complex and satisfying application, but the desire to see it in action with happy end users is almost non-existent even in most supercharged teams.
An important piece missing from traditional software life cycles is production software experiences and its incorporation into software itself. I have seen lifecycles talk about maintenance and warranty, but critically lack talking about any real means to observe, record, incorporate feedback from real users into the software product itself. To this regard, even eXtreme programming talks about involving users into sequential iterations but all change must come from the embedded user or representative into the team. There is practice listed which states that software is never really done and is similar to an evolving species. (Survival of the fittest software theory)
How would users react to the fact that they are being delivered “unfinished” software. It would be the honest thing to do. Couple it with a guaranteed promise of evolving software. There is hope in such a tool. How many software vendors promise user input manner, but how hard is it for an average user to make the opinion known and see it actually make a difference. I see no standard way that organizations do product improvement based on user feedback.
Improvement is not the same thing as innovation. Innovation is thinking of something that does not exist yet and certainly we cannot delegate this important task to user feedback alone.
In the next part we will examine Innovation in greater detail. How we have progressed from text based interfaces to today varied means of accessing information and interacting with it.
Any software that needs long training phase and a lag phase before user becomes productive on it, is expensive from the business point of view. Rarely, the cost of user training is built into the costing of software development. A truer picture will only emerge when vendors start incorporating the cost of end user training into the total cost incurred by the buyer.
If a user can learn the core functionality of a product in less than an hour, we can say that the software package is pretty lean on its training needs. Lengthy training periods tend to overwhelm hapless users and they generally gravitate towards using simpler software.
Compare the way Microsoft implemented Search in the Desktop to the way Google searches the whole World Wide Web. We know who the winner is.
Pebble Drop Approach
Even a tiny pebble tossed into the calm waters creates a ripple effect. Similarly, each software product put out to the users has the possibility of creating ripple effects into how they interact with the computer and do their business. Unfortunately, most software development processes end once the software is deployed and do not harness the energy created by this ripple. A tremendous opportunity is lost here.
You have got someone to use the software written by you. But you have put little or no formal methodical effort into gaining insight by measuring and quantifying their reactions to the software.
Most software development processes ignore this part of the life cycle. It’s a mistaken belief that the software development life cycle ends with delivery of the product or lives on in a dormant fashion during the maintenance phase.
Indeed some organizations utilize the beta testing phase to gather feedback about the upcoming product and also glean information about bugs that have slipped their development cycle. The beta users represent a fraction of the actual users. Big decisions about the product are generally taken by this time. Beta users can suggest improvements however; it is unlikely their feedback has a major impact on direction of the product. Also majority of the beta users are using the product in a “testing” mode. They are usually advanced users and are likely to view the product from the point of view of a wider spectrum.
Why would I buy Version 1.0?
If the customer knows that you are coming out with version 2.0 soon why
should they bother looking at version 1.0. This continues to be a genuine risk area for hardware products, which cost more and not quickly upgraded or replaced.
A customer wants version 1.0 of a product, for the following reasons:
- The need outweighs the rationale of waiting for a better version
- Version 1.0 can be used in a different capacity upon upgrading
- Version 2.0 is cheaper to upgrade than buy anew.
- Many important needs are already fulfilled by version 1.0 right now.
This entry was written by , posted on December 24, 2007 at 1:00 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
How many clicks to get to what you need?
It was in the news today. CBS bought Last.fm.
I admit I had not heard of it before. So I decided to check it out.
Type in www.lastfm.com into the browser.
What strikes you on the home page is “Start Listening with Last.fm” I had no idea what it meant at the time. So I punch in “Diana Krall” looking to listen to one of the smooth creations from the Vancouver native.
It took me a single click. The Last.fm radio played on for hours.
What a satisfactory user experience! From not knowing anything about the website to being on it for hours.
This entry was written by , posted on May 30, 2007 at 7:11 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
How united.com uses webservices
Unexpected error messages with call stack, on a website reveal the architecture in use.
In the process of using United’s website, I ran across such an unexpected error. The call stack pieces highlighted in RED reveal, the use of struts and webservices. It also reveals poor programming since I found others who have run into the same error. I guess United developers have not read Joel’s article on getting error report from users.
Effective code review techniques would have caught and prevented such errors from being ever being displayed to the user. Want to know someone who can help you prevent such problems on your website? Hire CodeReviewers.
Flights Search>>Select>>Review>>Purchase
There was an error in processing your request. Please see the message below for instructions.
We are unable to retrieve flight information at this time. Please try again later.
CTSCHEDULEECONOMY-NON-REFUNDABLE **************************************##ERROR LOG ##**************************************##Service Invocation Exception: com.uls.servicebroker.ServiceInvocationException: ServiceBroker::Service invocation failed because of the following reasons com.ual.telescope.util.ServiceInvocationException: Web Service Invocation Error::SOAP Fault Occured at com.ual.telescope.ws.IBECommonServiceAgent.invoke(IBECommonServiceAgent.java:181) at com.uls.servicebroker.LocalObjectDelegator.invoke(Unknown Source) at com.uls.servicebroker.requestor.RequestDelegator.invoke(Unknown Source) at com.uls.servicebroker.requestor.RequestorAgent.invoke(Unknown Source) at com.ual.telescope.util.SBUtil.invokeIBEService(SBUtil.java:137) at com.ual.telescope.util.SBUtil.invokeIBEService(SBUtil.java:114) at com.ual.telescope.util.SBUtil.invokeIBEService(SBUtil.java:103) at com.ual.telescope.util.ServiceDelegateImpl.getFareSearchResponse(ServiceDelegateImpl.java:312) at com.ual.telescope.ui.shop.util.ServiceBDImpl.getFareSearchRS(ServiceBDImpl.java:572) at com.ual.telescope.ui.schedule.actions.SelectODCombinationAction.getSelectedItineraryForMultiCity(SelectODCombinationAction.java:178) at com.ual.telescope.ui.schedule.actions.SelectODCombinationAction.doExecute(SelectODCombinationAction.java:105) at com.ual.telescope.ui.shop.actions.BaseAction.execute(BaseAction.java:146) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421) at com.ual.telescope.ui.core.UIRequestProcessor.processActionPerform(UIRequestProcessor.java:535) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at com.ual.telescope.ui.core.servlet.LocaleActionServlet.service(LocaleActionServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at com.ual.telescope.ui.core.UIFilter.doFilter(UIFilter.java:169) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at com.ual.telescope.ui.core.SecureTokenFilter.doFilter(SecureTokenFilter.java:84) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at com.ual.telescope.ui.core.TelescopeMgmtFilter.doFilter(TelescopeMgmtFilter.java:121) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183) END Hidden error msg for debug–>
This entry was written by , posted on May 16, 2007 at 1:49 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Comparing Instant Messenger Softwares
A brief comparison of MSN Messenger, Yahoo Messenger, Google Talk, Skype
Typically an Instant Messenger user does the following activities:
1. Launch the instant messenger program (most probably its already running in the background and its launched using the Systray icon).
2. The person’s eye locates the buddy they want to talk with.
3. Click on the name and a message window pops up.
Up until this point, most messenger behave identically. This is the activity that I intend to compare. The big guys messengers have morphed into being many things, but I will ignore those for the purpose of this study.
User experience
The user experience sucks across all the major messengers. It takes me a minimum of three clicks to start a conversation. It is too many clicks. Compare this to making a phone call to your speed dial number. That’s two button pressed and this with an interface that is two to three decades old.
Also there is mouse movement between the clicks. I launch the messenger with a double click on the systray. The messenger launches at the previous location. My mouse pointer is still near the systray. Now it take me couple of seconds to move the mouse location to point to messenger software, locate the buddy and then use another click.
Hence, in the department called “imagination” all the major softwares get a big zero. Make it as easy as calling a buddy on speed dial and you will be a step ahead of competition.
The usability of the process of creating conferences with multiple participants is shaky at best.
Only MSN Messenger provides a slightly better way of adding participants to the conference.
Skype and Yahoo both use the unimaginitive form of listing contacts on the left and and an array of arrow buttons to move contacts into a conversation. A classic example of bad form factor being copied. I don’t know where this format originated, but I have seen early examples in the Microsoft client software such as Outlook.
MSN Messenger improves on this form by allowing search and clicking checkboxes. Lame, but an improvement nonetheless. I could not figure out how to create a conference in Google Talk.
Connection issues
Instant messenger softwares are anathema to most system administrators I have met. The big ones used to require punching a hole in the corporate firewalls to allow them to operate. Hence, a lot of companies disallowed the use of MSN Messenger and Yahoo Messenger by simply blocking the required ports. Let’s see how the different clients fare when posed with such problems.
MSN Messenger fares poorly when operating behind a firewall. It has no built in support to chat over the default port 80 using the HTTP protocol. It is an outright loser in this category. Microsoft came up with a pure web based client for MSN Messenger called Webmessenger. The usability is quite bad and the experience does not translate over from the regular client to the web based client.
Yahoo allows the user to switch from the regular chat port and protocol to using port 80 and HTTP. But this requires advance knowledge on part of the user on what setting will work. It would not have been hard for the Yahoo programmers to put in a feature which automatically chooses the correct option based on the users network settings.
Google Talk shines in this department. The reconnection works flawlessly, it uses port 80 and HTTP with ease and all of this is quite transparent to the user as it should be.
Skype “gets it” as well. It has a default port but also sets up port 80 in case the default port cannot be utilized. Again, transparent to the user as it should be.
Memory and CPU footprint on base system : Windows XP, 2 GB RAM, 2 GHz CPU
MSN Messenger core process msmsgr.exe used about 4.5 MB in the minimized state and goes upto 22 MB upon being activated. Launching an empty message windows added additional 5MB memory footprint. The additional process launched is livecall.exe which takes up additional 17MB before it does anything useful for you.
Yahoo Messenger
The monolithic YahooMessenger.exe takes about 45MB without a single open chat window. Upon opening an empty chat window, the footprint goes up to 47MB. I minimize Yahoo messenger and it remains steady at 46 MB. I wonder what all that important stuff is that the Yahoo programmers keep around no matter what.
Skype
Skype operates on two processes, Skype.exe and skypePM.exe. Minimized, Skype.exe takes around 49MB and skypePM.exe takes around 15MB. The total footprint comes to 64MB for Skype. Opening an empty chat window in Skype produce negligible additional footprint.
Google Talk
Minimized google talk occupies 21MB on my system. Opening an empty chat window does not increase that amount significantly.
Voice Chats
For comparison, I made calls from USA to China over various IM clients. It seems that the outright winner in this category is once again Google Talk client. The call quality was crisp and clear. The loser in this category was Skype. Yahoo and MSN are fairly identical in terms of call quality and rank in between Google Talk and Skype.
Disclaimer: this is strictly based on call quality comparison between USA and China. Call quality will vary based on the quality of the internet pipes between two end points.
One feature that sucks in Google Talk is the absence of Voice conferencing. There is a hack to do conference calls using Google Talk as explained here http://lpahome.com/call.html.
Plugins
Google talk is the only software which solely focuses on chat and keeps additional plugins at bay.
There is nothing to buy, sell, play games or any peripheral stuff. It seems to be keeping it simple as Google does with everything it creates.
This entry was written by , posted on May 13, 2007 at 12:53 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Defects as Cooperation Tool
Is it a reflection of the sad state of a team when Defects have to be used as a cooperation tool? I was recently involved in a very large project, comprised of around 600 contractors. What happens when a team this large is trying to move with each sub-team having its own priorities? Emails and voice mails get ignored. Cubicle drive-by’s are no longer successful in getting much needed attention.
Enter defect tracking tool. Submit a defect with Critical severity and it gets noticed. It gets highlighted at the triage meetings. Suddenly you get some attention. Project managers from the two teams begin a negotiation. Yes, you get your request fulfilled.
Now this is where things get interesting. Developer catch on to this pretty quick. Now if they want your cooperation, all they do is enter a highly visible defect.
Defect multiply. Defects lose their true meaning. Defects start getting reassigned. Now the company has to hire more consultants to keep up with the increased traffic of defects and implement more processes around “how and when to enter defects”.
Unfortunately in such large teams, the churn continues, and newer team members need to get trained in the “defect processes” and mistakes keep getting repeated.
The circle of defects continues.
This entry was written by , posted on December 5, 2006 at 11:12 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Do your error messages to users lie often?
Enter a search into Travelocity.com and search for a ticket from Bangkok (BKK) to New Delhi (DEL).
Here is what you are told:
What they might have said instead:
- Your search may have been beyond our comprehension and we are really really sorry about how we allow our software developers to lie in the error messages to the end users to leave you in a perpetually confused and exasperated state while using our programs.
This entry was written by , posted on November 8, 2006 at 11:19 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
User expectations
An actual quote from an actual user.
“During pilot I found, I really have to think big as far as where this project is going. The concepts and ideas behind this project are so suited to the frontline agent – we can search a client by name!!! “
This is 2006! There are still users out there who are subjected to software which does not let you search by name/place/thing. Google has been around for more than a decade.
Think about it. If your software does not provide a good search and ability to search on anything, it should have come with an expiration date of 1997.
This entry was written by , posted on October 19, 2006 at 9:42 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Printer friendly or plain eye friendly?
I find myself increasingly reading webpages in their “printer friendly” versions. Why do web designers think it is only printer friendly, i.e, saving ink? Even if ink was free and inexhaustive, do they really think people will prefer reading with all that clutter around the article?
I think what web designers need is a crash course in feng shui for web pages. Forget the ad revenues, the article’s point is lost as the eye tries to find the article, constantly being jarred by collisons with undesirable advertisement banners.
Bad mojo 101 is to break the flow of an article by inserting ads.
This entry was written by , posted on May 29, 2006 at 11:21 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Dude, Where’s my A drive?
My laptop does not have a floppy disk drive. I suspect more and more PCs do not ship with one. Yet the default configuration over the years has stayed the same. The drive letters start with C.
Why is it so?
Is it because over the years, in the typical windows user’s mind, the drive letter C became synonymous with where the files go. “A” was the special drive letter for the floppy disk drive.
Now that the floppy disk drive is becoming increasingly obsolete, the drive letter A is like a famous player’s jersey number: retired when the player retires.
This entry was written by , posted on April 7, 2006 at 4:12 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
» Next Entries