Dave Laribee

• Spicing Up Your Standup

  Tags: luke-melia-is-awesome, funny Posted Nov 16 2008, 08:58 PM by Dave Laribee with 1 comment(s) Filed under: Agile, stand-up

• Ayende on Advanced NHibernate

  There's this cat called Ayende that's been around the NHibernate block (20 or 30 times). In Austin, he did a 3-hour workshop detailing the advanced features of the tool. If you weren't there, sorry you missed it. Oh wait! You're in luck; someone recorded it! The audio is a little quiet so be sure to, as the kids say, "pump up the volume." Enjoy... Posted Nov 13 2008, 09:02 AM by Dave Laribee with 10 comment(s) Filed under: conferences, NHibernate, video

• Designing the Team Room, Take 2

  Based on the comments, a couple of clarifications on my "Designing the Team Room" post from yesterday. The text at the bottom certainly does have contradictions and conflicts. That's by design. We wanted to see what people came up with, what ideas latched on to "productivity" versus "collaboration." The opening is simply for context. People that are up on Theory of Constraints will realize that defining conflicts and finding solutions based on root cause is, well, kind of the whole point. I also neglected to detail the mechanics used for the design storm. 1. Each person tore of a sheet from a 3M sticky easel pad, grabbed a marker, and found a spot on the wall.  2. We had twelve (12) people stand in the circle. 3. I read the context statement I posted yesterday. 4. For 5 minutes, each person made a "design." Some of these were visual, some textual, some floor plans, etc. 5. We then counted off by threes to form a total of four groups (ones in one group, twos in another). 6. Each group member (within their group) had 1 minute to pitch their ideas. 7. After the individual pitches, we took another 5 minutes to synthesis a cohesive design. 8. The cohesive designs were presented to the entire group. What was interesting is that this process took under 30 minutes and we got a little closer to consensus and got some really good ideas. And that was the point...   Posted Nov 06 2008, 10:19 AM by Dave Laribee with 1 comment(s)

• Designing the Team Room

  At VersionOne, we just got the opportunity to move to a new team room. It's far superior in terms of size, noise level, and natural light. It's a very cool, very lofty kind of space. To get things started, we applied the "design storm" exercise which is a form of concurrent set-based design, an evolution of the old school architectural charette. Special thanks to @uxdesignermike who turned us on to this tool at KaizenConf. Mike, for the unaware, is awesome. You'll find the opening I used to kick the session off below. I'll be sure to post a few follow up shots as we get our space together in the coming days. # In moving to a new, more-ideal space we have an unusual opportunity to optimize for collaboration, productivity, and fun. To get this process and involve the numerous smart and opinionated members of the V1 development team, we’d like to engage in a process called “the design storm.” We have a few goals and constraints going into this: We want to keep noise at an acceptable level. We want an intensely collaborative environment. We want the space to be flexible and permit promiscuous pairing. We need spaces for breakouts and loud meetings. We want stand-ups to remain unbroken (no walkthroughs). We want to pay attention to traffic patterns. We want to change it up every so often. Take that how you will. We want our continuous improvement efforts to be highly visible and easily accessible. We want the team to sit in the same area together (i.e. no cave dwellers). We want to leverage natural light the best we can. I’ve hinted at this, but our main motivations are: Collaboration – proximity promotes knowledge sharing. Creativity – ours is a creative job. it should be easy to start designing stuff. Productivity – it’s easy to focus and get stuff done. Awareness – looking at the walls yields information. A pleasant working space is, well, pleasant. Now, without pre-designing the space, does anyone have anything else?   Posted Nov 05 2008, 01:53 PM by Dave Laribee with 12 comment(s) Filed under: coaching, collaboration, design, team room, teams

• KaizenConf Workshops Schedule

  UPDATE: We will try to record the full sessions. I'm hoping some participants will bring video cameras and have at it. I'm bringing mine. First of all the temporal situation: Morning Sessions - 9a-Noon Afternoon Sessions - 1:30p-4:30p Then, we have to talk about the nomenclature around and sizing of rooms: Huge - 50-60 people Large - 40-50 people Wimpy - 15-25 people Thursday Morning Huge - Advanced NHibernate Large -  Introduction to Lua Wimpy - Pull, Don’t Push: Lean Systems and Kanban Thursday Afternoon   Huge - Functional Programming - Is it a game changer? Large - DSLs in BOO Wimpy - Driving Toward the Goal   Friday Morning Huge - Using and Abusing ASP.NET MVC for Fun and Profit Large - All About MEF (the Managed Extensibility Framework) Wimpy - Mystery Session with Scott Bellware Friday Afternoon Huge - Presentation Patterns: Going beyond MVP and Presentation Model Large - Fluent APIs with C# 3 Wimpy - DDD Chalk Talk Posted Oct 27 2008, 12:32 AM by Dave Laribee with 5 comment(s) Filed under: conferences, housekeeping

• The Value of Lean and Kanban

  Mark Levison wrote up and introductory article on Kanban for InfoQ. It's from a people perspective and worth a read if your new to this scene or interested. I'm especially happy he conveyed the "work to done" concept. For me that's the biggest thing. Done has a pretty simple definition: "it's in production." I think this is a message that should be in the forefront. As with any message, repetition is key. Throughput accounting (David Anderson's book on Agile Management, great intro) is a big, big, big deal. This is the theory/justification/whatever of the done definition. The other thing that's really important to me is the visual management stuff. You can see where things are getting bogged down. Corey Ladas pegged this best in his leading indicators post. Queue utilization trumps velocity/cycle time in having an effect on throughput. Standard work and thinking about your pipeline is rather critical. Continuous improvement happens much more regularly when we say "hey, here's how we're gonna work" and make that explicit with a whiteboard, cards, and a marker, and tweak over time. There's gotta be a baseline. Other things, like cycle time, seem less important (but still matter) as, in the case of cycle time, it's just a re-imagining/slight reconfiguration of an agile concept (velocity). Of course it's important to establish it and improve upon it, but I don't necessarily see it as new ground. Posted Oct 23 2008, 05:42 PM by Dave Laribee with 1 comment(s) Filed under: kanban, lean

• Presenting the KaizenConf Workshops

  UPDATE 1: Schedule is coming tonight. Each workshop is approximately three hours long. We're going with a longer form to get more knowledge transfer, interactivity, etc. UPDATE 2: Based on space and time constraints, there will be two sessions going on at once. No tracks (we don't do tracks), but I will make an attempt to provide some variety. Here's the final lineup for the workshops immediately preceding the KaizenConf Open Spaces event. I'm pretty psyched about the line-up. There's some very relevant/edge topics covered by seasoned people chock full of juicy content. ALT.NET assemble! # Advanced NHibernate Ayende Rahien Object relational mapping are becoming only more popular, as people developing complex systems find that they need more than the tabular model to work with in their applications. A sophisticated ORM can do a lot more than merely get the data out of the database in object form, it can be a valuable asset in simplifying development and making things possible. In this session, you will see how you can utilize an ORM in nontraditional ways to get an additional, better, approach to solving complex issues. Some of those ways include business rules, localization, state transitions, inversion of control, etc. All done via the ORM layer, and all can be used to drasticly simplify the complexity of the given scenarios.   Presentation Patterns:  Going beyond MVP and Presentation Model Jeremy D. Miller and Glenn Block Our desktop applications are becoming more complicated every year, and just slamming all the behavior into the code behind isn't cutting it any more.  You know about Model View Presenter and Presentation Model for individual screens, but what about the application as a whole?  How do you govern screen activation?  What about communicating across screens?  Extensibility?  In this session I'll present some patterns and strategies for handling complex behavior in stateful clients.  We'll examine some possible approaches for using IoC tools to wire together a composite application.  I'll also present on the screen activation lifecycle, state management throughout the application, and coordinating events over an application.  Taking another tact, I'd like to examine the MicroController pattern combined with language oriented programming as a way to wring out more productivity in our development efforts. Time permitting, I'll also share some lessons learned for automated testing of desktop applications.   Fluent APIs with C# 3 Chad Myers You may not know it, but you're likely already using internal DSLs in C#: The Linq IEnumerable extension methods (Select(), Where(), ToArray(), etc), the NHibernate ICriteria API, Rhino Mocks, StructureMap, Windsor, Moq, Ninject, and many others all have internal DSL syntaxes. Whether it be for configuration, programmatic assembly of an object graph, or a myriad of other purposes, an internal DSL can usually make the process go faster, easier to test, and easier to consume by the API consumer. In this workshop, we'll go through the process of creating a basic internal DSL. We'll then go deeper into more advanced variations and themes of internal DSLs, learn about tricks and pitfalls, and end up with an advanced internal DSL.  We'll learn about method chaining, the builder pattern, function sequences, and many other internal DSL patterns and related concepts.   Using and Abusing ASP.NET MVC for Fun and Profit Jeremy D. Miller & Chad Myers After deciding to go with ASP.NET MVC Preview 2, we quickly ran into a few design/testability problems and some missing functionality we needed (it's a preview, after all). Still agreeing that ASP.NET MVC was good and still worth pursuing, we decided to begin filling in some of the gaps and trying to avoid some of the testability problems by creating our own extensions and overriding certain behavior.  Jeremy has come up with some great concepts during this process that we'd like to share with the community. During this workshop, we'll go through the various additions and derivations we've made in our ASP.NET MVC-based application and how they've helped us create a very adaptable, reusable, and testable web application infrastructure.  The goal is to discuss and contribute ideas to the community, suffer critical feedback, and hopefully increase interest in MVC-based design and testability in a web environment.   Introduction to Lua Marcus Irven Lua is a powerful, fast, light-weight, open source, scripting language.  Though Lua can be used for standalone applications a lot of its power lies in how can easily it can be used to extend programs written in other languages. In this workshop you will get a thorough introduction into the Lua language. After covering the basics we will dive into code and explore the interesting and unique features of Lua. You will also get an introduction on how Lua can be used to extend your applications.   Functional Programming – Is it a game changer? Matt Podwysocki We hear a lot about functional programming lately, and many wonder the reasons.  We’ll dig into the philosophy of functional programming, how you can apply it, and what uses it has.  Immutable by default, recursion over mutation and functional composition over inheritance are some of the mind shifts required for this technique.  As we run into Moore’s law changing, we need to be aware of how to realize the full potential of our applications when it comes to asynchronous and concurrent behavior. Learn how functional programming can help solve some of these problems that we have not only today, but in the years upcoming.  Using languages such as C#, and F#, we can apply these functional techniques today to help make your code more concise.  But, with any paradigm shift, there are traps.  Learn of some of the pitfalls you may fall into and how to avoid them.   Pull, Don’t Push: Lean Systems and Kanban Dave Laribee Full description forthcoming. I will say this will be aimed at getting you up and running with an iteration-less pull system or "Kanban." We'll cover some of the principles of Lean Software Development, queue and buffer patterns, and metrics/reporting.   Driving Toward the Goal: Standard Work in Software Development Jef Newsom Kent Beck titled his first book on XP "Extreme Programming: Embrace Change." Yet so many organizations and individuals that adopt agile software development practices only attempt to embrace the ongoing change of requirements, not the ongoing change of themselves and their processes. Because of this, so many teams who approach agile software adoption either plateau or backslide into a rebranded status quo. To truly become agile--to truly embrace change--we must focus on constantly improving our people, our products, and our processes. To determine whether we are improving, we need both an understanding of where we are and to where we want to head. Taiichi Ohno is quoted to have said, "Where there is no standard there can be no kaizen." This notion of "standard work" is key to how the production workers in the Toyota Production System continuously improve the repetitive tasks of manufacturing. And this standard work is not a static "best practice" that we adopt to magically reach nirvana. It is a detailed description of how we currently know to best perform the repetitive tasks, along with examples of both desired outcomes and common defects. We will explore two common "Best Practices" for agile development: TDD/BDD and User Stories. We'll define our standard work, execute it, decide what works and what needs improving, and determine how we'll take action. We'll look for challenges, undesirable effects that are introduced, and we'll think logically about how we can remove them, experiment, and improve our standard. By the end of this workshop, you will have shared and learned how others in the workshop are best applying practices like user stories and TDD. You will have shared what you struggle with and learned what others struggle with in applying the practices. You will "stop the line," come up with experiments for improving the approaches, try them out, establish a new standard, and continue improving. We'll explore common questions such as: how to identify the right user stories; how best to split user stories and still deliver value; how and where to get started when doing TDD. And we'll explore powerful tools such as: standard work; "stop the line" issue resolution’ TOC's thinking processes Bring a laptop and your intuition.   All About MEF (the Managed Extensibility Framework) Glenn Block Today, it is difficult for applications and frameworks to meet an open-ended set of needs. Building in extensibility allows third-party customization, however there are many challenges in doing so. The application developer is often faced with creating an extensibility mechanism from scratch. This forces the extender to learn a new extensibility model for each application he extends.  The design of the extensibility APIs directly impacts the ability of the extender to do what he wants. The Managed Extensibility Framework (MEF) is a new extensibility model in the .NET framework that addresses many of these problems. It provides as simple declarative model for application developers and extenders. The model itself can be enhanced to support your own semantics. It focuses on discoverability and composition, drawing from lessons learned from the DI (Dependency Injection) community although it is not a traditional DI container. In this workshop we’ll start with the basics of what MEF is and how you use it. Then we’ll peel back the covers and go deeper into more advanced usages of MEF. Along the way we’ll also look at how MEF compares to DI/IoC containers, and how it fares with TDD and other agile practices. We’ll come out of the session having built an application from scratch that uses MEF.   Textual DSLs in Boo Ayende Rahien Domain Specific Language is not just the DSL SDK from Microsoft. A DSL can make working with the domain much easier, since you are capable of leveraging the domain concepts directly. The other alternative to a DSL is an XML file, and we all know how well declarative model can work when you need imperative concepts, just consider NAnt for a minute and you will see the issue. Usually, writing a DSL in .NET would be a complex issue, requiring writing a parser, interpreter, etc. Boo already handles all of that, and its open architecture means that it is very easy to extend it to express the concepts of the domain. This talk will show you how to build DSLs in Boo and how to utilize this power in your applications.   DDD Chalk Talk Dave Laribee and Greg Young Full description forthcoming. Greg *might* make it, still up in the air. This will be a looser and more interactive workshop for all skill levels, but will focus on techniques for implementing rich domain models for .NET. Audience participation is highly encouraged! Posted Oct 22 2008, 01:35 AM by Dave Laribee with 23 comment(s) Filed under: ALT.NET, Community, conferences, housekeeping

• Transitioning from NAnt to Rake

  Maybe you're interested in this Rake business. Maybe you've got a big investment in a whole build infrastructure in NAnt. Maybe, just maybe, it's impractical to convert the whole enchilada over at once. What do you do? Wrap it in Rakey goodness, of course! Step one: leave your nant build in place. Write a little ruby function to fake call into Nant from Rake. Step two: create your rakefile.rb (or rakefile). Step three: incrementally replace NAnt tasks with Rake equivalents. Start simple... Step four: evolve as necessary and on your own timeline! Posted Oct 17 2008, 03:05 PM by Dave Laribee with 4 comment(s) Filed under: builds, nant, rake, Ruby

• VersionOne, Day Zero

  I announced this on Twitter a while back, but I've left my full-time job at Xclaim to join VersionOne as their internal Agile Development Coach. I'll say, leaving Xclaim was kind of a bittersweet thing. I'm still a part owner of the business, which is nice, but it's the excellent team and practice we've forged together that I'll miss the most. I get really involved in my work and it was at 5:00pm on my final Friday that I was feeling, let's say, like the ultimate chicken. I'm comforted, however, by the fact that Xclaim goes on and continues to be a great team. Every coach needs a captain, and my colleague, Rik Bardrof, is more than ready to take on the next set of challenges. He's in cahoots with the same awesome and dedicated people I had the pleasure of working with over the years and I'm positive they'll continue to kick it, as they say, up a notch. For those that don't know, VersionOne makes tools for Agile teams and organizations. In fact Xclaim is a happy customer. My job there, as the internal coach to their development team, is to drive new practices and process improvements that can help take them to the next level. What's cool is that they've got an already-rocking team right now. In the course of a day long interview/visit, I got a sense of clear vision from top leadership and met some very talented, passionate team members. All the ingredients for a legendary team are in place and that's something I knew I had to be a part of. I took the job for another big reason: the domain is really interesting. You're working to drive continuous improvement on an Agile team working on a product for other Agile teams. How meta can you get?! I quite like the challenge of serving both domain expert and playing coach roles simultaneously. This team will push the edge of Agile and Lean to the point where we can harvest and validate innovations and bake them into a product that sells itself. This has to be the highest form of technical excellence a product team can achieve. I believe that's within reach, and am looking forward to sharing our experiences along the way. Posted Oct 02 2008, 11:50 PM by Dave Laribee with 9 comment(s) Filed under: housekeeping

• .NET: Coming to a Cloud Near You

  I was very happy to hear the news that Amazon will be providing Windows/SQL support on their EC2 cloud computing service. From the email announcement: We are excited to let you know that Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server starting later this Fall. Today, you can choose from a variety of Unix-based operating systems, and soon you will be able to configure your instances to run the Windows Server operating system. In addition, you will be able to use SQL Server as another option within Amazon EC2 for running relational databases. I've been waiting for this option. For a long time the LAMP stack has held a distinct (and unarguable) advantage in long tail plays; much easier to find the kinds of virtual, on-demand models associated with "cloud computing." With this, I see that gap narrowing. Even so, during this time of low availability, new architectures might have had a chance to sneak into the (at times monolithic) .NET developer community. When we reach for a persistence solution for our next killer web apps will it be SQL Server 2008 or a distributed hashtable? Posted Oct 01 2008, 09:26 PM by Dave Laribee with 8 comment(s) Filed under: .net, cloud-computing, infrastructure

• Done For Real

  I had the good fortune to sit in on a day long session with Dave Hussman (who is awesome, by the way) on the topic Agile coaching as a lead in to the Atlanta APLN meeting. It was chock full of tips and I recommend getting out to see Dave if and when you get the chance; he packs a lot of knowledge into a short amount of time in an extremely entertaining way. One of the questions he asked is: when is a feature done? This is a perennial topic with Agilists and it's a very valid question; how do we know when a feature is "potentially shippable?" I piped up with my answer: a story is done when it's in production use. That was a little different than the answers from the others in the room. Think about it: we're not delivering value until that value has been delivered. That's a very Yogi Berra way of saying that until the user's using, that feature you made isn't contributing to business value. In a way that's one of the original premises of Agile: release early, release often. This is the reason why I like the cycle time measure over the velocity measure. Cycle time tells us how long the feature took from the time it was green lit to the time it went into production. This gives us a real measure of how long it takes to deliver business value. Velocity simply tells us how long a feature took to develop (unless, of course, we have release-per-iteration) Agile asked us to work better as software development teams and deliver in tiny little batches. Lean asks us to do the same thing, but put the software team in the context of the larger organization and from the customer perspective. Think globally, act locally. Doesn't matter how rockin' a development team is, if those features are being held in inventory until waiting for some deployment event, they're not done; they're only done as far as you're concerned, and, last I checked, there were more than developers and testers involved in the process of delivering software. Posted Sep 26 2008, 12:03 PM by Dave Laribee with 10 comment(s) Filed under: Agile, kanban, lean

• Laribee's Final Law of Continuous Integration

  Seeing that DJ Miller is spinning up some amusing-but-true laws of continuous integration, I'm gonna weigh in and declare Laribee's Final Law of Continuous Integration. I see it as so critical that I'm going to put it quasi-biblical speak and in a blockquote: Thou shalt not leave the office before the successful build of thine last commit. Doing so is beyond uncool and shall impose as a penalty, at minimum, the collective stink eye of the team to be cast upon thee. Or maybe we'll go with modern and more direct version. Stick around and make sure your last commit doesn't break the build. Posted Sep 22 2008, 08:48 PM by Dave Laribee with 12 comment(s) Filed under: continuous-integration, opinion

• More General Thing Madness

  This description of problem analysis by Reginald Braithwaite (who is a smart person) struck a chord with me: I found this to be an important point in my own programming, and I don't know if that's a general point but quite often we see something and we are very tempted to say "Oh, this is a special case of a more general thing", and then we solve the general thing. However that is an infinite recursion, it's always the special case of something more general. And if you are always climbing up the tree into the more general thing you will eventually wind up with a PhD in computer science and no code. I know one of the areas that I get into trouble sometimes is when I try to make something too meta, too flexible. One of the things we abandoned early on at Xclaim was a very flexible party/roles management system that was so general -- it would have modeled anything -- but it was nigh impossible to represent in as a consistent and meaningful user experience and programming interface (developer experience). I try to stay more mindful, as an applications guy, of my abstractions now and root them in the concrete problem. For me, learning and flexing DDD was a really useful approach for all sorts of domains and reigning in my tendency to get too abstract. As a method, you can apply it (in part, at least) to really any domain: vertical or horizontal. Patterns such as bounded contexts, intention revealing interfaces, the core pattern language, and ubiquitous language can keep you from falling into the pit of meta-meta-meta-madness. Posted Sep 22 2008, 08:24 PM by Dave Laribee with 3 comment(s) Filed under: analysis, DDD, opinion

• Why SOLID? GIMME AN L!

  Thus far in my journey to explain the why of the so-called SOLID principles I've covered Single Responsibility Principle and Open/Closed Principle. This brings us to "L" for Liskov Substitution Principle which the originator, Barbara Liskov, describes as: What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. Whoa! Math meets English and kicks its... well, you know. Robert Martin boils it down a bit: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. If we have a consuming function that takes a Customer class, it shouldn't matter if that gets a GoldCustomer specialization. We don't want, in our consumer code, to rely on the is or as keywords to branch our consumer accordingly. // For shame! void Consumer(Customer customer) { if (customer is GoldCustomer) { var goldCustomer = customer as GoldCustomer; goldCustomer.DoSomethingElse(); } else { customer.DoSomething(); } } Seems sensible, but recall: we're dealing with the why and operating under the strict belief that it's unacceptable to invoke these principles without understanding their deeper reasons and benefits. It's particularly important that we be able and ready to articulate the reasons for these tried truisms as we mentor new developers and win entrenched developers over to known better ways of doing things. Mind Your Coupling A lot of these principles come down to coupling and cohesion. LSP is all about controlling coupling. Notice how in the code example we've touched on two types? Customer and GoldCustomer are both used by our (rather creatively named) Consumer method. So what if we add a PlatinumCustomer? We've created a permalink between our consumer and a wider-than-desired surface area of our customer model. Respect the OCP As Robert Martin points out, ignoring LSP is a clear violation of "the Open-Closed principle because [that function] must be modified whenever a new derivative of the base class is created." So LSP and OCP are intrinsically linked, and, if you remember, the why behind OCP has to do with stability and moving forward by only ever adding new behavior. If I have to change the Consumer function every time I create a specialization of Customer is that function closed to modification? Clearly not. Fragile APIs Ignoring this has particularly nasty effects when we're writing code or an API to be consumed by someone else. By "someone else" I mean either: Another team in the same timeline. Another developer that has to come along and maintain our code. Ourselves way down the timeline; we'd have to remember this bit of code exists! LSP must be taken into account when we design our class hierarchies. We have to respect this principle upstream and within the context of our layered architectures. I believe LSP and everything it supports form part of the justification for another principle: favor composition over inheritance. Sure inheritance seems conceptually useful when we're inside the model or framework using it, but when we think about our system as a whole -- external consumers, future dependents -- and apply LSP, that initial perceived value diminishes quickly. Since it's so hard to get these "is a" relationships right and they are fewer and further between than we might initially think, why not just avoid it and treat our classes as a kind of surgical tray? Small, single-purpose instruments that can collaborate to solve a number of problems... Leveraging DbC Design-by-Contract and LSP go hand-in-hand. DbC's notion of preconditions and postconditions have import when we delve into the mire of class hierarchies. A subclass may override a parent method only under certain conditions: Preconditions can only be weaker. Postconditions can only be stronger. If you want to take advantage of DbC features in the future -- and I think a lot of us will -- your class hierarchies need to meet this guideline. They should meet it already right now, but a DbC framework should prove this at compile time. DbC gets us closer to the promised power of static languages with verifiably correct software, which has the benefit of achieving a high bar of initial quality after the development process while lightening our testing and specification burden. Posted Sep 22 2008, 11:52 AM by Dave Laribee with 6 comment(s) Filed under: oo, principles, solid

• TDD, Contracts, and Reading the Fine Print

  Jimmy Bogard on coming to TDD and interface oriented Jesus and the aha moment of why we use interfaces: An interface is a contract, that any implementation needs to adhere to. Consumers of the interface do not care about implementation details, nor can they, as the interface provides no other information besides the signatures it provides. I quite like the point that Jimmy hints at. Classes, at a certain level, are tiny components. But is an interface really a contract? Yes... but it's not the whole contract; our tests and specifications are part of the contract of our components. A component does a couple of things. It will a) tell its container environment what services it needs to run and b) what services it provides. It does this by requiring or publishing one or more contracts. As far as what we have right now in the mainstream, if we're pursuing the highest quality, it's up to us to deliver contracts that fully document not just the data (as interfaces do) but, at times, the behavior or semantic qualities of these tiny components we're writing. Sometimes those behaviors mean something to the supplier and the consumer. Say we have a controller and that controller depends on a service. The controller creates a transaction and invokes a service method. Perhaps that service method then throws a business-meaningful exception. For argument let's say we have a shopping cart and you've just added -1 pairs of agile pants to your order. Wait a second... what just happened?! The fact the exception happened is surely a part of the contract! We have to deal with it after all and abort the transaction or take some compensating action. In the case of ordering some agile pants, maybe you want to display a message indicating that quantity should be one or more. Yes, I realize this is a bad example, but stuff like this necessarily happens in the real world. What if -- just go with me here -- we have a dependency that can throw an exception? Is that not part of the contract? Last I checked there wasn't a way to say "hey, this interface can throw these kinds of exceptions" in C#. Consumers surely need to care about implementation details. What about invariants? If we simply have a structural contract we have nothing that expresses these behavioral elements. C# might get some spec# features, but we're not quite there yet. Preconditions, postconditions, and invariants are a part of the contract we take in. When we're driving out interfaces and using a nice mock objects framework, we need to think about our consumers when we dive into a dependency and drive it out. What preconditions are you creating? What exceptions are you throwing? Do consumers of this service need to be aware or are they likely to want to handle these exceptions? If so, you need to return to the consumer and write some more tests. Get more mileage out of your code by applying defensive programming conservatively. Simply put: contract = specifications + interface. Interested in the potential benefits of DbC for more-robust contracts? Sifting through a quick Google search on the subject yields a nice post by Mario Gleichmann exploring the idea that interfaces all by themselves are poor contracts. Posted Sep 18 2008, 09:44 PM by Dave Laribee with 2 comment(s) Filed under: BDD, DbC, oo, TDD