Scott Lilly – Agile .Net Developer

I’m going to be leading a session on development patterns this Saturday (the 17th) at the Austin Code Camp.

Over the years, I’ve ended up working on a lot of existing codebases, some of it good, some of it bad. I’ve spent a good deal of time thinking about what separates good code from bad code, and what can I do to ensure that the code I write is good. Agile development has been great because of the practices of writing unit tests, high code coverage, and continuous integration. With that, I can safely modify existing code and quickly know if my change broke some other part of the application. Design patterns have also helped by letting me know how to write a standard solution to common scenarios.

However, even with those tools in the toolbox, it’s still possible to write bad code. What I’ve been working on lately is trying to bridge the gap between writing the unit test and ending up with great code. “Development Patterns” is what I’ve come up with (although I’m sure I’m not the first person to think this up). If I’m creating a new class, and have a property that doesn’t need any additional code in the getter and setter, should I just make it a public variable, or do I go ahead and write the simple getter and setter? When I need to instantiate an object, do I just write “Employee user = new Employee();”, or should I get an IPerson object from a PersonFactory? What are the costs and benefits or writing my code either way? What makes the code more flexible? What makes the code easier to maintain? Which is clearer to a new developer coming in to made changes to the system six months from now?

This is what my session will be about at the Austin Code Camp. I don’t expect there to be too many answers, but I am hoping for plenty of good questions. I put together a quick website to go into the details of this some more. It’s developmentpatterns.com. It currently has a simple wiki with a few patterns listed and only one mostly filled out (oh, the joys of moving and being without the Internet for weeks). There is also a discussion board there to talk about why the pattern is useful or not, and how to improve it. I’ll be working on my personal projects using the current ‘best patterns’, and expect that will lead to quite a bit of change to them over time.

If you have any thoughts on the subject, please check out the website and add a comment to the forum. If you see me at the code camp, please let me know what patterns you follow that makes your code great.

At my client, the drive to switch to agile development has really come from management.  With the merger of two divisions (one agile, one not), the decision was made that the standard would be agile.  While I think choosing agile is a good decision, it seems to work better when the team drives that decision.  Fortunately, several of the team members were already familiar with agile tools and techniques, and they all seem open very open to learn more.

At the first meeting with the whole team, I focused on the few things that I think are important:

1. I’m not there to push a pre-determined agenda.  I’m not a devoted follower or Scrum, XP, Lean, Agile, etc.  I don’t have a checklist with 18 things they must do be considered ‘Agile’.  My focus is on what practices help the team implement the principles, and it is the team that ultimately decides which practices provide a good return on their investment.

2. When it comes to the principles that I consider to be important, they are; “Give and get feedback early and often (from and with customers, teammates, the code, etc.)”, “Act on the feedback to improve”, “Take small incremental steps, so that you never go too far of course”, and “Never let the code be undeliverable for long”.  Those are what I consider when judging the practices that we’ll try out.

3. While there’s a lot of room for growth with agile practices, they need to focus on where they are going and how much they are improving, not how far they are from the end.  95% code coverage can look intimidating for a project that is currently at 0%.  But getting to 5% will be something to be proud of.

4. My background has been as a coder, and I’ve gone through the change from non-agile to agile.  I think it’s important that the coach doesn’t only have ‘book smarts’.  They should be someone who has a few scars from going down a road or two that didn’t work for them.

After that, I asked what topics they were most interested in and what parts of the process are causing the most pain.  Those became the ‘user stories’ for my project of coaching the team.  Those are now on a whiteboard next to my desk and can be added to and changed based on what makes sense for the team.

One of the items was dependency injection.  So, I created a test application to show how to use dependency injection to help make legacy code easier to unit test.  As an existing team, they have a lot of code out there without tests, and much of it has dependency issues that make it difficult to test.  I’m going to see if I can do a similar tutorial here, without taking up a few hundred pages.

I’ve been spending the last few months on a contract assignment that’s been heads-down coding.  I re-wrote an accounting integration service, improved the performance of a data entry application (hint: don’t use temp tables in your stored procedures, unless you really need to), and created a web application that manages print queues for jobs running local SSRS reports.

But now, I’m back to ‘Agile Coaching’.  I have an assignment to help a development team become more agile.  This client has gone through a lot of changes recently.  There was a merger of two separate divisions, and all the somewhat-expected management changes, hirings, firings, resignations, etc. have been happening.  The main development groups have been using agile methodologies, but the team I’m working with really hasn’t been doing any.  So, I’m coming in to help the team transition to agile development.  I’ve met all the members of the team, and have found out that some of them have already used agile techniques on their own, or at previous jobs.  The ones who haven’t seem like they are at least willing to try out the new techniques.

First, I should probably mention that I’m not a strict follower of any particular agile methodology (XP, Scrum, Lean, DSDM, etc.).  My main interest is in focusing on the basic principles, then picking and choosing the practices that make the most sense for the team and their projects.  I obviously have the practices that I personally like to follow, but I’m a believer that the team has to drive their own practices and standards.  My approach is going to be to show the some practices, how they apply to the principles, work with the team to get them to the point where they can use the practice, and let them decide how they want to use it (if they do).

I’ll also be running my project of ‘Help the team improve their applications and development techniques’ as an agile project.  On Tuesday, I have my first meeting with the whole group.  I plan on most of the meeting being a Q&A session, to find out what the team’s biggest problems are and what they want to work on (regarding agile practices).  The comments from the meeting will become my ‘user stories’, and I’ll let the team (my customers) prioritize them.  Just like any agile project, I know that the stories will change over time, new ones will get added in, some will be removed, and the priorities will definitely change.  But I think that things should work well this way.

For anyone else interested in changing a development team over to agile methodologies, I’ll be documenting the experience here (the good and the bad).

By the way, for anyone on the team who might stumble into this site.  Sorry, they’re won’t be any secrets here.  I’m a pretty open guy.  If you have a question, just come over to my desk and ask.