I find myself using the following heuristics:

• Can I quickly comprehend what is going on?
• Do I need to parse the method’s code more than once?
• Does this code violate the Single Responsibility Principle (SRP)?
• Is the Cyclomatic  Complexity of this code more than 5?
• Does this method have more than 7 +/- 2 (Miller’s Magical Number Seven) concepts?

More details: Long Method Smell: When is a method too big?

My friend Srihari has been working on a great project called Systems We Make. His goal is to provide a consolidated catalog of various papers/articles about building large, complex, distributed system.

He personally searches, reads through and filters each the papers for you. This is awesome!

Please support his initiative.

Technical Debt is any technical issues slowing down the project due to hasty (short-sighted) decisions made at an earlier point.

All of us make bad decisions, but not fixing them and just differing them really leads to bigger problems as these issues have a snowball effect.

Technical debt can be introduced at various levels:

• Code smells is the most obvious one,
• But things like lack of (or poor) automation,
• poor choice of tools,
• fragility in the development environment
• and so on

can also contribute to technical debt.

Most software organizations today suffer from what I called the “Inverted Testing Pyramid”. They spend maximum time and effort building end-to-end GUI test. Very little effort is spent on building unit/micro tests. Hence they end up with majority (80-90%) of their tests being end-to-end GUI tests. Some effort is spent on writing so-called “Integration test” (typically 5-15%.) Resulting in a shocking 1-5% of their tests being unit/micro tests.

Why is this a problem?

• The base of the pyramid is constructed from end-to-end GUI test, which are famous for their fragility and complexity. A small pixel change in the location of a UI component can result in test failure. GUI tests are also very time-sensitive, sometimes resulting in random failure (false-negative.)
• To make matters worst, most teams struggle automating their end-to-end tests early on, which results in huge amount of time spent in manual regression testing. Its quite common to find test teams struggling to catch up with development. This lag causes many other hard-development problems.
• Number of end-to-end tests required to get a good coverage is much higher and more complex than the number of unit tests + selected end-to-end tests required. (BEWARE: Don’t be Seduced by Code Coverage Numbers)

• Maintain a large number of end-to-end tests is quite a nightmare for teams. Following are some core issues with end-to-end tests:
  • It requires deep domain knowledge and high technical skills to write quality end-to-end tests.
  • They take a lot of time to execute.
  • They are relatively resource intensive.
  • Testing negative paths in end-to-end tests is very difficult (or impossible) compared to lower level tests.
  • When an end-to-end test fails, we don’t get pin-pointed feedback about what went wrong.
  • They are more tightly coupled with the environment and have external dependencies, hence fragile. Slight changes to the environment can cause the tests to fail. (false-negative.)
  • From a refactoring point of view, they don’t give the same comfort feeling to developers as unit tests can give.

Again don’t get me wrong. I’m not suggesting end-to-end integration tests are a scam. I certainly think they have a place and time.

What I propose and help many organizations achieve is the right balance of end-to-end tests, acceptance tests and unit tests. I call this “Inverting the Testing Pyramid.” [Inspired by Jonathan Wilson's book called Inverting The Pyramid: The History Of Football Tactics].

In a later blog post I can quickly highlight various tactics used to invert the pyramid.

Simple Design and Testing Conference is an all open space conference providing software practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches.

At this conference you’ll meet real, hands-on practitioners interested in peer-to-peer learning and exploration. We strive hard to avoid fluffy, marketing talks and other non-sense.

• What: Open Space Conference on Simple Design & Testing practices
• Where: Skills Matter eXchange, London, UK
• When: 12th-13th Mar 2011
• Who: Software Practitioners (Developers, Testers, UX Designer…)
• Cost: £50.00, also (Position Paper required!)

SDT Conf 2011 is our 6th annual conference and for the first time in Europe. Check out the past conference SDT Conf 2006, 2007, 2008, 2009 and 2010 details.

Register now…

On many applications I’ve worked on, Authentication is a big pain.

• Usually its an usability hazard. (No one likes to authenticate themselves over and over again)
• Since its a cross-cutting concern and every application has some special logic for authentication, we spend way too much time hand crafting the best strategy to implement and test it to make sure our application is secure.
• When you have multiple applications and you want to implement single-sign-on, the pain just exponentially amplifies.
• On high scalability apps, Authentication (session validation) can be expensive from performance point of view

In the search of simplicity, I’m wondering if there are alternative techniques to implement authentication on certain types of applications.

One thought comes to my mind, which I’m curious to try. I’ll start with a very specific example and then expand it to other applications.

While building web applications in the category of social networking or eLearning or some other category, where retrieving data from the app is not very critical from a security point of view:

Even if you have a stale session cookie, GET request works fine without requesting you to authenticate. Only when you POST, authentication kicks in.

This approach will certainly not work for a banking application, where reads also have to be very secure. But for many application reads don’t need to be very secure. Also most applications have relative very small number of POST requests, which means very few times the user would be nudged to authenticate themselves. Most RESTful frameworks can have this built in.

Can this approach be used for rich-client apps instead of just web-apps? I think so.

What am I missing?

I’m proud to announce the 5th Annual SDTConf. This year we plan to hold the conference in Otterbein University Campus Center, OH, USA.

We plan to keep a max cap of 100 participants for this conference.

As you might be aware SDTConf is a free conference and we use the concept of position papers as the price for admission. This helps us ensure the quality of the participants is really high. You can add your position papers for the conference on our wiki. Making the position papers public helps other participants gauge in advance what they can expect from the conference.

Last but not the least, since this is a community run, non-profit event, we really on sponsorship in kind to make this event possible. Here is a list of items that you or your company can sponsor to support this conference.

P.S: Please blog about this conference and/or send an email to your friends and colleagues. Word of mouth is the only way we market this event.

Recently I stumbled upon John Maeda’s book: The Laws of Simplicity.

He has a very interesting take on Simplicity. In this book he describes:

TEN LAWS

1. Reduce – The simplest way to achieve simplicity is through thoughtful reduction.
2. Organize – Organization makes a system of many appear fewer.
3. Time – Savings in time feel like simplicity.
4. Learn – Knowledge makes everything simpler.
5. Differences – Simplicity and complexity need each other.
6. Context – What lies in the periphery of simplicity is definitely not peripheral.
7. Emotion – More emotions are better than less.
8. Trust – In simplicity we trust.
9. Failure – Some things can never be made simple.
10. The One – Simplicity is about subtracting the obvious, and adding the meaningful.

THREE KEYS

• Away – More appears like less by simply moving it far, far away.
• Open – Openness simplifies complexity.
• Power – Use less, gain more.

I found some slides which are also interesting:

David Hussman’s Keynote at Agile Bengaluru 2010 Conference titled: “Discovery and Delivery – Redesigning Agility”

David starts off saying “Agile communities know that the sooner they deliver a working product the sooner they can determine the value it provides. Yet while the ability to deliver frequently is valuable, if you don’t know where you are going, it is easy to iteratively not get there.”

In this talk David RI-examines the balance of discovery and delivery techniques in use by agile communities today. He specifically, discusses how can design thinking help agile communities discover deeper product value before iterative delivery begins. Also, after the first iteration, how can agile communities use design tools to keep the users alive and well and part of every story, acceptance tests, and iteration of development and delivery.