Christopher Bennage : Agile

What I Learned Playing StarCraft

Christopher Bennage — Mon, 31 Jan 2011 02:13:00 GMT

On March 31, 1998, around 10am, my then-manager Alex and I left the office we shared together and headed over to Electronics Boutique. Alex and I were both developers working for the IT department of an up and coming software company called PC DOCS. In those days, we didn’t have a corporate firewall. My desktop was a node on the internet. In fact, I was running a web server on it. A bunch of us would stay late after work, barricaded in other peoples’ cubicles, all phones on speaker, playing WarCraft II and Quake. Those were halcyon days. I was just about to turn 23. I was just about to get married.

Alex and I had headed to EB because it was Release Day for StarCraft. I don’t think that I had ever been so excited about a video game. Well, maybe once but that’s another story…

A few months ago, StarCraft 2 was released. While there wasn’t as personal ceremony this time, I still purchased it on Release Day.

This time around I decided to really learn how to play the game. In case you are unaware, StarCraft is huge. There are televised tournaments, professional players, and so on. In many ways, it’s analogous to chess. As I began to learn more about it, I found that there are certain tenets of gameplay and, as I mused on these, I found that they extend to life in general (though I’ll limit them here to a professional context).

The First Lesson

In the game, there are a dizziness amount of options. Your opponent can overwhelm you with astounding ease if you are unprepared for their particular tactic. So you might be inclined to try and prepare for all contingencies. But guess what? You can’t. You will end up spending all of your resources ‘preparing’. You think that this aligns with your overarching goal, but in reality it is a distraction.

Professionally, we are given a goal: build software that will do X. As developers we typically and immediately begin thinking about all the ‘what ifs’. Usually because we’ve been burned by them in the past. X is still in sight, but there is a long road to get to there, because we have to deal with Y and Z and so many other things. We have to be prepared.

The truth is that you cannot be prepared for everything. It is actually a waste of energy and a distraction from your real goal. In the game of StarCraft, if you try to prepare for everything, you will lose. Instead, you must choose your battles.

The Second Lesson

How do you know which battles to choose? Surely a battle is coming. There are always problems in every project. You can’t simply be unprepared. That’s suicide.

In StarCraft, the answer is scouting. That is, you gather intelligence about what the enemy is doing. Once you know, then you can prepare properly and efficiently.

Recently, I was asked about some performance concerns at the start of a project. Now, I have been seriously burned by performance issues. In fact, one of the worst software disasters I was a part of was a performance issue. Nevertheless, the concerns raised with granular and premature. As Donald Knuth said “premature optimization is the root of all evil”. Now, I am most emphatically not saying to avoid optimization. What I am saying is to scout, gathering intelligence and responding accordingly.

A Summary

I’ll sum up these two thoughts:

Don’t waste time on things you don’t need.
Find out what you need through active analysis.

None of this is new. In fact, you see pretty much the same things preached all over. I hear it in XP, I hear it in Agile, I hear it in StarCraft.

Epilogue

I’m reminded of a passage from G. K. Chesterton’s Manalive (chapter 3):

"Well," said the girl solidly, "what is there to wake up to?"

"There must be!" cried Inglewood, turning round in a singular excitement—"there must be something to wake up to! All we do is preparations—your cleanliness, and my healthiness, and Warner's scientific appliances. We're always preparing for something—something that never comes off. I ventilate the house, and you sweep the house; but what is going to HAPPEN in the house?"

Visions of Software Development or Can’t We Just All Get Along?

Christopher Bennage — Tue, 12 Jan 2010 11:38:00 GMT

I’m currently reading Thomas Sowell’s A Conflict of Visions: Ideological Origins of Political Struggles. As the title suggests, it deals with certain fundamental differences in the way we see the world and how that affects our political views. Don’t worry, I’m not going to delve into politics in the post. However, I was struck by how applicable the ‘visions’ in the book are to the competing (and conflicting) views about how we should write software.

Here’s a simplified sketch of the two fundamental visions in the book. (Note that I’m not attempting to make a judgment call here on which vision is correct or better. Though admittedly, I have my bias. Likewise, I’m necessarily keeping it simplified.).

Complex problems are best addressed by:
[a] systemic evolution or [b] clear and articulated reason
When a complex problem is addressed the result will most likely be:
[a] a set of prudent trade-offs or [b] a solution
Better results are produced when governance is provided by
[a] role and ritual or [b] well-educated individuals

This is just a few characteristics indentified in the book. We have a tendency to favor either the A answers or the B ones.

Let me unpack this now in terms of software development. I think that the philosophy of agile/software craftsmanship/etc has generally preferred the A answers. While more traditional software development has generally preferred the B answers.

Many agile practices (such as TDD) build up software through systemic evolution. (Tim Barcz touched upon this idea some time ago). Evolution is at the heart of iterative design. In opposition to this is a heavy initial design phase (or Big Design Up Front). In BDUF, the problem is analyzed and a clear, detailed path is laid out.
I think the second point follows implicitly from the first point. BDUF is a ‘solution’, whereas iterative development is inherently about trade-offs. By the term ‘solution’ I am implying that on such-and-such a date, the software will be delivered and the problem will be solved. The value is delayed, but it is complete. In an iterative project the goal is to deliver immediate, but only partial value. It acknowledges that some value is always omitted and that the software might never be complete.
The third point is one of the more divisive ones. I believe that agile practices focus a lot on ritual. TDD is a ritual. (I believe there was a Hanselman interview with Robert Martin that discussed this point). Kaban, Scrum, and other similar practices are ritualistic. These rituals are the soil where the systemic evolution grows. On the opposing side, development teams are led by architects. That is, by well-educated and intelligent individuals who have a greater understanding of what needs to be done.

My Bias

It is always important to admit your bias. I tend to favor the A answers above, though not always. I have been in circumstances where that approach broke down.

Regardless, I highly recommend the book as it has given me a lot of insight into my own views and those of others.

Refactoring Relationships

Christopher Bennage — Sun, 09 Aug 2009 01:45:00 GMT

Working with people is a lot like working with code. New relationships are green fields. Over time they become brown fields and (just like code) they require maintenance. I’m sure that everyone reading this can identify some legacy relationships that they would describer as, well, complicated. Just like some legacy code.

I mean a lot with the word ‘relationship’. I have in mind everything from co-workers to friends to significant others. These variations all require maintenance and I think we should deliberately structure our relationships so that maintenance is easier.

Interaction Smells

So what is the social equivalent of a switch\case statement?

We talk about code smells in software development as suggestive indicators that something is wrong. In our relationships, it is interaction smells. I would consider these common emotional responses to be smells:

avoidance
irritation
suspicion

Personally, I have been guilty of avoiding someone because I thought I would irritate them and I didn’t want the hassle. This was in a work environment and it a negative effect on the overall efficacy of the group. My impulse to avoid was a smell and it led to a problem that needed to be addressed.

Amicability Debt

Bad code gets worse over time. We call this technical debt. Relationships that have soured do not get better by themselves. Little fractures grow over time. If we don’t address them when we smell them, the stink only gets worse. In addition, the stinky relationship can be begin affecting other parts of design, uh I mean, other social interactions (e.g., the team you are working with).

Refactoring the Relationship

Relationships are more difficult to work with than code for one primary reason:

You cannot revert back to the last revision if your changes fail.

Nevertheless, we often need to make changes. Refactoring code doesn’t change the exposed functionality, but we make internal changes to improve it. If you are beginning to have problems with your boss, that doesn’t necessarily mean it’s time to quit (change the function) rather you might just need some relational refactoring.

But what do I mean by refactoring a relationship? Well, there’s a lot to be said there and you can find a lot of practical advice on dealing with conflict and more over on “Doc” List’s blog.

In brief though, I mean this:

Be honest and humble. “Hey, Joe, I feel like you’ve been a bit on edge with me. Did I do something to frustrate you? I’d like to clear the air.” Then talk it over. Again, refer to Doc’s blog for lots of details.

I would like to qualify this further. Since you cannot revert what you say and do, you must be deliberate and thoughtful about your refactoring.

Afterword

You can see where my brain has been lately. It’s the cross-pollination of ideas from software development into all other human interests. Next week: multithreading and Italian cooking, followed up by ALT.NET and comparative religion.

If any of this resonates with you, you might be interested in (a possibly controversial) post regarding the maintenance of marriage on my personal blog.

Agile Living

Christopher Bennage — Wed, 05 Aug 2009 03:14:00 GMT

I yearn to be consistent. I want my professional values to be the same as my personal ones. This is why I was quick to sign the Agile Manifesto; it aligned with my personal values.

I have been overcommitted for the last couple of months and the stress has forced me to do some professional reevaluation. I had a number of entrepreneurial and professional books on my back log. One of the book was The 4-Hour Workweek by Timothy Ferriss.

I really like this book.

That’s nice, Christopher. Thanks for sharing. What does this have to do with software development?

Not a lot. Perhaps. But I think it has a lot to do with the philosophy of Agile.

Eschew BDUF

One of the first ideas in the book is that the notion that retirement is a bit silly. We spend forty something odd years saving up money to retire and for what? How do we really know what to save up for? Do we honestly know what our requirements for old age will be? The standard cultural approach to professional life is Waterfall. We spend so much time building our product, and we have one big rollout.

Iterative Design

I recently watched the film Holiday with Cary Grant and Katharine Hepburn. In the movie, a young and savvy Johnny Case (Grant) struggles between Doing Business (because that’s sensible) and taking time off to figure out what he wants out of life. Ferris makes a similar proposition in the book. He suggests planning mini-retirements. It’s a release often, release early approach to life. Discover what you want you by trying things out. It’s Life in Sprints.

Illusion of Slackness

Agile has had a bad rep for being unstructured and lacking in discipline. Of course, practitioners of Agile know the exact opposite is the case (and let that be a life lesson in itself). One of the things I love about Agile is the focus on delivering value. Likewise, my initial perception of the book was that it was a guide for the lazy; just another Get Rich Quick scheme. No, it’s about being deliberate with your life. It’s not a book that most people can use, because it requires disciple.

Eliminate Waste

If I’m being technical, I guess I would say that this is a Lean principle. However, Lean and Agile are complimentary ingredients in the tossed salad that is my head. Ferris applies this principle to all of life. It’s a beautiful thing. There’s a lot of waste in our lives, hidden under the veil of busyness. Find it and eliminate it. Repeat.

Conclusion

Okay, so I guess this turned out to be a book review of a non-technical book. If any of this stirs your brain, then I recommend that you read the book. If you are compelled by the ideas of Agile or Continuous Improvement, read the book.

My Advice: be deliberate with your life, your professional, and your time.

“… the unexamined life is not worth living…”
Socrates, Plato’s Apology

“Whatever your hand finds to do, do it with all your might, for in the grave, where you are going, there is neither working nor planning nor knowledge nor wisdom.”

Kohelet 9:10

Idealistic vs. Practical

Christopher Bennage — Tue, 24 Mar 2009 14:05:09 GMT

I often identify myself as an Agilist. When I first began to use the term, I was met with a great deal of trepidation. I remember the first few times I attended the local user group. “Oh, you’re one of those guys”. This hesitation has diminished considerably, but I still find that there are some interesting misconceptions about agile.

For example, people frequently contrast Agile with Pragmatic.

“Oh, I’ve heard about SOLID principles (or whatever), but I’m really more pragmatic.”

This has actually made me laugh out loud. You see, it was pragmatism that drove me towards the agile philosophy.

According to Meriam-Webster, pragmatic means:

relating to matters of fact or practical affairs often to the exclusion of intellectual or artistic matters : practical as opposed to idealistic

So here is the relevant contrast:

Idealistic vs. Practical

Is Agile idealistic or practical? Agile does embraces a set of principles (ideals) and I’ve seen many of its adherents become drunk with the beauty of it. I’ve been there a few times myself. So yes, it is idealistic in that respect. However, I think a better question is this:

Is Agile merely idealistic?

There is a strong idealistic streak in Agile, we will not deny it, however the ideal is actually “get work done”. In other words, Agile is the art of pragmatism.

I am motivated by success. I am motivated by accomplishing things. The quickest route to depressing me (or frustrating me) is to prevent me from getting work done. Because of this, when I first encountered the agile idea that change is expensive and therefore we should reduce the cost of change, I was listening. When I discovered that agile methodology offers a set of tools for reducing the cost of change, I was ecstatic.

In the interest of being brief, I’ll jump to my conclusion:

The application of the agile principles is about being successful in software development projects. It is not ars gratia artis. While some enthusiasts may forget that, it doesn’t change the nature of the underlying principles.

Agile is the art of being pragmatic.

Solving Problems with TDD

Christopher Bennage — Thu, 06 Nov 2008 20:03:00 GMT

I'm giving a talk on TDD at our local UG tonight, and under the influence of some recent posts here on devlicio.us, I just finished reworking my presentation. This post is an outline for the first half of my presentation.

The Problems

Code has entropy. That is over time it deteriorates. At least, that's the metaphor we developers like to use. What is really means is that the code becomes harder to maintain and extend as it is maintained and extended over time. Did you follow that? Our typical approach to maintaining and extending code causes the code to become fragile and rigid and thus harder to maintain and extend in the future.

There are three common difficulties that arise, maybe more, but I'm focusing on three:

Unchangeable Code
Unintelligible Code
Unnecessary Code

A portion of code becomes unchangeable when its deeply entwined and entangled with other portions of code that have different responsibilities. You can't change method X because we really don't know what that will do to Y and Z.

Code can become unintelligible for lots of reasons: abbreviated names, circuitous logic, enormous methods, confusion of responsibilities, use of php☺, etc.

Finally, unnecessary code is code that is not used by the system. It can be vestigial, or as often happens, it can be the result of feature anticipation. We thought this was going to be needed in the app, so...

The Solutions

There are some generally accepted solutions to these three problems.

In the case of unchangeable code, we can apply such patterns as Separation of Concerns (SoC) and the Single Responsibility Principle (SRP). For addressing unintelligible code, we have a number of techniques such as thoughtful comments, explicit naming, SRP again, etc. Finally, for unnecessary code we have the old axiom of You Ain't Gonna Need It.

Okay, so we know how to solve the problems. Or least, we know how to mediate them. So what? What does that have to do with TDD?

My proposition is this: solutions are without value unless they are applied.

Additionally, when a problem occurs over time, the solution must be applied over time.

The Analogy

I just started going to the gym. It's been about a decade since I did that, but I'm back. For the past several years however, I have been preaching to certain family members the value of exercise and healthy diet. I knew the benefits: stress reduction, longevity, improved sleeping, and just plain feeling better. However, I wasn't really doing either.

I had the problem and I believed in the solution and, in fact, I made attempts to employ the solution. Ultimately, I was unsuccessful. That is, until I committed to go to the gym three days week at a set time and with a workout buddy.

My point is this, we are human beings and despite being smart we frequently revert to doing "the easiest thing". Therefore, we ought to set up some sort of framework of methodology or discipline where the easiest thing is actually what we want to do.

Additionally, I have to keep on going to gym. For as long as I want to be fit, I will need to exercise. In the same way, for as long as I want my code to fit I will need to apply good principles.

TDD as a Discipline

I will argue that TDD is a discipline that enables the application of the solutions outlined above. Perhaps you apply those solution naturally. Perhaps you can benchmark 200lbs because of your genetic disposition. Bully for you. Go ahead and skip the rest.

Let's examine a few essentials of TDD and see if they really address the problems we outlined.

Test First

I'm an advocate of automated testing in general. However, I do think that writing your tests first yields additional value. Primarily, it helps you discover your ideal API. In other words, you can design your API up front such that it is more intuitive. More intuitive means easier to understand.

Secondly, testing first helps you identify dependencies early. You quickly discover that class X will need a Y and so you are forced to create seams in the application at the onset. This encourages SoC and SRP.

Testing Units

It took me a long time to understand the "unit" part of unit testing. The idea is that you decompose your problem into units, and deal with the problem one unit at a time. You could call this "test just one thing". Okay, well what is "one thing"? That is hard to tell and comes with experience. Nevertheless, the practice of trying to decompose a problem and identifying units leads you back to SoC and SRP again.

Just Enough Code

Another tenet of TDD is to write only enough code to pass the test. Our natural instinct is to anticipate. It is part of what we are as developer, and it is not a bad thing. However, like many strengths, it can become a weakness. By constraining ourselves to a single problem at a time we will end up with less code. It also forces us to be conscious about our anticipation and to ask if a given scenario is really necessary.

Conclusion

I know that there is much contention over the actual value of TDD as a practice, and I am not going to force it on anyone (unless I hire you and now you are warned). However, I have found it to be a useful discipline for helping me to overcome common problems and because of that I encourage it's use.

ALT.Consultancy: Reflections on doing it my way

Christopher Bennage — Sun, 18 May 2008 23:48:32 GMT

Awhile back there was some discussion on the new ALT.NET list about what it would be like to start a consultancy with a bunch ALT.NET minded people. The hypothetical scenario proposed there wasn't quite what I did, but I thought I'd go ahead and share my experiences and how we addressed (or are still addressing) some of the problems in running a business like this.

The Background

Rob Eisenberg and I founded our company Blue Spire in October 2006. We were long time friends, and had worked together for about two years prior to starting the company. In that time, we were learning about Agile in general, as well as patterns, TDD, OR/M, the myriad of awesome OSS tools, etc. We didn't know it, but we were developing a culture between the two of us. The elements of this culture included:

continuous learning
passion for our craft
learning to "code without ego"
excitement about "doing things better" and discovering "better practices"

We started our consulting firm with the belief that we could deliver quality, human friendly software in less time and for less cost that the majority of other firms. (The genesis of this thought occurred over a decade ago when I was subcontracting for a large consulting shop, working on an 18 month project with a team of around 25. I'm sure I was pretty cocky back then, but I felt at the time that a team of 5 could have delivered more in less than a year.)

We began with just the two of us, and we envisioned growing to a team of 4 to 6. Smaller is better. Even at the beginning though, we felt that consulting was just a stepping stone to something else.

Kicking It Off

The question was asked on the list if such a shop could compete. What kind of sales and marketing would you need? How do you break in and demonstrate to potential clients that you can provide a better value than super consulting company X?

We've had zero down time since we started, and we've had almost zero sales and marketing efforts. We started off having lunch with other software development shops in the area. We told them what we were doing (without being derogatory) and we talked about overflow work, and subcontracting. There's enough business out there that the competition is pretty friendly. We also offered ourselves at very, very reasonable rate. (We're now charging double from what we started, and we're probably going to raise our rates again this year.)

The majority of our clients have been other software shops. What's cool is that they saw our value pretty quickly. What's bad is that we were sometimes restricted from using the practices and tools that we wanted.

We also decided it was important to connect with the local developer community. Both for our own continuing professional development, but also for growing the reputation of our company. Rob has especially put in efforts to speak at Code Camps, and the local user group. It helps that we are genuinely excited about sharing. (This even helped us land a really fun agile coaching gig for the internal development team of a state agency.)

Convincing Clients

We've focused on Scrum for project management, and we were lucky to have a client who was already intent on using it. Nonetheless, even that client (who was not a software shop) required a statement of work. We estimated as best we could, and the client agreed that the SOW was a target and not a guarantee.

In our "sales pitch", we tell clients that software development in inherently unpredictable. We contrast "release early, release often" with "throwing the spec over the wall". (There's usually a lot of resonance if they've had software developed before.) We (cautiously) explain to them that no one really knows exactly what they need up front. Change is inevitable.

What Really Happens

Our projects have usually taken one of the following forms:

The client budgets a set amount of hours. We provide a conservative statement of what we think can be accomplished in that time. We explicitly qualify the risks as soon as they are known.
We get the client to buy into the project, by allowing them to manage the priorities for each iteration in the project (usually 2 - 4 weeks). In this way, they share the responsibility with us for hitting the desired target.
Because of the iterative nature, they are aware of risks and problems early.
Some client are too deeply rooted in the idea of "build me X, in Y hours, for Z dollars". We try to avoid that situation, but we've been there. When that occurs we greatly exaggerate the hours (3x or 4x). Funny enough, the exaggerated estimate is often within the client's expectations. We've alternately benefited and been burned by this arrangement. I don't like to do it this way.
This last arrangement is a mixture of the other two, and it's only been useful for periods where we would would have been between projects and when a client has some flexibility in scheduling. Essentially, we budget some initial time to size tasks. Again we pad the hours to mitigate risk, and then we allow the client to pick and choose the tasks. We commit to delivering an individual task for the number of hours we estimated, but we are not committed to delivering the entire project for a set amount.

The first option is preferred and honestly it is the one that provides the most cost effectiveness for the client. We only use the other arrangements when the client isn't comfortable with the first.

Some Final Thoughts

Here's a few additional observations:

Having the right clients is paramount. You want a genuine trust relationship. We had one project where trust was eroded (if it was ever present on their side) and it was by far the most stress I've had in years. It's hard to turn down business, but sometimes you really need too.
Scheduling is difficult. Managing the pipeline is one of the more difficult tasks in managing a small shop. When is this project really going to be over? What if the client wants to extend? How much downtime can we afford? At what point are we over extended?
Everyone that I've talked to that has a small project-based business seems to have the same difficulty. So far, we haven't made any clients mad, but we've had a few periods of overtime. This would be easier if we were a larger company, but size has many disadvantages too.

I'm a developer at heart, and running a business has been challenging (and distracting). So I'd love to hear from anyone else who is doing this sort of thing.

Thoughts on ALT.NET

Christopher Bennage — Sat, 15 Mar 2008 21:39:00 GMT

I just listened to Scott Hanselman interviewing Dave Laribee regarding ALT.NET. I really like what Dave had to say, and I encourage everyone to go and listen. I've been reticent about the ALT.NET movement (aside from my initial surge of enthusiasm.) I'm a bit shy when it comes to controversy, and even though I have strong evangelistic tendencies, I am also quick to shut up. ALT.NET has had its share of controversy.

I really like that Dave said it's not about the tools, it's about the principles. I am frequently asked about "good design" and "best practices". This is why I'm ALT.NET. (In fact, I have a series of posts on this topic that I intend to start after we're done with the book.)

There's an item in the interview that I'd like to comment on.

Scott asks (pardon my paraphrasing) why would the hypothetical Chief Architect of the Nebraska Department of Forestry have any interest in ALT.NET? The mythical Mort has pressing concerns, he just needs to get work done, why would he care about these conversations, discussions, and principles? Listen to the podcast for Dave's answer. However, my answer is this: he probably doesn't care and that's okay. I think that ALT.NET is about bringing good design and principle to the forefront. However, good ideas take a while to be adopted, to be democratized. Those who are hungry, we'll feed. Those who aren't, we'll wish them well. No hard feelings. Eventually, the good ideas will be institutionalized and they'll trickle down. (Have you noticed the "refactor" menu in Visual Studio?) I'm more concerned about convincing the institutions and the thought leaders. (Perhaps "convincing" is the wrong word, ALT.NET is more about "conversing" to me.) That's why it's good that ALT.NET is conversing with Microsoft, and that's also why I'm encouraged to see Microsoft paying attention to things like open source (though I know many people are angry about the kind of attention being paid).

Now go learn Ruby! :-)

The Words We Use

Christopher Bennage — Thu, 07 Feb 2008 15:50:48 GMT

I just read this great post by Jimmy Bogard over at Los Techies. He talks about user stories and the fact that what you call a user story is very important. (A rose by another other name would not smell as sweet. ) Words affect how we think about things; though we don't like to admit it. I've definitely struggled with this myself.

If you ever communicate with your clients, then I recommend checking out the post. It's short too.

I particularly like his comment that prioritizing a requirement is like putting lipstick on a pig.

Continuous Integration with Draco.NET

Christopher Bennage — Sun, 12 Aug 2007 19:37:00 GMT

At our most recent .NET users group meeting, Joe Healy asked for a show of hands for those doing Continuous Integration. There were about 40 of us and (I'm pretty sure) no one raised their hand.

A few years back, I had a NAnt script that was scheduled to execute nightly (you could also call it manually via a classic ASP page). The script would grab the source from Subversion, build it, execute some SQL scripts to construct a fresh database, bcp in some data, and finally publish the Web application to the staging server. (Notice that I didn't mention anything about unit testing). This was the closest I ever got to Continuous Integration, and I was tempted to raise my hand.

Why I didn't do it...

I've thought about CI many times over the years, but I kept putting it off. The configuration challenge was always a bit daunting. A couple of months ago, I started to get excited again after watching the dnrTV episode on CI Factory. However, even with the simplification brought about by CI Factory, it didn't quite seem worth the effort. (I should punctuate that we are still a small shop operating in teams of 2 or 3).

I had mostly experimented with CruiseControl.NET in the past, and the configuration was more than I wanted to deal with.

I Value Simplicity.

Or as Ayende might say Zero Friction. I imagine that CC.NET might have been zero friction to use, if I had ever gotten past the setup. (I will readily admit a good deal of laziness here).

After Joe's admonition about not doing CI, I asked Google about my choices for CI in the .NET world and it reminded me of Draco.NET.

I installed Dract.NET, and I was happily doing CI within an hour.

How to configure Draco.NET

Specifically, I will step through how I set it up to work with Subversion 1.4.4 and NAnt 0.85.

Download Draco Server 1.6.4 from here.
The installer will create a service named "Draco.NET".
In order to have this service work properly with NAnt I had to run it under domain account. (At first I used Local System Account with Allow service to interact with desktop, but it reported a File Not Found when it attempted to call nant.exe.)
Add the bin directory for NAnt to your path. Additionally, I copied the some assemblies from NAntContrib and MbUnit in the NAnt bin directory in order to access tasks for msbuild and MbUnit within my NAnt script.
The install will create a directory at "C:\Program Files\Draco.NET Service" and place two config files in a subdirectory bin.
The default Draco.exe.config is fine, but I recommend taking a look at it.
The other file, Draco.builds.config, tells Draco what projects to monitor. It can point to many projects under diverse source control.
I deleted all of the <build/> nodes expect for the one referencing Subversion. You will have one <build/> node for every project the server monitors.
Inside the <build /> node:
<name /> is merely a unique name to identify the project.
<nant /> tells Draco to use NAnt to execute the build process, and points to your build file within the source that it checked out.
<svn /> tells Draco the repository that it will monitor for this build. You'll probably want to create a readonly account for Draco to use.

What Draco does

Aside from hating Harry Potter...

Draco will poll the repository in the build every 60 by default. If it finds any modifications since the last build, it will wait for the repository to be quiet for a designated amount of time (again 60 seconds by default). Quiet means no further commits during the period. After the repository been quiet, it will check out the source to a temp directory and then execute NAnt script.

At this point, it is really up to your NAnt script. Currently, mine is very simple. It calls msbuild to compile the solutions, and then calls MbUnit to execute the tests.

Monitoring the Build

Draco.NET has a client for monitoring the status of builds available here. I installed 1.6.4, and it did not add anything to my start menu.

It installed a help file to this location:
C:\Program Files\Draco.NET Client Tools\Draco.chm

And a monitoring app that runs in the systray here:
C:\Program Files\Draco.NET Client Tools\bin\DracoGui.exe

In addition to monitoring, you can:

Start Build - which tells Draco to check the repository for modifications, but only starts the build if there has been a change.
Force Start Build - which kicks off a build even if there no modifications.

Finally, there is an install for monitoring builds over the Web, but I haven't played with that yet.

Scrumming for the first time

Christopher Bennage — Fri, 03 Aug 2007 21:54:00 GMT

We finished our second sprint today. In fact, I just left the Sprint Retrospective Meeting (which was actually quite brief).

We've been very lucky to have a client that insisted on using Scrum to manage the project. Before this I only had a cursory knowledge of Scrum. We are a small shop, and while we've been influenced significantly by Extreme Programming (XP), we haven't had the mass to implement all the practices we'd like.

What is Scrum?

I discovered quickly that I had a misconception about Scrum. I had assumed that it was just a different flavor of the same thing as XP. But there's a difference of scale, Scrum is about managing a project, or multiple projects. Within Scrum you might have multiple teams, and each of those teams is responsible for Self Organizing. XP is one way for a team to self-organize. In this way, XP fits nicely inside of Scrum.

I began reading Ken Schwaber's book just before this project started. I highly recommend it. It is a set of case studies discussing how Scrum works, and it comes across as honest and realistic.

The significant parts of Scrum, as adapted from Ken's book, are:

Scrum Master - The individual responsible for managing the Scrum process. The Scrum Master's job is to facilitate the project. On our current project, this role is filled by our client's IT Director.
Product Owner - The representative of the stakeholders. An individual responsible for making the final decisions about what needs to get done. On our current project, this role is filled by an employee who was a Power User of the legacy system we are replacing.
The Team - The people responsible for doing the work. In this case, it's my company.
Sprint - Typically, a sprint is a 30 day span of time, during which the team is working toward a specific goal. On our current project, sprints are just two weeks (some XP influence here). I think 30 days is preferable though.
Product Backlog - this is the list of requirements. It can always be added to. In our case, it is a list of User Stories. Each sprint begins with a meeting to decide which stories from the Product Backlog will be worked on in the upcoming sprint. The stories that the team commits to are then moved the Sprint Backlog.
Daily Scrum - A daily, but brief meeting, where the Scrum Master has the the team answer three questions: What did you do yesterday? What are you doing today? And what is getting in your way?

First Impressions

I will first acknowledge my basis: I believe in Agile methodology and the concepts underlying Scrum resonate with me.

But how does it shake out in practice?

I think that Scrum is a great way to manage software projects. Possibly, the best that I have attempted. However, based on my limited experience here are few things to consider.

It is hard to write good user stories. I've struggled with this for several years now, and I hate to admit it. The problem mostly lies with my tendency toward optimism. We'll write some initial stories, they'll sound great to the stakeholders. We commit to delivering them by such and such a date, then we begin to realize that we left out a number of prerequisites. I always pad my numbers, so it has always worked out, but it feels too much like guess work to me. (I have Mike Cohn's User Stories Applied on my desk, but I have to finish finding out what happens to Harry first.)

The mechanics of tracking are awkward. We've been using TargetProcess to keep track of the Product Backlog, monitor burn down, etc. I had used version 1.x and I liked it, however 2.x is a little overkill I think. I believe that it's likely a great tool, but I lack the patience to overcome the learning curve, at least at the moment. 4 x6 note cards are becoming more and more attractive to me. (I also like white boards!)

Ok, so neither of these caveats is the fault of Scrum. However, they both fall in a region that Scrum leaves undefined.

Finally

I think it is hard to sell Scrum to a client. We are a consulting company. Our clients come to us and they want to know exactly how much they will spend to get custom software. We all know that it is inherently impossible to predict the cost of developing custom software. Scrum (and agile practices in general) acknowledge this and provide a solution. However, clients still want a commitment to deliver X for Y amount of money in Z amount of time. It is hard to convince a client to work with something "open-ended" like Scrum. (I think that this is not a problem for in house projects). Again, we've been very been very blessed to have a client who understands custom software development and asked for this.

Best Practices, Training, & Tools

Christopher Bennage — Mon, 18 Jun 2007 20:44:00 GMT

We were recently contracted to assist a development team in employing some Best Practices. Specifically, they were interested in learning Agile.

We began by speaking with the developers and managers to try to determine what would benefit them the most. We were only given three weeks to teach/guide/coach, and we knew that we could easily overwhelm them and thus provide no value.

After the initial exploration, we decided to focus these ideas:

TDD\BDD
O\R M
MVC/MVP (they have a focus on Web development)
Iterations, User Stories, Planning Game, etc.

We were also sprinkling bits of Domain-Driven Design through-out.

What surprised me about this experience is that fact that I could not teach these concepts without discussing the supporting tools. Maybe this seem strikingly obvious, but it did not occur to me until we were outlining the agenda for our daily training sessions. It went something like this:

Monday, MVP & WebForms
Tuesday, MVC & MonoRail
Wednesday, NSpecify
Thursday, NHibernate

Ayende already hit on this idea, but I guess that it did not sink in for me. I love these tools, but I just wish that they were not so conspicuous in what I consider to be a better way of doing software development.

...

It occurred to me later that some future generation of developers will very rarely think about all of this, in the same way that I so infrequently think about memory management and garbage collection. I believe we are in a transition (and maybe it's always in transit). Best Practices are always trickling their way down lower and lower into the stack, as Software Development moves from combing letters into words towards writing poetry.

Sam's List

Christopher Bennage — Thu, 25 Jan 2007 19:47:00 GMT

I've been overloaded lately with my infant .NET consulting company, and I have to apologize for the lack of consistent posts.

I just read a terse, but very insightful post from Sam Gentile. You'll need to dig into it and read the cross links, but it's a worth the while. Basically, he's covering the techniques and technologies that he employed over the last 14 months on an enterprise scale project.