April 24, 2012

Are you settling for mediocre solution?

"This is just an Intranet application"
"People would hardly use this feature"
"There will be only less than 100 users for this site"
How many times have you heard such arguments during discussions. I have heard similar comments many times and have also made such comments myself. I have just realized that I had been convincing myself with these arguments to settle with mediocre solution for some of the "interesting" problems.

There is one particular requirement in my recent project where I faced similar situation.

Initial approach:

We came up with some sort of a "conventional" solution to address a requirement. This approach was not very clean as it had couple of issues
- We were violating the general rule of the site to support browser back/forward actions
- We were using URL query param to hide/show few links
Even though we had these issues, I was convinced with the solution and wanted to go ahead with that. I had "strong" reasons (read as excuses :) ) for the same.

Reasons (Excuses):

  1. This application doesn't deserve "advanced/complex" features / This requirement is unwanted: This project has only 100 end users. We don't have to spend much time on building this "advanced/complex" features just for these users. I am not convinced yet that this requirement is needed.   

  2. Just enough design/This is an exceptional case: The conventional solution for this requirement works and we don't have to spend much time on this. We can violate the back/forward support for this requirement as it is an exception case.

  3. Story points: It is only a 2 (S/something) pointer and we can't spend much time on this story.

  4. This scenario would never happen: NO user would be performing these sequence of steps (Even though I don't have any metrics to support this claim)

Luckily in my project, all mediocre/conventional solutions were challenged and the team was not convinced with my reasons. We had to come up with a better solution.

When we spent a little more time without thinking about excuses, we were able to come up with a better/cleaner solution. This out of the box solution met all our requirements and also made us feel good about. All it required was that little push from others and a little time to overcome the mediocre solution mode.

Now when I look back at my "strong reasons", everything seem to be flawed:
  1. I could not see the difference between unwanted feature and differentiators. Without these features (related to usability), our site would end up being mediocre. It would not be able to get more users on to the system.
  2. Looks like my notion of "Just enough design" also had "taking exceptions" for granted. In this particular case, I had already convinced myself that this requirement can take exceptions (like not supporting browser forward/backward) without exploring some more possibilities.
  3. Story points are just a metrics to track progress and it should not be used for killing innovation/thinking out of the box.
  4. I think, I had made up the "scenario would never happen" argument to support my "this is an exception" argument.

Lessons learnt:

Mediocre solutions come into existence only by convincing ourselves that it is the right thing to do in THIS  case/application. All it needs is a little more time to come up with a better alternative.
Team members should be constantly challenging each other on mediocre solutions in order to build a great product. It also helps the team to improve their technical and problem solving skills.

Are you coming up with excuses or a better product?


  1. On the other side of the coin, i have been in circumstances where the people challenge to match the ideal case... too much of perfectionism will certainly kill creativity... being judicial on where to stop, iteratively getting it perfect seems to be a better approach to me as it buys me enough time and feedback from the users...

  2. Nice post Venky. Adding to your points, I would say that interface design is the 'victim' of so-called 'delivery' most of the times. Whenever there is a need to deliver more points and hence to cut down cost, design ends up being the first choice. Rather, design is something that should not and cannot be compromised. On an extreme note, from a design perspective, implementation is just a way of 'accomplishing' the design (developers have every right to think it the other way :-)).

    Regarding the target users of the product, the numbers should never matter. In fact, a 10 user application might need the most thoughtful design and usability depending on the importance of tasks they accomplish using it.

  3. I am very happy to discover your post as it will become on top in my collection of favorite blogs to visit. seo expert

  4. Great Article. Thank you for sharing! Really an awesome post for every one.

    IEEE Final Year projects Project Centers in Chennai are consistently sought after. Final Year Students Projects take a shot at them to improve their aptitudes, while specialists like the enjoyment in interfering with innovation. For experts, it's an alternate ball game through and through. Smaller than expected IEEE Final Year project centers ground for all fragments of CSE & IT engineers hoping to assemble. Final Year Project Domains for IT It gives you tips and rules that is progressively critical to consider while choosing any final year project point.

    Spring Framework has already made serious inroads as an integrated technology stack for building user-facing applications. Spring Framework Corporate TRaining the authors explore the idea of using Java in Big Data platforms.
    Specifically, Spring Framework provides various tasks are geared around preparing data for further analysis and visualization. Spring Training in Chennai