Don’t You Have to LOGIN first?

In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere.
I was also in that list discussion.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. For one thing, it’s unlikely that you’ll find much business value in delivering a system that allows people to login, but do nothing else. Unless you’re writing a login package for others to integrate into their code, something else is the central idea of the system. Surely there are some things about that central idea that we don’t yet know in detail. By contrast, “login” is fairly widely known and understood (even if sometimes implemented poorly). Even if we decide we can’t deliver the system without “login,” we can learn important things earlier if we work on the central idea first. (And I can imagine, in a pinch, having a usable system where access was controlled by putting the computer in a secure room where only those with authority could touch it.)

Learning important information sooner is one of the subtle but powerful benefits of working in an Agile fashion. It can help the business make better decisions about priority, or even about the direction of the effort. That’s one of the tenets of the Lean Startup focus, but it works for established organizations, too. There’s almost always something new about what we’re doing, or we wouldn’t be spending money doing it.

This pattern of accelerating learning is powerful for businesses that use it. But it’s also powerful for programmers working on the code. As we build our application, we can learn about better ways to structure the code, and we can use that information when we’re writing further code. I’ve found this to allow me to do a better job when developing code in an iterative-incremental fashion than when creating an up-front design and then following it.

Let’s look in more detail at Jon’s suggested beginning:

For example, to start, you can simply check that the response has “Login Succeeded” ( or “Login Failed” for testing that a bogus login attempt does indeed fail). …simply:

Scenario: Successful Login
    When I login as admin
    Then I should be logged in

Scenario: Failed Login
    When I login as asdf56ghasdkfh
    Then I should be not logged in

And your steps would hide the logic for filling in the login form and checking for success:

Given /^I login as "([^"]*)"$/ do |login|
  @login_name = login
  visit login_path
  fill_in "login", :with => login
  fill_in "password", :with => "password"
  click_button "login_button"

Then /^I should be logged in$/ do
  response.should contain "Login Succeeded"

Then /^I should not be logged in$/ do
  response.should contain "Login Failed. Please try again."

Given this simple start, where will we put our access control logic? Most likely in our Controller of MVC or Presenter of MVP. Then we’ll decide to which page we direct the user. In effect, we’re protecting the “Login Succeeded” page from the unauthenticated. Is that page the asset whose access we want to control?

I once worked with a client who had an application that allowed authorized users to access the documents to which they were authorized. It was not an Agile shop, and they were not working in short iterations using small stories. They had, however, been delivering new functionality in each release for a number of years. And they were very thorough programmers, carefully checking that they were not delivering bugs. Having started with the idea of access control, they had ended up with their authorization check in the Action class of their Struts app. Over time, there was a need for further authorization concerning some documents. Only an authorized user could see any document, but some documents were only available to a subset of users. The Action class checked that the user was logged in, retrieved the list of documents, and then filtered out the ones that particular user was not allowed to see.

Do you see any problem with this scheme?

It works well enough, but it causes some maintenance headaches. Even though there was not a link to the unauthorized documents, there’s nothing to stop a savvy user from guessing the URL and retrieving it anyway–so there had to be an authorization check there, too. And there were multiple lists of documents, so each one had to make this check. Sometimes when the authorization logic changed, one of the Action classes would be overlooked. Extracting this authorization filtering code to a method would reduce much of this duplication and make that particular mistake less likely, but some lists had different filtering rules. Also, the Action classes would retain the duplication of the order of steps that each one had to apply in order to properly protect the assets. (That’s a more subtle flavor of duplication that many overlook.) And there was a requirement to show some documents in the list to people who were not yet authorized to retrieve them.

It was pretty complicated and error-prone. Enforcing the security at the outer layer, instead of directly around the protected assets, resulted in more places and more variability in the implementation. I’m sure that you and I and Jon Kern would not end up with such an error-prone design. Jon is an excellent software designer–much better than I am. He can explain why you’d want to design in a particular way and describe the reasons why. I, on the other hand, have trained myself to be sensitive to duplication. Test-driving code with an aversion to duplication would lead me to a different design.

I helped these programmers implement a new feature–one that provided government-mandated access to certain documents even if the user wasn’t logged in at all. Since this required a change to all of these access controls, it provided the impetus to change the design. While adding this new requirement using Test Driven Design, I also refactored code to remove the duplication. As I did so, I pushed the access check lower in the code, passing along a “AuthenticationToken” object that could be treated as a black box by intervening layers. Ultimately the access check was made in the database queries themselves, insuring by simple inspection that no path in the user interface could lead to a condition that allowed unauthorized access.

You’re probably a good programmer, too. I’m sure you wouldn’t make a mistake. Linda Rising recently told me that 80% of people think they’re above average, so you must be good. As it happens, the programmers who built this system were pretty good, but they weren’t experienced in the technology. This J2EE system was the first Java code they’d ever written. These programmers generally succeeded by being very careful to check all the paths. Only very occasionally did they miss one and allow a bug to escape to User Integration Testing.

It’s my contention that by implementing the primary functionality first, in this case the listing and retrieval of documents, then we’ll be more likely to naturally put the access control directly around the assets that matter. In other situations, there may be other considerations for the access control that would be different from the application I described. In any case, if our primary story is

When I do whatever my application does
Then I get the result of doing so

in all of the varieties of “do,” then the proper place for access control will be obvious for more than 80% of us when we get to the story

Given I am not an authorized user
When I do whatever my application does
Then I am denied the result of doing so

While it is certainly true that we can get to the desired design anyway, as both Jon’s blog and my story above illustrate, it’s easier, more direct, and more likely that we’ll do so if we start with our primary business functionality before the LOGIN story.

It’s not a law of the universe, but it’s a good heuristic: The Login story is not the place to begin.

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
41 Corsham Street
N1 6DR
United Kingdom


101 Ways Limited
No.1 Spinningfields
Quay Street
M3 3JE
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at