Growth in business puts scalability and performance demands on the software product that the company provides. These demands could take the form of site accessibility (number of concurrent users) and also number of exceptions that need to be handled by the system. Issues caused by increase in the load experienced by the product is well known (solved by load balancing, more servers, well written web pages such that it can load faster etc.). I want to touch upon an equally important scalability issue which is related to the number of exceptions and their frequency.
So what do I mean by an exception? I am not talking about exceptions from a software programming sense where the concept of try-throw-catch statements to handle anomalous situations in the code is used. Instead, I am talking about anomalous situations that can happen from a user or a business process perspective. Let me clarify more with a simple example.
Assume that our product does one thing – takes a full name, typed in by the user and splits it into first and last name before storing it into the database. Sounds very simple. If the user types in “John Smith”, first name = “John” and last name = “Smith”. Everything goes well but over time, until the system starts encountering names it had never seen before. Names such as:
- John Doe Jr.
- Safraq Ahmed Naveed
- B. Sunil
- Rajeev Kumar P.C.
- DÖRTHE Austerlitz
- Timo Gärtner
Let us take the second and third names in the above list. In the case of John Doe Jr., you don’t want the system to store the last name as Jr. and refer the customer as Mr. Jr. in the emails it sends him. In the case of “Safraq Ahmed Naveed”, what do you do with the name “Ahmed” – is it part of the first name or last name? Can your product handle special characters such as “.”, “Ö” or “ä” in the names?
Such problems should also be considered scalability problems. It may not cause site performance issues, but it could prevent users from using your product. I have used a very simple example to illustrate the issue. But in the real world, when such exceptions are encountered in the core business process, things can take an ugly turn not only because of the number of the types of exceptions, but more because of the frequency at which each of this happen. What used to be considered an edge case when you had 100 users could quickly turn into a mainstream use case when you have a 1000 users. In my career, I have experienced numerous such issues – all of them sound trivial – but that could have caused major impact on product usage. If you are running a consumer facing website, you may not even know about these use cases that are affecting your business because customers turn away when they find that the website cannot even handle what they consider a simple use case (one that applies to them, but which in your books is an edge case).
As software product managers, we need to be aware of these exceptions that may be raised because of expansion into a new international market, a new vertical etc.
Thoughts?
If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.
Great insight, Well these exceptional scenarios should be well thought by Software Product Managers during the phase of writing the Business Requirement Documents so that the development team can consider that during the product development phase.
Amit Jain
Gopal,
Good post. And let’s not forget that each exception has a life of its own and thus requires many other related exceptions in other parts of the application. So, for every exception that we handle during input, we must also handle during display, update, and in some cases, delete, operations.
-dave-