Treat Your Customer As A Business

This is an attempt at making requirements elicitation more efficient and to help get the bigger picture. Software, whether it is explicitly said or not, makes an impact on the business it is being used in. Value of the software is driven by that magic number provided by the Return On Investment (ROI). So, even if the customer is an individual treat him/her as a business. This can bring out the standing and significance of the software in the business.

What business are we talking about?

A software is typically looked at as a solution to a problem. This problem lies in its own problem domain which lies in the business. The business involves much more than your customer. It involves your customer’s customers, your customer’s vendors, shareholders, other stakeholders and of course your customer’s competitors. A business also plays are role in the entire supply chain. A business interacts with its customers, interacts with other businesses, probably with customers of its competitors. A business is a system with other subsystems in it, in which people are involved. Any software, whatever its scope, used in any part of any subsystem has the potential of making an impact on the entire system and eventually making an impact on the supply chain. If the software does not make a difference to the entire system, then why invest in it? Accounting department of a company can want an accounting software. But if using it does not affect the business of the company, is it really useful? Meaning of usefullness can change when you consider this business.

The business gets its ROI only when it can leverage the software to improve its standing in the entire supply chain. This can be direct or indirect. This business is a different animal than your customer. It is affected by more factors, it runs under more restrictions and it also affects more factors. To be able to get a handle on these factors, it is imperative to understand and treat your customer as a business.

What factors are we talking about?

Business, being a generic term, lets look at its generic factors.

Localized Optimization

The software affects the peripheral businesses or subsystems, along with the problem it is supposed to solve. A manufacturing unit can improve efficiency of the production department, however, this efficiency affect the business only if it propagates through the delivery systems. Sometimes, an improved production department can stock up the inventory system which can turn into a cost centre. The production efficiency is also only as good as the efficiency of the business providing the raw materials. If this is realised earlier in the stage appropriate solutions can be identified for the possible problems caused by localized optimization.

The real benefit lies in overal optimization, which looks at the bigger picture and finds solution in the bigger picture. This factor can help us in tying features of the software to benefits to the business, without the middlemen of departments or localized cells. Somehwere there also lies the answer for ROI.

Current Investment

A business inherently involves people. With people come their skillsets, their ability to learn and their questions. Software is not only about development, it is also about training, it is about making the users use the software in a right way. This can happen only if their skillsets are considered. The business perspective highlights this factor which is missed a lot of times.

People are a form of current investments. There can be many others like using existing real estate, expertise and even softwares. A software initiative can consider to use them instead of requiring new investments.

Growth and Dynamics

A business wants to grow, wants to scale up, wants to do more things. The software should not be an impediment. There is no way of predicting future requirements, but the software design can include provisions for growth and scalability. Website for a newspaper, that has a thousand readers today, but expects five thousand in future, should be able to handle this scalability. An overhaul of the website for this purpose can turn about to be too expensive. This can be achieved by querying the roadmap or vision or goals of the business.


Last but not the least, a business operates under a variety of restrictions. Timelines, financial budgets and even the market trends factor into the various tasks that a business carries out. These restrictions percolate to the software initiative. Eventually, each of the restrictions on the software project are born out of some real-life business restriction. This realization can help us understand the impact of breaking any one of them. It can make us look for a better solution that can comply with all the restrictions. If complying with all is not possible, it can at least give us time to prepare for the eventuality.

Still Be Personal

Treating the customer as a business sounds impersonal. Being personal does not mean involving personal problems, but giving personal attention to the customer. Labelling the customer in a category of other customers and giving a generic treatment is impersonal. Every customer, every business and every project is different. Realizing this, treating them different and giving them personalized solutions is being personal, and this can happen only when you can deliver something that brings in positive results for the entire business. And this can happen only when you treat your customer, not as an individual, not as a group, but as a business.

Technorati tags:

Copyright Abhijit Nadgouda.


A Good Developer

Martin Fowler at ThoughtWorks says:

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I’ll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

Bingo! The critical thing to realise is that software development is less about the software and more about the customer and his/her business. No amount of technical expertise will make the software work if the workings of the underlying business are not understood. Customer Affinity is about working close with the customer to understand the problem. And this creates the need for agility in the software development.

Business is a multi-dimensional entity, which is affected by multiple factors. It becomes imperative to discuss with the customer first hand to comprehend something like this and then automate it. Requirements gathering is not as much about interviews as it is about discussions. Interview is inherently a question-answer session, whereas a business, and hence software development is a field where you can have multiple answers to a question from different perspectives. Selecting the best one is an effort to talk to all the stakeholders involved, bring them on a common ground and then discuss with them. Like Martin mentions, most of the times the developer learns about the business by collaborating with the domain experts. In some cases a software developer ends up contributing a feature to the solution. An example of this is during a project of article management, the feature of related articles was something that came from us, the software developers.

The popular reason I have seen for this to not happen is that the software developer is too scared to talk non-technology with the customer, and the customer to talk technology. The ideal thing would be if both of them discuss the solution. Isn’t it the solution that we are really looking for? Discuss the solution, and let the expert handle the details of corresponding domains.

The developer should also be able to rationalise the requirements and then justify the design against them. At the end of the day, the software developer should be able to solve the problems with the designed software. I have seen lot of designs fail when they cannot assign purpose to the design. The best way to do this is a direct customer developer interaction at various levels and at multiple times during the software development project.

It is equally important that the customers realise that a customer cannot just wash off hands from the project after providing information. The customers should identify their problems, but also keep an open mind in the discussios and expect contribution from the other side of the table.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Web, JavaScript And Security

JavaScript is now main stream, thanks to the popularity and extensive acceptance of AJAX. In fact, AJAX is considered to be a core part of Web 2.0.

Acceptance of a technology by the industry has been a subject of its scanning under the security microscope, which has caused delays in accepting new things. JavaScript seemed to follow the same road, unless AJAX came around. AJAX gives this wonderful capability of behind-the-scenes requests to keep the web page dynamic, and make it more userfriendly and attractive to the user.

JavaScript has matured, however, not its security model. JavaScript opens doors to browser-based attacks. This may sound as the same old crib against scripting, but delve a little more in the side-channel attacks and the real danger surfaces:

“We have discovered a technique to scan a network, fingerprint all the Web-enabled devices found and send attacks or commands to those devices,” said Billy Hoffman, lead engineer at Web security specialist SPI Dynamics. “This technique can scan networks protected behind firewalls such as corporate networks.”

The popular mode of attacks today is by exploiting the different browser vulnerabilties. But, JavaScript can now get inside your network. Once inside the network JavaScript can attack any IP enabled device, including server, routers or printers. This is no more limited to the user’s machine, the danger expands to the entire network, including the corporate ones. Along with the Web 2.0, these attack strategies too will mature and the new websites can end up being haven for the hackers end up in another cat and mouse game.

The good thing about seamless integration with scripting turns into evil as the user will never know if his/her machine or network has been attacked or not. Unless, the user is knowledgable enough to set the security to the right level. Every computer user cannot be expected of knowing the JavaScript vulnerabilities or keep his/her antennas on for staying alert to JavaScript problems. It will beat out the productivity, which is the ultimate purpose of using computers.

Security makes it difficult

Various new web frameworks have come up which allow easy AJAX integration and build sites quickly. However, if the different vulnerabilities are considered, it is not easy any more. Consider the cross-site scripting, cross-zone scripting or the new dangers of JavaScript.

Security does not figure in many applications as one of the primary requirements. Either the client is not very interested or even if i is considered its cost might turn it into a good-to-have feature. Many a times, a project starts with a reduced scope where the security is not urgent and is ignored. However, the project evolves with time and then it is more difficult and expensive to make it secure. Today, Web 2.0 is headed that way.


Disabling JavaScript is the instant reactive solution to this problem, however it not practical. Today scripting is ubiquitous. The solution lies in preventing hacks not avoiding scripting. Incorporating security in the JavaScript design involves changing its model which entails changing almost every web application today which might take time. The solution has to be a two-way approach – a policy based solution and an effort to improve scripting environments.

Clients, designers, developers, browsers – the whole industry should accept policy based decisions to avoid hacking. It would be perfect if there would be a way of differentiating between good-intentioned and malicious code. Maybe there can be certifications to certify non-malicious code. Ted Dziuba presents a novel approach, though a little critical, by differentiating between a document and an application.

Indeed, JavaScript is useful when the main purpose of your work is an application. When you are presenting information, however, there should be no JavaScript between the user and that information. As I said earlier: we as developers have an obligation to the rest of the internet to classify our work as either document or application. So, the next time you think that having your entire web site as one page with AJAX controls, please, think of the crawlers.

Software creators should focus on security along with the quick and easy rush. Make the web site secure and safe along with making it dynamic, interactive and flashy.

The industry needs to hold back a bit, focus on the JavaScript vulenrabilities, prepare for it and then get gung-ho about it.

Technorati tags: , , , , ,

Copyright Abhijit Nadgouda.

Design Efficiency

Aza Raskin at Humanized has written an interesting article about design efficiency. He provides a quantitative way of measuring efficiency of the design.

Of course, efficiency cannot be absolute, but it is an indication enough.

The most important property of efficiency is that it lets you know how you are doing in the grand scope of things. If an engine has an efficiency of 10%, you know you can do a lot better. And if an engine has an efficiency of 98%, no matter how brilliantly you design, you won’t be able to improve it much.

Efficiency lets you know when you can stop looking for a better design.

Efficiency can tell you when you need a new inspiration.

A benefit of the efficiency is the focus on big picture and to be able to consider all the different aspects, and consciously ignore the ones that don’t matter. It is extremely important to consider only the factors that fall within the scope, otherwise it leads to the wrong direction or a wastage of effort. It is also important to measure the efficiency from the user’s perspective.

Aza includes on the quirks I love to hate – the desktop:

The Desktop.

Think about it: if you want to write a letter, how much of the letter do you get written on the Desktop? None. If you want to look something up in Wikipedia, how much of the searching do you get done on the Desktop? None. If you want to perform a calculation, how many numbers get crunched on the Desktop? None!

The time you spend fiddling with your Desktop to get where you need to go to get your work done is entirely wasted. You get no work done on the Desktop. It has an efficiency of 0%.

Clearly, there is a lot of room for improvement on the Desktop. A lot. We think we have a solution so keep your eyes peeled next month.

In my opinion, the desktop should play the role of an interface to the computer. Whether we are dealing with applications or activities is something that the desktop should convey and should be customizable according to the user’s expertise.

Efficiency is important, it determines how much to design or sometimes enables innovations that break the conventional ways and leads the pack.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Software Development Is Like Running A Restaurant

Software development is alien to a lot of people and explaining it in technical terms really makes it worse. So, we use metaphors. Lidor Wyssocky says it is like a broken telephone. And there have been many more attempts, to compare it with the construction industry with similar roles – architect, designer, developer (?) or manufacturing. Here is my attempt.

Software Development Is Like Running A Restaurant

This is the closest metaphor I can find today. To serve the customer that satisfies his/her needs, to provide tasty servings that are unique enough to make you standout but still within the realms of expected quality and standards is what we both do. It requires a delicate balance of creativity, engineering, understanding of the customer’s needs and other constraints like time and budget.

The waiter has to not only provide the menu but also gather what is it that the customer is looking for. Most of the times the customer does not what to order because he is not familiar with the culinary skills. It is upto the waiter to get the information, and help the customer choose a course. The course is split into parts and include the condiments like wine or starters are part of the order, they are the ones that complete the experience.

Once the order is taken, it has to be given to the kitchen so that the chefs and use their knowledge and skills to work on the order and create something that will satisfy the customer. There should be good information flow and collaboration between the dining area and the kitchen so much so that the customer feels that they are one and the same. The chefs have to be careful to select the right ingredients and the right combinations and the right proportions. Any change in this will cause a change in experience to the customer. However, the chefs cannot have all the time in the world, they have to serve before the customer gets frustrated waiting for the food. If the customer is hungry it might call for a different order or an expedited preparation. The decision involves not only the chefs’ skills but also the needs and constraints of the customer.

In the kitchen it is a different ball game for the chef. He has to design the dish, along with managing and motivating his team to complete the dish in time with a certain quality. This calls for samplers, tasting (or testing), good people management and good communication. Typically the kitchen ends up serving more than one customers which requires good estimation and scheduling skills.

Sometimes it makes sense for the chef himself to come up and talk to the customer. A lot of times problems raise their ugly head, like lack of seating or local problems like loss of electricity or disasters in the kitchen. The restaurant needs to have a good manager who can handle these situations and keep the customer abreast. A good restaurant will like to take the customer’s feedback and suggestions, and factor them in their improvement. Unless this experience is good, the customer is not going to revisit the restaurant or suggest it to his colleagues or friends.

Last but not the least, it is important for the restaurant to realise that every customer is unique. The same course need not satisfy all the customers, the restaurant has to consider and treat every customer individually and serve individually.

All this has to happen while making sure that the customer does not feel that he has been handed an expensive deal. The restaurant should still keep making money, and hopefully good profit so that some of it goes back in improvements of the restaurant and stay updated to the trends. The restaurant has to, in the background, make sure to manage the raw materials and manage the vendors.

And you see all kinds of restaurants – from the five star ones where there is a hierarchy of waiters to the ones who are affiliated to hotels and lodges to the three star ones, the Thai, Italian, Mexican and such specialized ones to the mass caterers to the diners to the ones that are part of a food court in the malls to the ones who give take-aways to the ones on stalls on the road.

It Is Still A Metaphor

Having said all this, running a restaurant is still a metaphor. The biggest difference is that the software development is about automation that is expected to serve for a longer time. This is what makes it complex, it is expected to serve for a time in which the customer’s needs and requirements keep changing.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Interview With Usability Guru

Usability guru Jakob Nielsen was interviewed (via Ajaxian) on usability and its relation to advertising.

One of the things that come out of it are the applications of AJAX.

It’s important to remember that most web sites are not used repeatedly. Usually, users will visit a given page only once. This means that the efficiency of any given operation takes a back seat to the discoverability and learnability of the feature. Therefore, interaction techniques like drag-and-drop should almost never be used on web sites. Instead, focus on showing a few important features and making them accessible through a single click on a simple link or button.

Some business sites that are used repeatedly include features for approximating software applications. Online banking comes to mind, and I can easily envision a design that enables the user to see the front or back of a check through an AJAX technique on the account statement page, instead of going to a new page.

Do we simplify or in fact complicate the interaction by adding advanced features? This is a question to consider whenever any feature is being implemented. Ideally, any feature should be implemented such that it supports maximum number of platforms and browsers without any third party plugins.

He also mentions the classic problem of doing technology for technology’s sake. It is important to realise that the software being developed is for the customer and no one else.

Remember: just because you love technology and advanced features, it doesn’t mean that your customers do. They just want to get in and out without worrying about your web site. So take it easy on the features.

I agree in entirety that adding features or programming tricks turn into just gimmicks if they are not targeted to be used. One of the best ways of identifying the required features is to identify their usage – who, why, how and when. If there are concrete answers to these questions that feature becomes an important one. Rest fall in the category of gimmicks. Every Web 2.0 company talks about AJAX today, but how many talk about using it for improving the website?

He also talks about usability and conversion rates. Usability is an important factor, it makes the user comfortable and that drives traffic. Advertising can get a user to the website, however the conversion to a frequent user will depend on the content and how usable the website is to consume the content.

Technorati tags: ,

Copyright Abhijit Nadgouda.

Simplicity and Side Effects

Alex Bundardzic has written a nice piece on achieving simplicty when developing software. He also points to the post on 37 signals on similar lines. Like other times, I have commented on Alex’s post, but later I thought that this topic warrented a post here.

What About Flexibility?

However I feel it is a incomplete without its possible side effects. The biggest one being lesser flexibility. Of course flexibility itself can be the evil sometimes, but design of any software is (or should be) done with enough flexibility. One of the most classic divisions in the Linux world is over Gnome ‘s simplicity and KDE‘s flexibility. Another instance is the popular messenger gaim opting to reduce the number of preferences to make it simple.

Reducing the necessary flexibility can kill the application and sometimes its usability. There are logical sets of customization units that can need to be equally flexible, e.g., to let the user select a font, the change of typeface, font size and the decoration all has to be provided in a word processor. Howerver, this flexibility might not be necessary for writing posts on a blog as the presentation is controlled by the theme.


What is required is to keep a balance between enough flexibility and possible simplicity (through usability). Beyond this balance these folks are ready to wage a war with each other. One of the ways I like to achieve this balance, in case of preferences, is to provide default values. Allow the user to make fewer choices by providing default values for things (s)he does not care about. So that the other (s)he will have more or lesser choice. Using the combination of flexibility and default values you can provide different levels of choices to different users.

Another way can be to provide themes of preferences that users can choose. Something similar to desktop themes or blog templates and themes. The user profiles should be used to identify the different combinations of choices to package as a theme.

Documentation A Must

I think this is the biggest effort cost of providing flexibility. Without supporting documentation it is just another bundle of controls and dialogs for the user. Usable and extensive help can provide the necessary education to the user about the application.

I am a believer of the Less Is More paradigm, but it is imperative to decide on how much less. This will by and large be dependent on the user profiles the application is expected to serve. Over the long term a software with the right formula of flexibility, simplicity and functionality will be successful. However, it is important to see that the formula will not be the same for every project, it will vary and will depend on lots of factors. It should result in a software as simple as possible with enough flexibility to provide the expected functionality.

Technorati tags: ,

Copyright Abhijit Nadgouda.