public String execute() {
    String resultStatus;
    User user = getUser();
    if (loggedIn(user)) {
        String key = getParameter(KEY);
 
        if (!isEmpty(key)) {
            String id = findSourceIdFor(key);
            Record record = new Record(user, key, id);
            record.save();
            resultStatus = "Successful";
        } else {
            logger.severe("Invalid key"); 
            resultStatus = "Invalid Key";
        }
    } else
         resultStatus = "User Not Logged In";
 
    return resultStatus;
}

OR

public String execute() {
    User user = getUser();
    if (!loggedIn(user))
        return "User Not Logged In";
 
    String key = getParameter(KEY);
    if (isEmpty(key)) {
        logger.severe("Invalid key");
        return "Invalid Key";
    }
 
    String id = findSourceIdFor(key);
    new Record(user, key, id).save();
    return "Successful";
}

Personally I like the second code sample. I’m a big fan of the guard clause pattern. Even though the second code sample has multiple return statements (which some people hate), it has much lower cyclomatic complexity.

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.

As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user’s needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

Most software organizations today suffer from what I call, the “Inverted Testing Pyramid” problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

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.

Imagine, an automobile company building an automobile without testing/checking the bolts, nuts all the way up to the engine, transmission, breaks, etc. And then just assembling the whole thing somehow and asking you to drive it. Would you test drive that automobile? But you will see many software companies using this approach to building software.

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.

Update: I recently came across Alister Scott’s blog on Introducing the software testing ice-cream cone (anti-pattern). Strongly suggest you read it.

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: