Secret Server has supported a “Mobile Edition” for over a year now but it is always tricky making sure that it works correctly on all devices.

Our approach was to bake mobile support into the base product (ASP.NET based) so it simply scales down to the capability of the device.  That sounds simple but unfortunately it depends on making sure that functionality will work with all the limitations of various devices.

My own favorite BlackBerry 8820 does a reasonable job of helping me get to the password I need in emergencies but it is hardly a pleasant browsing experience.  In fairness, no browsing on the device is particularly pleasant since it is slow, struggles with most layouts and has a small screen.  That said, I love it dearly and browsing has never been a core requirement for me since email, contacts and calendar are definitely my most essential.

Today we had a customer ask about the Treo 700 so I tried out the emulator from the Palm website.  It seems to work fine with Secret Server and I was able to browse around and access passwords.

Do your web applications support mobile devices and if so how do you test them?

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

Ok, so it is a really bad pun.  It is tough writing blog post titles sometimes.

Anyway, we finally got a beautiful metallic official sign for our office after inhabiting our office space for almost two years.  (Now if we could just do something about that door!). 

In our first office suite in Vienna (VA) we had a good excuse for not having a sign since it was shared space and we weren’t allowed sign-age.

In our current space, we actually lasted almost two years with this paper sign.  Not exactly glamorous but it did the job.

This got me thinking … when is the moment that you are no longer a startup? 

A few facts about Thycotic’s beginnings:

• We were profitable from day one.
• Our software development consulting business has always been a stable, profitable area.
• On the product side, Secret Server is self funded, started small and has slowly built a solid customer base.
• The company was officially formed in 1996 but only hired its first employee other than me in 2004.

So how do we identify a change from startup to mature company?
(if it is has even really happened to us yet)

Could it be?

• The day you finally turn off the email that tells you when someone bought your product.
• The day the founder can take more than one consecutive week of vacation.
• The day you don’t know how many employees are in the company (this has already happened but that is just because I have a hard time figuring it out on the fly).
• The day that the company hires someone the founder didn’t hire or even meet.
• The day you walk by someone in the hall you have seen often but have no idea who they are.
• The day you are bought out by some monster corporation. (assuming you want to be bought out … which we don’t)

What would you define as the tipping point?  In the meantime, we are going to continue admiring our new sign.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

• CMAP Code Camp in Maryland
• Pittsburgh Code Camp in Pennsylvania

I will be speaking at the Pittsburgh Code Camp on Refactoring - a topic that is very dear to me.

Register now and come along to talk code.

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products?  Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.

• Agile .NET Developer
• Agile .NET Developer Internship
• Graphics Designer

All three involve *doing* something in order to be considered for the position - for the developer positions it requires completing a code sample and sending it in with your resume. For the graphics designer position, it requires putting together a fun design and sending it in with resume.

I have not kept accurate numbers (since we have run the postings for a while now with lots of applicants) but roughly 1 out 2 candidates for the developer positions and a whopping4 out of 5 candidates for the graphics designer position do not submit their design/code. If I receive 20 applications in two days and your application is canned and does not include the design/code - then guess what happens to yours? … it gets DELETED. Can you believe that there are many applicants who just send a resume without even a cover letter?

If you can’t bother to read a job posting, why do you expect someone else to bother reading your resume?

It is truly amazing that some people believe their resume alone will make them stand out - I imagine many companies don’t even open the resume if the applicant hasn’t met the requirements of the job posting - I know we don’t.

A job is an significant part of our lives and should be treated with importance.

When you next apply for a job:

1. Read the job posting entirely.
2. Submit any additional samples/code as required.
3. Research the company, understand what they do and why you might want to work there.
4. Write a good cover letter explaining what you find interesting about the company, team or position.

Take these simple steps and you will stand out.

We are hiring! Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com. (don’t forget to read the job posting! :))

This was a very different conference for us since the audience varied widely in their roles compared to a conference such as Microsoft TechEd.  We met lots of IT managers and also our core audience of System Administrators and Network Administrators.  If you have an Excel spreadsheet of passwords that you share across your team … then Secret Server is a no brainer for you.

My favorite part of tradeshows is hearing where your product falls short and learning to better understand your customer’s needs.  Secret Server has come a long way in the last year and most the requests we heard were already met within the product.

The next stop for the Secret Server booth will be the Microsoft TechEd 2008 Conference (IT Pro week) in Orlando, Florida in June.  If you are going, please stop by our booth to say hi.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

The NoVa CodeCamp South v1 will be held on March 29th 2008 in Woodbridge VA.  The speaker schedule has been posted here.

I am presenting two sessions:

9:00-10:15:     Refactoring in C#

1:00-2:15:        Web Application Testing in Watin

Register now!

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.

If you are interested in the original problem, go here.

@drakiula: The idea with the Response.Redirect is that it will stop processing so the else is not needed on line 23.

@JV: Yes, this code could definitely be refactored!
And your suggestion would squish the bug.

@rajbk: Nice. Yes, the ThreadAbortException is definitely part of the bug but I don’t think the Redirect(url, false) is the best way to go.

@Basgun: Changing line 17-23 as you suggest would make it cleaner but wouldn’t fix the bug.

@cibrax,Lee:  Nice. Yes, the ThreadAbortException will cause the catch to fire everytime and redirect the user to the same page.

@Thomas Eyde: Nice. Yes, the refactoring into separate responsibilities would make it much cleaner and also would somewhat inadvertently fix the bug since the redirect would happen outside the catch.

@Zack Jones:  Nice suggestions.  Thanks!

@Hosam Kamel: Yes, good point - there are several ways those method calls could fail (lots of encryption and authentication done within them) so the catch is there as a simple default “then send them here”.

Summary:

If you call Response.Redirect(string) or Response.Redirect(string, true), it will throw a ThreadAbortException.  So if you do the redirect inside a generic try/catch then your catch will fail everytime.  As pointed out by several people above, the code could be refactored so the responsibilities are separated out - this means that the Redirect should probably only be done in one place which would mitigate the issue.

I was surprised to see that Response.Redirect throws this exception especially since this exception is not thrown up the Application_Error event so some “magic” must happen within ASP.NET to issue the HTTP location header but not allow the exception to continue as a real exception.  This seems like a misuse of exceptions since a Response.Redirect is hardly an “exceptional” case and in many applications happens somewhere on every page!
That said, it is reasonable to see how Microsoft uses this mechanism to prevent further execution in the page.

Either way, it is a good gotcha to remember!

Here is the “fixed” code:  (although this could still be seriously refactored)

01: private void Page_Load(object sender, EventArgs e)
02: {
03: string redirectUrl = null;
04: try

05: {

06:     AuthenticationInfo authenticationInfo = GetAuthenticationInfo(Request.QueryString["t"]);

07:     Authenticator authenticator = new Authenticator(new LoginProvider());

08:     AuthenticationStatus authenticationStatus = authenticator.Authenticate(authenticationInfo);

09:     if (authenticationStatus.Authenticated)

10:     {

11:         IUser user =

12:             BLUser.Load(authenticationInfo.UserName, authenticationInfo.OrganizationCode, aut
henticationInfo.DomainId);

13:         user.SetNewSessionId();

14:         AuthenticationTokenParser authenticationTokenParser = new AuthenticationTokenParser();

15:         string authenticationToken = authenticationTokenParser.Create(user.UserName, user.OrganizationId,

user.DomainId);

16:         FormsAuthentication.SetAuthCookie(authenticationToken, true);

04:         redirectUrl = FormsAuthentication.GetRedirectUrl(authenticationToken, true);

04:     }

16: }

17: catch

18: {

19:     // If anything goes wrong (encryption error, etc) then just let it fall through to the redirect.

20: }

21: if (redirectUrl == null || redirectUrl.Trim().Length == 0)

22: {

23:     redirectUrl = “~/Home.aspx”;

24: }

25: // NOTE: If you do the Redirect inside the try/catch it will get a ThreadAbortException!

26: Response.Redirect(redirectUrl, true);

27: }

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.

Kudos to the weblogs.asp.net team for fixing the issue quickly.

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.

   1:  private void Foo()

   2:  {

   3:      try

   4:      {

   5:          AuthenticationInfo authenticationInfo = GetAuthenticationInfo(Request.QueryString["t"]);

   6:          Authenticator authenticator = new Authenticator(new LoginProvider());

   7:          AuthenticationStatus authenticationStatus = authenticator.Authenticate(authenticationInfo);

   8:          if (authenticationStatus.Authenticated)

   9:          {

  10:              IUser user =

  11:                  BLUser.Load(authenticationInfo.UserName, authenticationInfo.OrganizationCode, authenticationInfo.DomainId);

  12:              user.SetNewSessionId();

  13:              AuthenticationTokenParser authenticationTokenParser = new AuthenticationTokenParser();

  14:              string authenticationToken = authenticationTokenParser.Create(user.UserName, user.OrganizationId, user.DomainId);

  15:              FormsAuthentication.SetAuthCookie(authenticationToken, true);

  16:              string redirectUrl = FormsAuthentication.GetRedirectUrl(authenticationToken, true);

  17:              if (redirectUrl == null || redirectUrl.Trim().Length == 0)

  18:              {

  19:                  redirectUrl = “~/Home.aspx”;

  20:              }

  21:              Response.Redirect(redirectUrl, true);

  22:          }

  23:          Response.Redirect(“~/Home.aspx”);

  24:      }

  25:      catch

  26:      {

  27:          Response.Redirect(“~/Home.aspx”);

  28:      }

  29:  }

I will post the answer soon if no-one gets it.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in a text file?

The chart to the left represents the Burn Down chart for the Secret Server 4.1 release which shipped on March 14th 2008.  We have always shipped Secret Server on the published date (or in the early hours of morning the next day!) but this release pushed things a little too close for our liking.  What was the problem?  Did we take on too much?  Did we trade off scope like we are supposed to?

Looking at the Burn Down we can see that our velocity was really low in the early stages of the release.  This was mostly due to some support issues that drained our development resources and also some staff shuffling on projects which lead to inefficiencies.  We were able to make up for this with a phenomenal increase in velocity in the final iterations.  Unfortunately this was achieved by using more team resources to accomplish the tasks.  While the increased velocity is good, it also means there was a greater rate of change in the codebase at a point where quality assurance was trying to stabilize the product.  Test Driven Development certainly helps by allowing us to lean on our regression suite of tests but it is still not ideal.

So what went wrong?  We will be having a recap meeting later this week to determine how to improve our planning for future releases. We need to get back on track to our usual release schedule where we are ready for the actual release days before the release date (not bad for a small team with frequent releases!).  I think part of the problem was not planning properly for reducing scope.  We left one of the larger features of the release until the end (the Role Based Security feature) - then we didn’t recognize that this feature could be thinned out to reduce scope but rather implemented most of the originally specified functionality. 

Typically our team cannot easily change resources (cost) since most team members are committed to projects and cannot easily shift responsibilities.  We also can’t change the date since customers are expecting a release on a particular date because sales and support have been giving this date out for a few weeks.  This only leaves scope as the final equalizer to make timely releases possible.  In future, we will need to be more careful to ensure that scope can always still be reduced if necessary.

What does your Burn Down Chart tell you?

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.