Ryan Rinaldi

Today is day 3 of our first Sprint. Yesterday was our first Daily Scrum and so far I’m digging it but I don’t have enough experience to really know if Scrum “is working” yet.

When we were doing our Sprint Planning meeting it became exceptionally clear to me that it’s really, really hard to create 4-16 hour tasks when a lot of a Sprint involves research & prototyping.  We are working on implementing an Enterprise Service Bus and for this first Sprint a lot of us have to spend some time just learning the tooling.  How do you plan tasks effectively when you have no real idea how long something is going to take?  We wound up actually trying to plan how we will go about doing our research and how long we will spend on prototypes but it just feels like those sprint tasks are wild ass guesses. 

In the future I’m going to advocate that we break the 4-16 hour task rule when we don’t know the potential solution and use “Spikes”, “Tracer Bullets”, and “Research” to wrap our heads around the Product Backlog before we do a Sprint Planning.

At work we are in the process of implementing Scrum (actually tomorrow is our first Sprint Planning meeting. Really looking forward to it.)

Everybody on the team has read the books on Scrum and we are all very excited to finally be formalizing our processes but we are in disagreement about how best to actually implement Scrum.

The problem is that we are a small team responsible for a set of pretty independent applications.  All of these applications are in various states:

• “Done” – These apps only see bug fixes and very small feature work. Until the business processes around them change there will be little to no work required to maintain them.
• “Maintenance” – Apps that are recently released. As the business adopts them they will require small feature changes and bug fixes.
• “Greenfield” – Brand new apps that haven’t yet reached 1.0. Lots of work.

Greenfield apps have more than enough work to fill a sprint. Maintenance and Done apps, not so much. So how do you fit work on projects into a sprint if each app has it’s own backlog but might not have enough work for a full sprint? 

I’ve searched for an answer and I’ve found the following sites that address it but nobody seems to be in complete agreement.

1. http://blog.xebia.com/2008/08/21/agile-maintenance-one-team-multiple-projects/
2. http://www.infoq.com/news/2007/12/multiple-projects-one-agile-team
3. http://stackoverflow.com/questions/412525/how-does-scrum-work-when-you-have-multiple-projects

We have tentatively agreed that we will have one Product Backlog for all of our projects and a sprint can (and probably will) include work for multiple projects. We will have one person that will manage the Product Backlog and will work with the various Product Owners to make sure they understand how and why the work for their projects is placed in the Product Backlog.

So to all the Scrum people out there, is this a common scenario? Is one Product Backlog for multiple projects seem like a reasonable idea? If not how else can we address our situation? 

Found this trick today and it saved me a lot of pain. I was renaming/reorganizing a bunch of classes and almost every page I went to greeted me with this error:

To make life easier I added an After Build target to my web project to run the asp.net compiler. This will catch all the same errors which would normally require you to go to each page of the site.

Add this to the bottom of your .csproj file:

<Target Name="AfterBuild">

<AspNetCompiler

VirtualPath="temp"

PhysicalPath="$(ProjectDir)..\$(ProjectName)"

/>

</Target>

I was telling a coworker the other day how awesome it is to fire up the internet on my way into work on the train.  Since he also takes the train and has a longer commute then me I suggested he give it a try.  First question that came up was “Is it really fast enough to get work done?”

It’s not cable modem speeds but it sure is fast enough for most things!  I’m able to pull down code from svn repositories, I’ve done svn commits, twittered, googled all without a hitch. I’m loving it.

Sorry for the long and boring title, but I wanted to make it easy for Google to find this post.

If you happen to have a site that is storing Unicode (that's bold because it's important, as you will see later!) HTML content in a SQL Server database and you want to enable full text indexing there are a few hoops you have to jump through that aren't obvious.

First of all, you can't store your content as varchar, nvarchar or text.  The assumption is that the text in those columns is plain text so the indexer uses a vanilla iFilter instead of the iFilter for HTML.  To use the HTML iFilter you will need to create a pair of columns.  One "Document Type" column and another varbinary column to store your content.  What I did was create a document type column and a persisted calculated varbinary column that was the column actually indexed (not the column that the application edits).

In the end I had 3 columns:

1. [Content] -> This is the varchar(max) column that my application updates
2. [IndexedContent] -> This is the varbinary(max) column that is indexed
3. [ContentDocumentType] -> This is the (obviously) Document Type column that tells SQL Server to use the HTML iFilter.

Here is the code to setup full text indexing (let's assume you wanted to index some content in a CMS):

EXEC sp_fulltext_catalog @ftcat= 'ContentManagementSystem' , 

     @action= 'Create'

GO

EXEC sp_fulltext_table 'dbo.Entries', 'create', 'ContentManagementSystem', 'PK_Entries_EntryID';

GO

EXEC sp_fulltext_service @action='load_os_resources', @value=1;

GO

ALTER TABLE Entries

    ADD IndexedContent AS (0xFFFE+CONVERT([varbinary](max),[Content],0))

GO

ALTER TABLE Entries

    ADD ContentDocumentType AS 'htm'

GO

EXEC sp_fulltext_column 'dbo.Entries', 'IndexedContent', 'add', 'ContentDocumentType'

GO

EXEC sp_fulltext_table 'dbo.Entries','start_change_tracking';

GO

EXEC sp_fulltext_table 'dbo.Entries','activate';

GO

The key part is where you see 0xFFEE.  When you are storing Unicode content in a varbinary field, the field needs to start with those magic bits or else the indexer doesn't index the field properly and you will get ZERO results back.

Don't ask why I needed this, but here is a SQL function that will abbreviate a string:

create function dbo.fnAbbreviate(@source nvarchar(100))

returns nvarchar(100)

begin

    if charindex(' ', @source) = 0

        return @source

    declare @result nvarchar(100)

    declare @i int

    declare @char nvarchar(1)

    set @result = ''

    set @i = 0;

    while @i < len(@source)

    begin

        set @char = substring(@source, @i, 1)

        if CONVERT(varbinary, @char) = CONVERT(varbinary, UPPER(@char))

        begin

            set @result = @result + @char

        end

        set @i = @i + 1

    end

    set @result = REPLACE(@result, ' ', '')

    return @result;

end

What tools do you use? If you are reading this I bet you use some flavor of Visual Studio and some form of source control, but like most developers your tooling stops there.  Why?  Have you tried the various Visual Studio add-ins like ReSharper or CodeRush?  How about SQL Schema diff tools like SQL Compare from Red-Gate? How about a build server like Team Build or Cruise Control?

Most developers I know would answer no to most of those questions.  And honestly, I don't get it.  Do you like spending time writing reams of similar code?  Manually diffing schema? Figuring out why a build doesn't work in a new environment?

"Ryan, those things are too expensive.  I could never get those things approved!" I call bull.  Have you tried to use them? Have you seen productivity gains?  If so, I bet it would be a rather easy sell to your manager.  Do a simple ROI on it and you'll be amazed at how cheap most of these tools are!

If you are looking for the quick win, create a build server.  Once you see how easier deployment is when you can xcopy a build to a new environment you'll be sold.  Then you add in things like unit tests and longer running build verification tests and you'll be amazed.  You'll start to trust your builds and rollouts to new environments won't be feared.

Here is another thing I don't get.  Developers, as a whole, put up with a lot of friction before doing something about it and I'm not sure why.  We spend all day writing applications that make other people's lives more productive yet we will put up with friction at almost ever step of the way.

"But that's the way it is. Writing software is hard and this is the way it's always been."

Yeah, writing software is hard, but that doesn't mean we can't write software to make it easier!  There are two tools that I use everyday that you can't buy anywhere.  OutWit, a Outlook add-in that creates TFS work items and IntelliPages, a small applications that lets us search our company directory/quick dialer.  Both of these applications make my life easier and neither one existed until a developer on the team decided it to make time to bring it life. (I made OutWit and Ray made IntelliPages, which has been so successful internally it's now part of our standard desktop image across the organization. :))

Another tool I build/use is a simple command line app that is part of each solution and is tasked with knowing how to promote builds from one environment to the next. Get the build from the build server, put in environment, update Team Build with new environment information, that sort of thing.

My point is that as developers you need to look outside of Visual Studio more often and find tools that lower the amount of friction you deal with daily.  If you are adamant that there is no way you can buy a tool, then build it.  You have the power. :)

In a recent post, CRM 4.0 Plugins, I said I would post an example of a plug-in that handles entity merges.  Here is that sample! :)

public class MergeHandler : IPlugin

{

    public MergeHandler (string unsecureConfig, string secureConfig)

    {

    }

    public void Execute(IPluginExecutionContext context)

    {

        try

        {

            if (context.MessageName == "Merge" &&

                context.PrimaryEntityName == "account")

            {

                string targetCrmId = ((Moniker)context.InputParameters[ParameterName.Target]).Id.ToString();

                string subOrdinateId = context.InputParameters[ParameterName.SubordinateId].ToString();

            }

        }    

        catch (Exception ex)

        {

            throw new InvalidPluginExecutionException(ex.Message, ex);

        }

    }

It's actually a lot easier than I thought.  It just took me awhile to understand what values were going to be passed into Execute method of the plug-in.

In the comments to my post yesterday (comments meaning the only one I got), my friend and coworker Richard Lowe pointed out that working with new technology also adds business value.  I have to agree with him.  Staying up to date with technology, whatever technology you use day to day, does increase business value. I took that as a given because, in my opinion, if you don't stay up to date then you become technically irrelevant and technical irrelevancy adds negative business value.

Negative business value?  Yeah, negative business value.  You actually becoming a liability to the company by not introducing new technology.  Tool sets, frameworks and programming languages all have an expiration date (within reason. I know COBOL is still alive and kicking). When they expire, your company is now in a horrible situation (especially if that expired technology is running a core business application).  Staying technically relevant removes that liability.

"So Ryan?  What is technically relevant?"

Glad you asked!  In my opinion there are a few things that every developer should be aware of right now.  Take note that I didn't say you should be using, you should know or you should be competent in.  These are things that should have at least crossed your radar so if somebody talked to you about it you would have some basis for discussion.

1.) Unit Testing

Unit testing is pretty much beyond mainstream.  The tools to do unit testing are now shipping with Visual Studio. 

2.) Model-View-Controller/Model-View-Presenter

These patterns have been around a long, long time (so long in fact that they have been renamed, but nobody goes by those names yet). A lot of web and windows frameworks that are coming out (or in the Java world have been out for a long time) use these patterns.

3.) Object-Relational Mapping

I don't care what tools you use.  If you are a developer you owe it to yourself to at least know about O/RM.  It will save you boatloads of time and money. (See: NHibernate, LINQ to Entities, LLBLGEN, iBatis, etc.)

4.) Dynamic versus Static languages

With languages like Ruby and Python being mainstream, C# adding dynamic support (Dynamic via Static) and the addition of the DLR to the .NET runtime, you need to have some understanding of why people even cared about the issue to begin with.

5.) Messaging

With the push to create isolated systems and cloud computing being "The Next Big Thing", messaging and messaging patterns are starting to get more press.

These 5 things are items that I feel that developers need to have at least heard of. I'm not claiming to be a guru in any of these (especially messaging!) and I'm sure other developers have the 5 areas that they feel everybody should be aware of.  What technologies am I missing?

(Side note: The Metra is all screwed up this morning.  I'm told trains are running 20 mins late then the 7:51 pulls up going from Chicago on the to Chicago tracks.  Sigh....)

Anybody that has worked with me knows that I tend to be an early adopter of technology.  I love playing with Beta, Alpha, CTP and "Here is my bin folder" builds. But sometimes as an early adopter I run into trouble.  Not the kind of "This build borked my machine" types of trouble, but more along the lines of "Boy this is neat but what value does it give me?" kind of trouble.  If I can't find the business value in a piece of code or new technology it's nothing more than a geeky toy.

As a developer it's our job not to just write really awesome code, but to make sure that code adds value to the core business.  Sometimes I struggle with that.  When I'm adding some lame excel exporting feature instead of playing with Aspect Oriented Programming or when I'm fixing some edge case bug instead of doing some crazy Meta-Programming I have to remind myself that the things I am doing are increasing productivity in some other part of the business.

Sometimes though, we need to take a step back and look at those new technologies (I just came back from PDC so my brain is FILLED with new stuff).  Do these new technologies increase business value?  How-so?  Sometimes the question is easy enough to answer (Windows will crash less), other times it's harder (Oslo will help you create textual DSLs).  Whenever I'm in this position, the first thing I do is play with the technology.  How long is taking me to understand it?  Is it lowering the amount of code that I have to write, or just moving it around (C# to Xml configuration)? Is it lowering the amount of friction in my day-to-day life?  Once I can answer those questions I can move forward and confidently promote new technologies to the business (or not as the case may be).

When you start to think of terms of business value interesting changes start to take place.  When you are what feels like a death march project you start to ask around.  What value are we providing?  Who needs this software?  What is this application going to do for them day-to-day? Are we really making work easier?  The answer to those questions will either motivate you because you know you are providing value, or the questions start to float up the chain of command and project goals start to get re-aligned.  There have been a few projects in my life that as stake-holders and priorities changed no one was really sure why the application was being built.  Asking questions has helped to get those projects back on the right tracks.

In the end, my point is simply that when you are implementing a new feature, fixing a bug or working with brand new technology try to keep your focus on business value and not what shiny new toys you want to play with.