Archive

Archive for the ‘Agile’ Category

A stranger in a strange land: A graphic designer in a dot NET Agile sprint planning world

April 30, 2009 Leave a comment

Josh Frankel: Stranger in a Strange Land a Graphic Designer in a .NET Agile planning meeting

April 30th 2009 | Josh Frankel

Stranger in a strange land: A graphic designer in a .NET Agile Sprint planning world

Agile Planning is an effective way of gauging how much work can get done in a given period of time. By measuring things in relative units of effort one should be able to approximate units of work required for a task. Our team uses a point system to avoid being influenced by a system based on hours. Hours may seem easier to use but they are not necesarily representative of the proportional relationship between work that has been completed and work that needs to be accomplished.

Shortly after joining Thycotic as a Web designer I was given a brief overview of Test Driven Development and Agile Planning practices and immediately recruited to participate in the bi-weekly sprint meetings. But with my skill set rooted firmly in the design arena and my vast development skills limited to CSS and HTML-I had absolutely no idea what was being discussed.

As the team went through the challenges and methods of each task I realized that my grasp of programming was comparable to my grasp of Mandarin Chinese. When it came to discussing point efforts needed for tasks, my guesses were wildly different from the rest of the team’s.

It’s been a few months now and sprint planning meetings are a lot easier. My assessment of the point effort needed for a task is usually pretty close to the developer’s approximations. Although I understand the planning terminology, I still don’t know squat about programming- for the purpose of Agile sprint planning, I really don’t need to. I only need a grasp of how or what is going to be done based on it’s relative difficulty to other tasks. What I’m trying to figure out during each sprint meeting though, is how much harder the current task is when compared to one that’s worth one point.

With buzzwords like ‘synergy’ and ‘cross-functional’ being thrown around so much, isn’t it time consideration was given to how Agile techniques might be expanded and enriched by those of us outside the traditional developer role?

Josh Frankel is the junior graphic designer and marketing team member at Thycotic Software Ltd, an agile software consulting and product development company based in Washington DC.  Secret Server is our flagship enterprise password management product.
On Twitter? Follow Josh

Refactoring Code: A Programmers Challenge

April 2, 2009 4 comments

Kevin Jones: Refactoring

April 2nd 2009 | Kevin Jones

Refactoring Code: A Programmer’s Challenge

Today I encountered a question on the ASP.NET Forum that I got quite excited about, “How do I refactor this?” Refactoring is a big part of our daily coding practices and I was curious as to what other programmers would come up with. Here is the basic question re-worded a little bit for brevity:
I have a master page with a control on it. However, on certain pages I don’t want a control to be shown. At first it was just one or two pages, and my approach worked just fine. However, the number of pages I need to hide this control on has grown. Can anyone offer some advice on how to refactor this code?
This was his code:
string pagename = Request.ServerVariables[“PATH_INFO”].ToString().Trim().ToLower();
if (
pagename == “/index.aspx” ||
pagename == “/sitemap.aspx” ||
pagename == “/404.aspx” ||
pagename == “/status.aspx” ||
pagename == “/online_help.aspx”
)
{
SomePanel.Visible = false;
}

The original poster realized that his code wasn’t maintainable-a classic reason to refactor: Keep your code clean, readable, and maintainable.

The interesting thing about refactoring is that there is no de-facto way to improve this code-or any refactoring for that matter. Refactoring has a lot of patterns that have been used over the years, but how that pattern is implemented, and evolves, is a discussion that could go on forever. The key is: keep the code simple and keep the changes small. If we really wanted to, we could write over-the-top code; put these pages in a database table; and cache the table for performance. But if you refactor often enough the changes should always be incremental.

Here’s something else to consider: the ‘if’ statement will keep getting larger and larger every time a page is added. If I was implementing this I might have started in the same place. I wouldn’t have needed this control visible for this page, but then I might not have needed it for the next one either, or the next one. The original code is not bad-it just doesn’t meet the new criteria.
My suggestion is to remove the OR chain and store the page names in a local so one can just keep adding to a string array, and then check if it exists in the string array. This simple refactoring adds a little clarity to the code, but it’s not exactly a work of art:
string[] pagesToHideElement = new[]
{
“/index.aspx”,
“/sitemap.aspx”,
“/404.aspx”,
“/status.aspx”,
“/online_help.aspx”,
};
string pagename = Request.ServerVariables[“PATH_INFO”].ToString().Trim().ToLower();
if (Array.Exists(pagesToHideElement, s => s == pagename))
{
SomePanel.Visible = false;
}
We have isolated one of our problems: the growing list of pages we want to exclude. The developer can then keep adding to the array. This also provides flexibility we didn’t have before. We can now move our page list anywhere we like, like a new class and method. This is a very simple refactoring, but what else can we do? While the original person didn’t think of this, this code isn’t easy to test without a full-blown integration test.
Not to derail our refactoring discussion, but let’s talk briefly about testing and how it applies to refactoring. They go hand-in-hand, especially to an Agile developer. Refactoring is a necessary part of improving code, but how do you know that everything will still work? Many who oppose refactoring don’t write tests simply because they have no proof that a refactoring didn’t break the code. And refactoring isn’t always easy, especially when dealing with legacy code. Most Agile developers are familiar with the “Red-Green-Refactor” motto:

Refactoring Code

The diagram varies, but nevertheless it always says the same thing
1. Write a failing test first (That’s a core Test Driven Development value)
2. Make the test pass by implementing the required code
3. See the test pass
4. Refactor
5. Make sure you are still green
6. Improve test so that it is red again
It’s the fifth component that makes testing and refactoring go together well. Peace of mind comes with knowing that you didn’t break anything, assuming you have good testing practices-but of course you do!

Back to refactoring. How is this code refactoring tested without actually seeing if it shows the correct content or not? MVP or the MVC pattern are a good idea, but let’s start small. A pattern that I am fond of for these simple things is a decider class. The benefits of this pattern will become clear shortly.
This sort of decision-making logic doesn’t really belong in the presentation layer (UI layer). It can be deferred to a decider. The decider is exactly what it sounds like-a class that decides if the panel should be visible or not. So our decider can have a method on it that takes a page name, and return a Boolean value if the panel should be displayed. Simple enough, right? At this point we are extracting our logic out of the page and into a new class.
public class DisplayPanelDecider
{
public bool ShouldDisplayPanelOnPage(string pageName)
{
string[] pagesToHideElement = new[]
{
“/index.aspx”,
“/sitemap.aspx”,
“/404.aspx”,
“/status.aspx”,
“/online_help.aspx”,
};
return !Array.Exists(pagesToHideElement, s => s == pageName);
}
}
So now we have a piece of logic that we can test very easily. All that the ASPX page would have to do is create an instance and hand in the page name, but the core decision logic can be tested without any need for a browser.
This gives us a new power through. Now that we have this decision making logic in its own method, we can make our method do whatever we like. If, in a year’s time, this no longer feasible, we can alter our method to pull the page names from an XML file or a database. We’ll look at that later.


A quick recap of what we did:

  • We changed the functionality to give us a bit more functionality and moved from a large OR operation to a more dynamic approach.
  • We extracted our logic out to a new class.
  • Two simple changes…and the benefits are huge!
  • We can now test this logic very easily through our favorite testing framework. XUnit MSTest, etc. (I refer to XUnit as “Any of the testing frameworks, like NUnit, MbUnit, etc. Not the actual framework called “xUnit”).
  • Our logic extraction keeps the decision making out of the ASPX code behind. This keeps our ASPX code behind focused on the page, not buried in a code behind.
  • We have the freedom to change what this method does without affecting the page. In the future, we can make “ShouldDisplayPanelOnPage” do whatever we like.
  • Further changes to this class can be tested TDD style so we can feel confident that future refactorings won’t break functionality.

What would you have done to improve the code? Got a better idea or suggestions?
Next we’ll look at dependency injection and what happens when this decision making logic gets complex.


Kevin Jones is a Senior .NET developer and Product Team Leader at Thycotic Software Ltd. Thycotic is recognized for providing Agile TDD Training and Agile .NET Consulting Services, and its flagship password management software Secret Server.

When you apply for a job, read the job posting!

April 8, 2008 17 comments

I am constantly amazed by the number of job candidates who apply for a position without reading the job posting. We are currently hiring for three positions:

  • 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.

image 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! :))

Learning from your Burn Down chart

March 18, 2008 Leave a comment

image

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. 

image

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.

Secret Server 4.0 has shipped!

December 22, 2007 Leave a comment

theming

We were hoping to ship one day early but a few delays in getting some updated artwork and some of the upgrade documentation caused us to ship yesterday on the scheduled day.  Secret Server has never missed a launch date since first being released in November 2005 – this is something we attribute to Test Driven Development, Pair Programming and an agile planning schedule.  Usually this means reducing scope slightly as the launch date approaches – this time we had to drop a fix for supporting backup when SQL Server is not on the IIS box but it will come in an update in early January.

So what is new in 4.0?

Theming

Theming allows you to create your own company theme for Secret Server – this was a popular request with customers. 

We also shipped two new themes with 4.0 – Blue Chrome and Corporate.

Inherited Permissions on Folders

Managing permissions on secrets and folders is tedious.  4.0 brings permission inheritance across secrets,sub-folders and folders.  This makes it possible to specify who has access at a high level and allow those rights to cascade through the hierarchy.

Additional Highlights

  • Optional, customizable Login Policy Statement for corporate environments
  • Migration from the Microsoft .NET Framework 1.1 to 2.0
  • Ability to search by sub-folder
  • More…

 

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?

Removing dead code

December 5, 2007 6 comments

Ambulance_Stretcher What does your code terrain look like?  Are there bodies of dead logic lying here and there?  Maybe they helped briefly while you worked towards a better solution or perhaps they just fell victim to changing business rules.

At a recent Code Camp, there was a question about code generation and I answered that we (as developers) are required to love every line of code (it drew a laugh from many).  But love isn’t cheap … it takes time, care and hard work.  Therefore we should only love and care for the lines of code that we absolutely need.  Anything not being used should be removed.

 

 

 

 

 

What excuses are there to keep unused code?

  • We may need it in the future
    • The classic argument – the typical agile response being YAGNI
    • Keeping it in the code-base takes maintenance in the form of understanding it, updating associated tests and working around it to add other functionality.
    • It will always remain in source control should we ever need it again
  • If it ain’t broke, don’t fix it.
    • Bob Martin sums this up well when he defines what “broke” means:  Code should 1) work 2) be maintainable and 3) communicate its intent.  Clearly dead code violates 2 and 3.
    • This idea also defeats the goal of loving every line of code – leaving something alone for no good reason is neglect.

I just spent a good half hour cleaning up some code and mostly removing unused code.  It was annoying since it wasn’t even being used but at least I am happier with the code now.  A good tool when investigating code you suspect may be dead is ALT-F7 using Jetbrains Resharper – you can easily find all usages of a method or class even in large code-bases.  A cheap alternative is to use “lean on the compiler” (as discussed by Michael Feathers) – this is simply changing a class name or method name by one character and try to compile (the compiler will then let you know what is depending on that code).

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?