I’m starting a new blog series based on my experiences doing agile coaching at clients.  Along with agile projects in .Net, my company also offers agile coaching and training.  Right now, the agile coaching practice consists of me, but I’m actively working on finding people to expand that practice.  I started doing this March 2007, and since then, I’ve seen some of the same patterns repeated in very different businesses.  In this series of posts, entitled “Agile Coaching”, I’ll talk about some of the common solutions to the common problems I’m finding.  This first installment is about a daily stand-up meeting.

The daily stand-up meeting

At several clients, I’ve seen developers who aren’t co-located.  Many organizations value individual offices, and what I observed is that sometimes developer won’t communicate much day-to-day.  Perhaps there is a weekly development meeting where folks report on status.  I attended one of these, and one developer reported spending the entire last week on a single blocking issue.  A whole week!  I recommended the instituting of a daily stand-up meeting immediately.  This would give a daily sync-up opportunity for the development team.  There are plenty of other things to improve, but a daily stand-up meeting is low-hanging fruit.  It is easy to implement and returns immediate gains.

What is it?

Every morning (I like 0830 or 0900), gather the development team in the same area.  That area could be a hallway, a meeting room or whatever space is available for standing.  No chairs allowed.  The meeting should be over in under 10 minutes.  The agenda:

• What I accomplished yesterday
• What I plan to accomplish today
• What issues are blocking progress

Every person in the development team reports on the three items to the rest of the team.  This is not a report to management or the coach/scrummaster/project manager.  This is so each person has a clear understanding of what is going on.  When issues are exposed early, others can help resolve them quickly.  I recommend this practice be used in every software organization. 

For more counter-intuitive banter, subscribe to my feed:  http://feeds.feedburner.com/jeffreypalermo

There is quite a bit of talk lately about unit testing using the extract method and override, or “inherit & override” method for stubbing out a method for unit testing.  Methods don’t have dependencies, and methods aren’t dependencies.

Objects are dependencies, and object have dependencies.  One object will depend on another object.  Objects are cohesive and present a contract of behavior so other objects know what behavior they can reliably leverage.  Because an object is cohesive, everything necessary to perform all its behavior can be passed into the object’s constructor at the beginning of the object’s life.  Then, that object can perform all of the operations.

In order to test a particular object, I might have to pass some fake objects (stubs, mocks, etc) into the constructor, but the object under test doesn’t care as long as the type is satisfied.  If I can’t test an object by passing in fakes to the constructor (and I can compromise sometimes by using setter injection), then the object is less than cohesive, and I should search the design of the object for an extra concern that is trying to get out.  Once I find the extra concern, I would separate the concern (separation of concerns) into its own object and have than as an explicit dependency by requiring it be passed into the constructor (dependency injection).

Michael Feathers outlines this extract method and override testing technique in his book, “Working Effectively with Legacy Code”, and I’ve used the technique many times to break nasty dependencies on legacy code in order to get it under test.  This is necessary because legacy code can’t be safely refactored until it has a safety net of test coverage.

If your unit test has to know that another method on the same object is being called, then the unit test knows too much about the implementation of the object.  The unit test should be doing black box testing on the object under test.  In other words, the unit test shouldn’t care about what code is written or if 1 method or 10,000 methods inside the object are actually called.  The unit test merely sets up explicit object dependencies and test state, interaction or both.

Recently, I was coaching a client who was embarking on a new project.  The project team was not formed, but key stakeholders were planning what the projected needed to be.  In Agile (specifically our Lean/Scrum/XP mix), we have iteration planning, release planning, and project planning.  This client is doing project planning, and the question came up about how to write stories for the project.  After all, we have to know the entire scope of the project in order to plan it, right?  Historical trends tell us that even if we think we know the full scope of the project, we’ll be wrong, so I helped this client identify the key components of the project to formulate the high-level project scope. 

If you like this post, you can subscribe to my feed at http://feeds.feedburner.com/jeffreypalermo

After we understood what the high-level requirements of the new software would be, we did a prioritization and created a backlog that we hoped would turn into a short-term first release.  With this rough release plan in mind, we did a small story-writing workshop.  We first wrote some stories together and then broke off into pairs to complete the remaining stories.  We concentrated on only the first release because that release contained the highest priority items (from the prioritized backlog).  We knew we were working on the highest value items first. 

Here is an example of a story (adapted from CodeCampServer as a realistic example):

"As an organizer I want to have a place to enter maps and driving
directions so that the attendees can find the event."

First, we have the persona of the organizer.  The organizer is in charge of the event and is doing the planning.  Often it’s helpful to give him a name.  We’ll call him Oscar the organizer.  Then, we can discuss what Oscar cares about to get a feel for how he’ll use the system. 

Your first thought is that this isn’t enough detail to formulate a release plan, and you’re right, but it’s a placeholder for a conversation with the team that’s going to make it happen.  I think a requirements document is also necessary.  Writing stories doesn’t take away the need to think about some level of detail while planning the overall project.  After all, when estimating the release, it’s necessary to know if driving directions merely means a link to Google Maps or if it means an interactive mapping system built into the application. 

Be careful about adding too much detail to the story because then people won’t read it.  If every story is a full page, it’s too long.  Story can act as headers in a requirements document, however, if you prefer to organize it that way.

Ok, buddy, but how will we know what the acceptance conditions are?  You need to know the high-level acceptance conditions, but I caution against laboring too much on small details of each story before the project has even kicked off.  You’ll paralyze yourself with analysis.  Define just enough detail to move to the next step, release planning.  By the time you move through iteration planning, and the team has asked all their questions, all the details will be fleshed out, and the team can turn the story into working software. 

Finally, get help from someone with Agile experience.  I’ve seen many people who have studies Lean/Scrum/XP struggle to move from use cases to stories with only academic knowledge.  There is no replacement for apprenticeship.

To get objects from an ASP.NET MVC controller to a view, you put the objects in a dictionary of sorts called ViewData.  ViewData is sort of a misnomer because it’s not meant to contain data at all.  It’s meant to contain objects.   By the way, if you like this post, you can subscribe to my RSS at http://feeds.feedburner.com/jeffreypalermo.

There are some challenges with ViewData as it stands now:

• A key is required for every object, both in the controller and view.
  ViewData.Add(“conference”, conference);
• A cast is required to pull out object by key.
  (ScheduledConference)ViewData[“conference”]
• The ViewPage<T> solution discards the valuable flexibility of the objectbag being passed to the view.
  <%=ViewData.DaysUntilStart.ToString() %> where ViewData is of type ScheduledConference

Facts (or my strong opinions):

• Repeated keys from controller and view increase chance for typos and runtime errors.
• Casting every extraction of an object in the view is annoying.
• Strong-typing ViewPage only works for trivial scenarios.
  – For instance, suppose once logged in, every view will need the currently logged in user.  Perhaps the user name is displayed at the top right of the screen in the layout (master page).  Since the layout shares the viewdata with the page, we immediately have the need for a flexible container that supports multiple objects.  A strongly typed ViewPage<T> won’t work without an elaborate hierarchy of presentation object that are themselves flexible object containers able to support everything needed.  Once you get there, you are almost back to the initial dictionary.

My proposed draft solution, the SmartBag:  (and a follow-up here)

• The SmartBag is currently only in CodeCampServer, but when it has proven it’s worth, I’ll move it into MvcContrib.  It’s used in the ConferenceController and the ShowSchedule view.  You can check out CodeCampServer at http://codecampserver.org.

public class SmartBag : Hashtable
{
    public T Get<T>()
    {
        return (T)Get(typeof(T));
    }

    public object Get(Type type)
    {
        if (!ContainsKey(type))
        {
            string message = string.Format("No object exists that is of type '{0}'.", type);
            throw new ArgumentException(message);
        }

        return this[type];
    }

    public void Add(object anObject)
    {
        Type type = anObject.GetType();
        if (ContainsKey(type))
        {
            string message = string.Format("You can only add one default object for type '{0}'.", type);
            throw new ArgumentException(message);
        }

        Add(type, anObject);
    }

    public bool Contains<T>()
    {
        return ContainsKey(typeof (T));
    }

• The smartbag implements IDictionary through HashTable, so it’s flexible, just like ViewData, but it has a powerful convention:  If you are passing one object/type to the view, we don’t need a key because the SmartBag can use the type as the key.  If you really need a Top conference and a Bottom conference, then you are back to using your keys, but for 80% (statistic I pulled out of my behind) cases, this works.
• If we introduce a layer supertype for our views, then we can just use it:

public class ViewBase : ViewPage<SmartBag>
{
    
}

• Then, all my views inherit from ViewPage<SmartBag>.

I’d appreciate feedback on this solution.  To me, it seems to be a good foundation and convention, but I’m sure it can be improved.  If this solution hasn’t been proven to be worthless, I’ll port it to MvcContrib so it can be used by MvcContrib clients.

There are several scripts floating around the Net regarding publishing an email to the development list every time someone commits a revision to Subversion.

In other cases, you may want to post the commit log entry directly to your project tracking system, such as trac, Rally, Gemini, Mingle, etc.  Anything under the sun can be coded into a post-commit action with Subversion.

Here’s how it works.  Here is how to send post commit email from Subversion while running on Windows:

In your subversion repository, there is a hooks folder.  This contains some template files for you.  On a Windows system, you’ll want a file called post-commit.bat.  This batch command will be run immediately after Subversion commits a transactional revision to the repository.  You can do work on other events, but I’ll focus on post-commit for this post.

Here is my post-commit.bat file that will call NAnt (which is placed inside the hooks folder for simplicity):

pushd .
cd DRIVELETTER:svnrepositoriesrepositorynamehooks
nantnant.exe -buildfile:postcommitemail.build -D:path.repository=%1 -D:revision=%2 > lastpostcommitrun.txt
popd

Notice how we are merely calling nant.exe.  The rest of the interesting work is done by NAnt.  Now that we are within NAnt, we can script out any action we might need.  In this case, I’m going to use some SVN command line tools to build up a simple email that with send developers what was included in the last commit:

<?xml version="1.0" encoding="utf-8"?>
<project name="commit" default="build" xmlns="http://nant.sf.net/release/0.85/nant.xsd">
    <target name="build">

        <exec program="svnlook" commandline="author ${path.repository} -r ${revision}" output="author.txt"/>        
        <exec program="svnlook" commandline="info ${path.repository} -r ${revision}" output="message.txt"/>
        <echo message=" " file="message.txt" append="true"/>
        <exec program="svnlook" commandline="changed ${path.repository} -r ${revision}" output="message.txt" append="true" />
        <exec program="svnlook" commandline="diff ${path.repository} -r ${revision} --no-diff-deleted --no-diff-added" output="message.txt" append="true"/>
        
        <loadfile file="author.txt" property="author"/>
        <loadfile file="message.txt" property="message"/>
        <mail tolist=jeffrey@mydomain.com
            from=build@mydomain.com 
            subject="SVN ${path.repository} - ${author}" 
            message="${message}" 
            mailhost="smtp.mydomain.com"/>
    </target>

</project>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

That’s all it takes.  I can write anything I need to in order to perform custom actions when things happen with my Subversion repository.  In this case, I’m sending email to a list, and the email contains the last commit.

There is a bit of confusion out there because R# 3.0.2 doesn’t immediately support code analysis and intellisense for the new C# 3.0 features like LINQ queries, etc.  What I’ve heard is that in Q12008, we’ll have a R# that will support all the new stuff.  While it’s a shame that it’s not ready to go immediately (because VS 2008 RTM is available as of this week), we can still us R# 3.0.2 with VS 2008 to get most of the value and ease of use we’ve come to expect from a productivity add-in.  Here are the steps:

First, the big problem is that when we start using new features in VS 2008, R# doesn’t cooperate because it doesn’t know about the new syntax that’s now available.  The on-the-fly code analysis goes haywire as depicted in the screenshot below:

Not only does the code analysis not work properly, but the R# intellisense we get doesn’t show the proper options with extension methods.  We’ll go to Resharper>Options and change two settings.  First, let’s turn off R# code analysis:

Next, we’ll tell R# to let VS give us intellisense since VS knows about the full options:

Now, if we look back at the code, all the red goes away, and our intellisense window has full support, like the “where” keyword in the LINQ query below:

With these two changes, we get rid of the immediate annoyances, but we can continue to leverage all the other great features R# gives us like file/type navigation, NANT/NUNIT support, etc.

If you have any more tips that would be helpful during the interim for using R# 3.0.2 with VS 2008 until R#4 comes out, please post a comment. 

. . .or it can be a lie.  In my last post, Evan commented that low cost only goes so far.  I see where he is coming from.  Let me illustrate.  If a consultant puts together a system very quickly and doesn’t pay attention to the quality and structure of the system, he can deliver quickly in the short term.  The client initially pays less money, and he is happy.  What actually happened was that the client received a lemon.  The software meets the initial requirements, but it has a handicap with intolerance to change (which is inevitable).  There are probably cobwebs lurking in every corner.  The same consultant will probably be asked to add features at a later time “because of the great job he did”, but the second revision will cost significantly more because he will be faced with the poor decisions made in the past.  The second project is unlikely to be as inexpensive as the first, and it is very likely to be bug-riden and unstable.  The initial software delivered was a pig with lipstick on it.  I compare it to a bridge that works great at first but starts to crack and shake as the years go by.

The above is not providing the lowest cost to the client.  It is front-loading cost savings only to defer the actual bill to a later time.  Credit.  Technical debt.  The first release incurred technical debt the client will ultimately have to pay back.

This is not my model for consulting, and in this post, I hope to educate you on real low cost consulting.

What is real low-cost consulting, and how do we maximize ROI for the client?.

First, we want consistent clients.  We want to serve the client so well that they come back for the next project.  That doesn’t happen if all we deliver is technical debt.  Here is the plan.  First, we start the project with very high standards.  No bugs.  We don’t plan for bugs.  We don’t allocate time in the project for bug fixes at the end. In fact, we give a warranty for the software.  If there is a bug found later, it’s covered under warranty.  We keep the software bug-free at all times.  When a bug is found (because, yes, it happens), it becomes the highest priority.  We fix bugs right away.  If a requirement/use case/story is found to be flawed or lacking analysis, then that is a separate issue that’s taken up with the client to find an acceptable course of action.  We are able to achieve this by building quality in.  All the fundamental principles come in to play: separation of concerns, cohesion, depending on abstractions, etc.  We use extensive automated testing throughout the project along with continuous integration to provide rapid feedback that everything that works continues to work.  After all, after the first feature is added, that feature is in maintenance mode from then on.  By concentrating on maintainability, the software serves the client well, both now and in the future.

But doesn’t that end up costing MORE?

No.  On the surface, it might seem so since our standards are so much higher, but the end result is a lower cost and, consequently, a higher ROI for the client.  Let’s examine how that works:  First, we ensure we are building the right thing.  That eliminates the waste of building the wrong thing.  Next, we start testing immediately, not at the end of the project.  That means that bugs are found immediately, not right before release.  When bugs are found/fixed immediately, there are never more than a handful of outstanding bugs, and many days there are none.  The software always works as expected.  Next, the architecture is of the highest quality, and it evolves over time.  With refactoring, the software is always well-suited to the problem. The code depends on abstractions and is therefore resilient to change.  New types can be added to the system for new features, and working code doesn’t need to be modified (open/closed principle).  There are so many interlocking practices that go into achieving this that it is hard to list them all.  We keep the build fast and clean so it provides valuable feedback quickly.  With quick feedback, we can course-correct to ensure we are always on the right track.

End result

The end result is a system delivered at the lowest cost possible, not just for the first release, but when the client asks us back for a follow-on release (which they do), we are able to repeat the process and deliver a 2nd, 3rd revision with the same results as the first.

But why doesn’t everyone do it that way?

It’s hard.  Very hard.  It hard to get the quality people that can make it happen, and it’s hard to find management that has the experience to make it happen.  

I don’t claim to have all the answers (because I don’t), and we are constantly improving over time, but I can say that delivering the highest in quality also ends up costing the least.