James Kovacs' Weblog

InfoQ has made another of my DevTeach talks available online – TDD/BDD as Architectural Tools. Enjoy!

TDD/BDD as Architectural Tools

As architects, we have all experienced the folly of BDUF (Big Design Up Front) – spending weeks or months perfecting an architecture that fails when it meets the real requirements and real code. Is it possible to design in the small? How can we avoid unintended complexity, which cripples so many code bases? Can we build enough of an architecture to start writing code and then flesh out our architecture as the code evolves? In this session we examine how Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) allow us to solve these conundrums. We will see how we can use TDD/BDD to focus our architectural efforts in the high-value areas of our code base to achieve just-in-time architecture.

A friend just pointed out that my presentation on “Convention-over-Configuration in an Agile World” is being featured by InfoQ. (The speaker is always the last to know.) I’m honoured and humbled by the great responses from folks. Worst criticism so far is that the presentation isn’t about TDD/BDD. Well, it’s not. Here is my original description:

Convention-over-Configuration in an Agile World

As developers, we spend an inordinate amount of time writing “glue code”. We write code to transform database rows to domain objects… domain objects to view-models or DTOs… We write code to configure inversion of control containers and wire dependencies together. We write code to style our UIs and respond to UI events. Wouldn’t it be nice if this could happen automagically for us? This session will look at using convention-based approaches using Fluent NHibernate and Castle Windsor to reduce the amount of repetitive code and accelerate application development.

So check it out and let me know what you think…

[Originally published on Telerik blog here. Republished with permission.]

As developers, we like to believe that only raw data matters. And what is more raw than the written word? Does this mean that email is a more efficient communication mechanism than in-person meetings? Email contains just the raw words of our intent, right? The receiver can scan through looking for relevant content. Their computer can index and search our email. Why don’t we communicate everything in email? We’ve all experienced the miscommunication that can happen in email. So what are we missing?

The reality is that humans are social animals. We are attuned to many communication side channels – tone of voice; verbal pauses; facial expressions; body language. These side channels communicate additional information above and beyond the written (or spoken) word. What we are effectively doing with these side channels is increasing our communication bandwidth and when it comes to communication, more bandwidth is better. Just like increasing bandwidth in your computer network means pushing more bits of data per second through the pipe, you can do the same thing with your personal and team communications. Arranging some common forms of communication from lowest to highest bandwidth.

• One-way text (email/tweet/txt)
• Two-way text (IM)
• Voice
• Video
• Face-to-Face

As you go from low to high, the amount of information communicated per unit time increases and the likelihood of asking for clarification goes up. You’re much more likely to ask for clarification on an uncertain point when talking to someone than when you’re texting. Having to craft a reply creates a certain amount of impedance and if you’re fairly certain you know what the person is talking about, you won’t send that clarifying text or email. When talking, you’re much more likely to simply say back, “Let me see if I understand what you’re staying” and proceed to paraphrase your understanding of what they said.

Let’s look at daily stand up meetings as an example of high-bandwidth communication. The purpose of the daily stand up meetings is to keep team members apprised of progress on the project. Daily stand up meetings aren’t the only way to do this. Everyone could write daily status reports. Or the project manager could walk around asking everyone for a verbal update. Or team members could update a central progress report wiki. But most successful agile teams use daily stand up meetings. Why are daily stand up meetings more effective than the other techniques? It all has to do with communication bandwidth…

Let’s say a team member emails everyone, “I’m going to finish the enrolment feature on the website today.” Sounds great. No reason to doubt them. Now let’s say that they say exactly the same thing in a daily stand up meeting, but now you notice that they say it while avoiding eye contact with other team members and shuffling their feet? Most people can tell that the developer is quite uncertain about their ability to accomplish the task today. Same raw information, but you’re receiving additional information from the communication sideband of body language. If the developer instead said the same thing, but looks other team members in the eye and says it with confidence in their voice, other team members will feel more certain about the task being completed. (If the person has been saying the same thing for a week straight now, the team has a different issue to deal with – that of honesty and integrity in communication.)

Knowing why agile teams value daily stand up meetings also helps us compensate when face-to-face stand ups aren’t possible or feasible. Let’s say that we have a geographically dispersed team, video calls are going to have higher bandwidth than a voice call or emails. Similarly if the geographically dispersed team is centred in two different locations, it would be better to have two separate face-to-face meetings linked by video rather than everyone calling in separately via video conference. The team’s goal is to maximize efficient information exchange between team members as much as possible.

Daily stand up meetings aren’t the only way that agile teams leverage high bandwidth communications. Other examples include:

• Pair programming: two developers focused on solving a single problem
• Team rooms: immersing project members in team-related communications
• User stories: a reminder to have a conversation with a stakeholder
• Story walls or Kanban boards: surrounding the team in relevant project data

In each of these cases, successful agile teams use high bandwidth communication to facilitate understanding between team members and with other project stakeholders. Notice that story walls and Kanban boards are a form of non-verbal high bandwidth communication. Team members and stakeholders can quickly glance at the board and see the current status of their project. A well-placed board cannot help but be noticed often and frequently throughout the day. It is a constant visual reminder of what the team is doing and where it is at. It often becomes a focal point of conversation and acts as an information radiator about the project.

This isn’t to say that teams should avoid written communication, but use it when it’s appropriate. Written communication is more easily archived and searchable than verbal communication. Good written communication summarizes and condenses a lot of information into a more useful form. Written communication also decouples the availability of the sender and receiver. If you need a new server set up or need to confirm a meeting time, often a quick email is more efficient than standing outside someone’s office waiting for them to have a moment to talk to you. The lesson here is use the appropriate form of communication for the job at hand. And next time you’re having trouble understanding an email from a team member or project stakeholder, don’t hesitate to increase your communication bandwidth by picking up the phone or inviting them out for coffee…

[This post was originally published on the Telerik blog and is reproduced here with permission.]

“Our team is agile because we stand up for meetings!” It’s the perennial joke of the agile community. We’ve all heard of teams that feel that they are doing agile development because they stand up for their meetings. (I sincerely hope that it is more urban legend than truth.) The reality is that there is more to agile than stand up meetings and there is more to stand up meetings than simply standing. Let’s look at some of the key aspects of the stand up meeting and how you can make yours more effective.

Just the Facts, M’am

At the heart of the stand up meeting is each team member answering three questions:

1. What did I accomplish yesterday?
2. What am I doing today?
3. Are any impediments blocking my progress?

The focus of these questions is progress. Each team member should be asking himself or herself, “How is my work progressing and is anything preventing me from being successful?” It shouldn’t be about excuses or recriminations. The stand up meeting is meant to be an honest appraisal by the team members of the current status of the project.

Same Bat Place, Same Bat Time

If you need Outlook to keep track of your stand up meetings, you’re doing something wrong. Keep them at the same time and same place every day – preferably first thing in the morning and close to where the team works. It gets the whole team off of the right foot and sets the cadence for the day. By keeping the time and place consistent, you don’t lose time “gathering the troops”. If team members need to coordinate on a task, they can arrange it at the beginning of the day. If there are any impediments that need tackling, the team can figure out how to tackle them together without wasting time waiting for the stand up meeting.

Keep It Short

Stand up meetings should be short and to-the-point. They should take no more than 5 or 10 minutes. Even a large team of 10 to 12 people can finish a stand up in about 10 minutes if everyone stays focused on the three questions above. The focus is on making sure the entire team is on the same page and heading toward a common goal. If meetings are taking longer, this is usually because team members start trying to solve problems rather than staying focused on reporting their progress. As developers, we love to solve problems and it takes a great deal of discipline to not start offering solutions when someone has a problem or you think of an elegant design for some new feature. Resist this temptation. Chances are that only a handful of people in the room need to be involved in the discussion. Respect their time by saying, “I’ve got an idea about how to solve that problem. Let’s talk about it afterward.” Everyone on the team has the authority to declare that a discussion should be moved to the “parking lot” to keep the team focused and on track. Remember a stand up meeting should be 5 to 10 minutes maximum.

The “No Impediments” Impediment

If a team member reports day after day that he/she has “no impediments”, that’s usually a good sign that there is a problem. Usually this goes hand-in-hand with missing commitments. It is virtually unheard of for a project to go completely smoothly for all the developers all the time and a few issues crop up every week across the team. Often team members feel self-conscious about asking for help or feel that they will be judged for complaining. The stand up meeting is about honest communication within the team. The point is to solve problems, not lay blame. If you are the project manager, team lead, or scrum master, talk to the individual afterward to see if there are any problems and encourage them to share with the group. This is a great opportunity to lead by example. Next time you hit a problem, discuss it at the stand up meeting and look to the team to help solve it. Show that the team is a supportive environment for everyone to excel.

The Whole Team

Stand up meetings are for the whole team, not just the developers. Agile encourages cross-functional teams and everyone involved in the project should be participating in the stand up meetings – developers, project managers, technical writers, QA, … Successful projects are those where the whole team takes responsibility for successful delivery. If a task needs doing, the team figures out how to get that task done regardless of official roles. For example, if the technical writer is behind on end user documentation because he was sick last week, the lead developer can step in and lend a hand. It shouldn’t be “beneath her” to do documentation work. Documentation is part of the deliverable, just as is testing, coding, coordinating with beta testers, and more. Sometimes multiple team members will need to juggle tasks around so that team members with the right skillset can tackle a particular problem. If you’re the project manager, team lead, and/or scrum master, remember to let the team figure out the solution (possibly with some gentle nudging) rather than you dictating it. The team will feel more ownership and responsibility for delivering on their commitments if they own the solution.

Report to the Team

Team members should be reporting their progress to the team and not the project manager. Stand ups work best when everyone stands in a circle. This encourages reporting to the whole team and make it easier to remember whose turn it is. The stand up meeting is about keeping the team synchronized, focused, and collaborating. It is not for updating a Gantt chart or explaining to your boss why the feature wasn’t completed on time. It is a forum for discussing progress of the project with the entire team and solving problems as a team. Team members should be making commitments to the other team members, not the project manager. It’s more important that the team meet its project deliverables than individual team members hit individual goals. In making the project successful, individual team members are also successful.

Summary

Stand up meetings are about more than just standing. They are about encouraging regular communication and collaboration between team members. They help to synchronize a team’s daily activities and facilitate just-in-time problem solving – removing impediments and keeping team members productive. They are one effective tool in our agile arsenal for delivering successful projects.

Thanks to everyone who came out to my session on Convention-over-Configuration on the Web at TechDays Calgary 2010. I enjoyed sharing my ideas about convention-over-configuration and how it can simplify software development. You expend some serious brain power over figuring out how to enable your application-specific conventions, but everything after that flows easily and without repetition. You end up doing more with less code. During the talk, I demonstrated how frameworks like Fluent NHibernate, AutoMapper, Castle Windsor, ASP.NET MVC, and jQuery support this style of development. (Links below.) I only scratched the surface though. With a bit of creative thinking, you can use these techniques in your own code to reduce duplication and increase flexibility.

• Fluent NHibernate
• NHForge
• AutoMapper
• Castle Windsor
• ASP.NET MVC
• jQuery & jQuery UI

You can grab a zip of the source code directly from here or view the source tree on GitHub here.

DevTeach is heading back to Toronto in a few weeks (March 8-12, 2010)and you’ll get a bigger dose of awesome than ever before. We’ve got a fantastic line-up of top-notch, internationally renowned speakers. 6 tracks covering Agile, Web, Windows, Silverlight, Architecture, and SharePoint. A metric ton of sessions. (I’m both the Agile and Web Track Chairs and am really excited about the speakers and sessions for each.)

Microsoft Canada is a platinum sponsor and every attendee receives a full copy of Visual Studio Professional with MSDN Premium. (N.B. Conference registration costs less than this subscription alone!)

And if you can’t get enough of that Sugar Crisp James Kovacs,  I’ll be there in full force with two sessions and a one-day post-con on agile development.

Convention-over-Configuration in an Agile World

As developers, we spend an inordinate amount of time writing “glue code”. We write code to transform database rows to domain objects… domain objects to view-models or DTOs… We write code to configure inversion of control containers and wire dependencies together. We write code to style our UIs and respond to UI events. Wouldn’t it be nice if this could happen automagically for us? This session will look at using convention-based approaches using Fluent NHibernate and Castle Windsor to reduce the amount of repetitive code and accelerate application development.

Convention-over-Configuration in a Web World

As developers, we spend an inordinate amount of time writing “glue code”. We write code to transform database rows to domain objects… domain objects to view-models or DTOs… We write code to configure inversion of control containers and wire dependencies together. We write code to style our UIs and respond to UI events. Wouldn’t it be nice if this could happen automagically for us? This session will look at using convention-based approaches using AutoMapper and jQuery to reduce the amount of repetitive code and accelerate application development.

Agile Development with IoC and ORM (Post-Con)

As developers we now have powerful tools in our toolbox, such inversion of control containers and object-relational mappers. But how can we use these tools to rapidly build maintainable and flexible applications? In this pre-con, we will look at advanced techniques such as convention-over-configuration in IoC containers and automapping ORMs to quickly build applications that can evolve over time. We will use test-driven development (TDD) to design and evolve a complete working application with supporting infrastructure during this one-day workshop.

Hope to see you in Toronto!

DevTeach is my favourite conference of the year and it’s happening again in Vancouver on June 8-12, 2009. No, it’s not my favourite conference because I’m one of the Tech Chairs. It’s the other way around. I’m a Tech Chair because DevTeach is my favourite conference. For the curious, Tech Chairs do not receive an honorarium or other compensation. We do it because we love DevTeach and the community it brings together. Here are my Top 10 Reasons to attend DevTeach Vancouver.

1. It’s got a dedicated Agile Track, baby! 18 sessions of agile goodness.
2. The Agile Track has more TLAs than any other track, including TDD, BDD, DDD, ORM, IoC, and DSL!
3. Internationally renowned speakers, including Oren Eini (aka Ayende Rahien), David Laribee, Michael Stiefel, Greg Young, Eric Renaud, Francois Tanguay, Claudio Lassala, Hamilton Verissimo, Owen Rogers, Donald Belcham, and me. And that’s just the Agile Track!
4. More IoC than you can shake a stick at with sessions by Oren Eini (current maintainer of Castle Windsor), Hamilton Verissimo (creator of Castle Windsor and Microsoft PM on MEF), and me. (I feel so outclassed in that line-up.)
5. 1-day pre-conference session on Agile Development with IoC and ORM with James Kovacs and Oren Eini. Register now! ($399 CAD) Spend an intense day of coding with Oren and me learning about how to build applications with Fluent NHibernate, Windsor, AutoMapper, and other agile-friendly technologies.
6. ALT.NET Canada happening June 12-14, 2009 at the same hotel. Register now! (FREE!) (DevTeach is a major sponsor of ALT.NET Canada. Thank you, JR!)
7. .NET Rocks will be in the house again! Carl and Richard always provide lively discussion and entertainment. DevTeach Vancouver will be no different with a .NET Rocks-hosted Visual Studio 2010 Beta 1 InstallFest.
8. At DevTeach, speakers don’t hide in the Speakers Lounge. You get to meet them face-to-face and ask them questions.
9. DevTeach Education Stimulus Package! In difficult times, DevTeach trying to help out by providing three registrations for the price of two. You can find details on the Registration page.
10. DevTeach is a conference where speakers go to learn. Unlike other conferences, speakers actually go to each other’s sessions and participate. This results in lively discussions that are fun for speakers and attendees alike.

Hope to see you at DevTeach Vancouver! Don’t forget to register for the day-long Oren/James extravaganza of agile fun. Or ALT.NET Canada!

A few months back, I announced that I was doing a series of articles for MSDN Magazine on improving a “classic” ASP.NET application with modern tooling and frameworks. As an application, I chose ScrewTurn Wiki 3.0 to use as my example throughout. The first article, Extreme ASP.NET Makeover – Getting Your House in Order, went live a few days ago. The article is purposefully a different format for MSDN Magazine than “traditional” articles in that it incorporates short screencasts where appropriate rather than just code snippets and pictures. (Code snippets and pictures are included too, though!) I tried to make the screencasts an integral part of the narrative where actually showing something was easier than text, pictures, or code. I would love to hear your feedback on the format and content.

Nitpickers Corner: In the series, I use MSBuild as the build tool. Yes, I wrote my own PowerShell-based build tool, psake. Yes, I use NAnt on many of my projects for clients. (They’re already using NAnt and PowerShell is a new skillset for them.) So why MSBuild for the series? Because it is installed by default with .NET 2.0 and above. Not my first choice, but a pragmatic choice for a series focused on improving what you have.

Joey Devilla (aka The Accordian Guy) from Microsoft’s Toronto office started Coffee and Code a few weeks ago in Toronto and John Bristowe is bringing the experience to Calgary. When John contacted me about the event, I thought to myself, “I like coffee. I like code. I want to be involved!” (Heck, I would order an Americano via intravenous drop if I could.) So John and I will be hanging at the Kawa Espresso Bar this Friday for the entire day drinking coffee, cutting code, and talking to anyone and everyone about software development. John is broadly familiar with a wide variety of Microsoft development technologies, as am I. I’ll also be happy to talk about Castle Windsor (DI/IoC), NHibernate (ORM), OOP and SOLID, TDD/BDD, continuous integration, software architectures, ASP.NET MVC, WPF/Prism, build automation with psake, … Curious what ALT.NET is about, I’ll be happy to talk about that too! I got my cast off today from my ice skating accident two weeks ago and am in a half-cast now. So I am hopeful that I’ll be able to demonstrate some ReSharper Jedi skills for those curious about the amazing tool that is ReSharper. (I am going to be daring and have a nightly build of ReSharper 4.5 on my laptop to show off some new features.) So come join John and I for some caffeinated coding fun at the Kawa Espresso Bar anytime between 9am and 4pm Friday, March 13, 2009.

This post has been brought to you by the letter C and the number 4…

Unfortunately I’m going to have to postpone my presentation on Tuesday as I broke my left wrist late this afternoon while ice skating with my older son. (I was practicing skating backwards, slipped, and landed with all my weight on the one wrist.) It’s a distal radial fracture, which means lots o’ pain meds for a few days and a cast for 6-8 weeks. You can see the effects of the percocet kicking in in the photo to the right. On a positive note, they let you pick the colour of the fibreglass cast. Glad to know that you can break your bones, but still be fashion conscious. Unfortunately they didn’t have my corporate colour green, which would have been cool.

So coding is going to be excruciatingly slow for awhile. I’ll reschedule the presentation once the cast comes off.