Educating the Team II (follow up to >>It's harder than I thought<<)

After laying some groundwork to understand C# and a tiny bit of .NET I would like to go more hands on. As the requirements are not as far as they should be (remember: NO ON SITE CUSTMER YET) I was thinking of picking a playground scenario my self and take it over the hurdles.

Here are the things I would like to do in the order I intent to do them

• Pick two features.
• Define Acceptance Tests.
• Implement Acceptance Tests with FIT (not Fitnesse - I don't see an easy way to manage it in revision control).
• Set up Continuous Integration running the FIT Tests - which will be all red at that point.
• Implement the features with automated developer tests.
• Enhance the CI to do the actual build, test and the packaging.
• Demo the result to the Management.

I would like to pick two features because the one feature I had in mind which we could use later on was Authentication and Authorization. As this is an infrastructure concern there is nothing to show off to the management later on. So I need to add a showcase scenario as well. For now lets say we manage some goods and only certain people are allowed to view the wholesale price and only some people are allowed to change our retail price .

So we will build some simple app that allows a user to enter, view, change, delete and query the goods. No fancy stuff. A good is described by its number, description, wholesale price, and retail price.

As the application we will build will be running as a SmartClient in a Windows environment, it makes sense to use integrated security. So if some user is logged on we just believe he is who Windows claims him to be. So this takes care of authentication. For authorization we would like to use memberships in Windows groups: You can print that really_secret_report only if you are a member of the ourapplication_ReportingLevel2 group. But there will be situations where integrated security will not work. There might be some customers that do not use a Windows Domain or there might be POS terminals which are used by more than one person without actually logging on as themselves. I've seen systems used in restaurants where the waiters were using some key - either a real key or something like a chip - to identify themselves on the terminal. If our application is running in such an environment we would like to switch our authentication and authorization provider.

And even if we would aim only for integrated security, we would like to keep our software decoupled from the actual implementation of the provider: It would be absolutely impossible to run either our unit tests nor out acceptance tests against a Windows domain providing the auth-info. There is no way we would be able to gain enough direct access to the Windows domain to set it up in the way we need it.

This is an ideal reason to introduce the team to the concepts of IoC and Testability. It pays to be able to switch implementations without affecting the application. It pays while developing because we can work in parallel on both features and can run tests for the app even if the auth-provider is under development. And it pays while in production because we can enhance our application to work in an environment that does not have integrated authentication.

Even if we are able to switch the auth-provider, the first implementation I expect to ship is the one for Windows integrated security. We will start to work on a module that handles the management of users and roles when we face the first environment where we need it. This defers the work on a user management module until some later time. No need to pay interest rates until then, no need to delay other features that are more important for the application and the vast majority of customers.

Please give your feedback...