The scene opens on a typical fall Saturday evening at the local sports bar filled with enthusiastic football fans cheering loudly at the myriad of TV screens scattered around. In one small corner sitting around a high table is a group of people visiting about software development. Two guys, eager to make friends, walk up introduce themselves and let slip they’ve been developing software with CSLA for the past few years, and are looking for redemption.” The rest of the table then looks at each other and responds in chorus, “I’m Sorry!”

The shock on their faces at the collective “I’m Sorry” was a bit much. They knew some people have very differing opinions about different frameworks and tools, but hearing it confessed out loud was a breath of fresh air.

Recently our development team decided to stop developing with the CSLA framework. Before I get into specifics, I want to be very clear about something up front. I have no problem with people that continue to use CSLA. We used CSLA for nearly 4 years and it has worked in way it was designed.

While Hiren and I were at KaizenConf in Austin we made sure to find a few minutes each evening before getting caught up with a large group, to recap the day and share some new things we each learned. One of these nights while relaxing and evaluating what we’d been learning we came to the conclusion that it was time for us to step away from new development with CSLA and migrate existing codebases as well. Over the past week we have been outlining and discussing these ideas and why we have made the decision to move away from CSLA.

It all started a few months ago when we first started getting introduced to the Alt.Net ways of developing software. What I mean by the Alt.Net ways are things like S.O.L.I.D. principles, ORM use, unit testing, Domain Driven Design, Mocking, TDD, etc… All of this has really changed the way we think about and develop software. Even before this though Hiren and I made a very dangerous combination of developers because we are never satisfied with a piece of code once it is written, we usually have to talk one another into just leaving it alone because it works and is as good as it needs to be to get the job done.

There are several driving forces behind this decision, but the primary one is that our CSLA business objects just leave a bad taste in our mouth. Our systems are moderately complex and it is not uncommon at all to have a class with 1500 – 2500 lines of code, in fact that is probably an average line count in most business objects. The other thing that really smells to us is that the “model” contains a lot of stuff that is not directly related to the model, namely data access.

I would like to take a minute to point out some of the things I really like and will miss about CSLA, and some of the other reasons for making the switch.

CSLA, I will miss some of you:

• Validation Rules System
• Data binding Support
• Combo of these == reach UI validation for user
• Good set of guiding principles and samples to get started with.
• Rocky’s Books!

I won’t miss these parts though:

• Data Access code in business object
• Difficult to mock out data access in mocking
• N-Level undo – I never, ever used this but had to contend with it, like it or not
• “Super” Classes

These are purely my opinion so take them as they are. I still think CSLA has a place for some people and unlike others I have run into on the internet, I will not bash you or think you are stupid for using it. CSLA was an excellent stepping stone for us; it introduced and really engrained the Object-Oriented Programming style of thinking into our minds. I/we just feel like we have matured to a new level of development through better understanding of our software development process and how apply those skills to our situation.

We are still learning and don’t yet know exactly what our development style is going to be end-to-end on this project. We have a long way to go before we are completely comfortable with all these new tools. Luckily, the Alt.Net community seems to be an open and accepting group and nearly everyone is willing to help us out along the way.

What I do know is that no team can just take what one person or one book says and do it that way. It won’t work. What we are doing is educating ourselves on different practices and tools and using what works for us, we do a lot of spikes right now. We are also building our domain model with POCO’s which gives us a great amount of flexibility in the infrastructure and presentation layers of our system. As we continue this process I will post successes and failures here on my blog.

I have to say that I am very excited about all the lean software development process talks that have been buzzing around in the community lately. This is generating lots of good first hand experience that is being shared with the community which I think is excellent. I would like to talk about two main points tonight, a pet peeve of mine that I just need to rant about for a few lines and second I would like to point out some of the other great stuff that is out there and discuss it a little.

Lean is the Process, Kanban the Tool

I personally think that a lot of people equate Kanban as being the methodology or even worse an equivalent replacement to Agile or Scrum. This is absolutely not the case, KanBan is not even a methodology like the others. This is a very important point that is often overlooked, especially when new people are trying to learn and apply Lean practices in their software process. Kanban is a Japanese word meaning literally “Signal Card” or “Signal Board”. A Kanban board is just a visual tool used to signal flow and show limits of the process and to create the signal for the pull flow of the system. Derick Bailey has a great easy to understand example of a Kanban in the shape of a grocery store over on his blog. I work for a Lean Manufacturer and we don’t use a “Kanban” in the traditional sense per say because we do not pass cards around the manufacturing floor, we do however use signaling and that is what KanBan is really all about. We refer to our signaling system as our “Supermarkets”, what these supermarkets are actually physical spaces in the production area that are designated for certain types and variations of product.  When a supermarket has an empty space, somebody up the process builds the product to refill that supermarket. To the right is a picture of one of our actual supermarkets, this is a bed supermarket.

Whether you are using cards, boards or supermarket’s the most important thing is that it is creating a signal in the pull system, and this enables flow. The two other really important pieces that Derick does a good job explaining are Order Points and Limits with his grocery store example so I won’t go to far in depth on this. These are two very basic items that every inventory management system has or should have at least. You obviously wouldn’t waste money shipping one box of cereal from General Mills every time a custom took one off the shelf. These just provide a way for the store or the development team to manage the amount of inventory they carry.

I kind of got carried away on what a Kanban was so let me get back on topic. A KanBan could be useful for various methodologies I think but it really shines if you are doing Lean Software Engineering. Lean is the methodology and I think there is a fear rising up within the software community that a lot of teams are just going to “Cargo Cult” this stuff and it really doesn’t work that way. Lean is a way of thinking, just like many of the Alt.Net principles. There are no hard and fast guidelines to implement Lean in 14 days, it is a process and takes time. Even then if you are practicing lean you will never stop implementing lean. I will get off my soap box but I just want people to know the difference between the tools and the methodologies.

Lean comes in Different Sizes

This is what I am really excited about right now. I know of 3 people currently implementing (or hoping to) Lean in their teams right now. The best part of this is that we are sharing the processes that we are following to make this as open as possible for other teams to follow along with. This is great because we are all in different teams, sizes, makeup, skill level, etc… So we should see some very different yet exciting results come out of all this. I committed to documenting my implementation at KaizenConf and have started with a few posts on what I have done so far. Louis Salin also has a series of great articles on his blog that are a recap of several sessions from KaizenConf combined with his own thoughts on this implementation and guess what, It isn’t that much different from the rest of us, only it is his way, which is awsome!

Louis Salin – The bag and the Kanban:

1. The bag and the Kanban, part 1
2. The bag and the Kanban, part 2
3. Activity Modeling and the bag

Louis has got some great ideas here, especially the bag idea. This is something very similar to what I have been thinking of / calling my “To-do” list. I will expand on this topic in a few days, we are currently re-working the way we deal with items before they make it on the backlog.

Derick Bailey – Adventures in Lean

Derick Bailey has just started his series, “Adventures in Lean”, and I think this will be very interesting to follow as well. Derick’s team is a larger team that I have for sure, and I think larger that Louis’ team too.

Ryan Kelley – Lean in Small Teams

I am documenting the Lean implementation in our team as we go along. I will continue to write about this, good things and bad so hopefully other people can learn from what we are doing. That said, we are a very small team, in fact if we were any smaller we wouldn’t be a team. Some may think that for a 2 – 4 person team you don’t need to do Lean but I say that is Bull****. One of the main reasons we are “Going Lean” is to bring some formality into a process that hasn’t ever had any before. We are probably the most disciplined department in the company with regards to how we work, so we need to share the discipline around a little and off-load more responsibility to the customer.

Until next time, I hope this as whet your appetite for more Lean / Kanban discussions.

Some of you know that we are in the process of not using Csla anymore, this is a decision that just seems logical for us, but that is another post. I need a little help implementing a problem in my domain. Now the sample I am posting is out of a dumbed down version I have been using to spike with. Take a look at the following class diagram and then I will explain what is going on and what my problem is:

What is going on here you ask? Order is the primary object type, but it is abstract. I have maybe 7 different types of orders, service order, make order, repair order, etc… each order has several attributes that are always present on every order. What makes each order unique is the attributes that are not shared between all orders. This is why I have decided to use inheritance.

One of the items that are common between all types of orders is that they all have many parts. However, I want the base Order class to have a collection of base OrderPart objects. OrderPart is the mapping object in between Order and Part for the Many To Many relationship, I am using an object because this association has state of it’s own. Now to complicate matters even more, each concrete Order can have a different concrete type of Part and OrderPart assigned to it.

I have the model all setup and Have written some tests against it as I wrote it, not really test first but hey, I am spiking here. So below is one of the tests that shows most of this in action.

public void CanCreateOrderWithCustomerAndParts()
{
var order = new CustomOrder();
order.Customer = new Customer
{
Name = "John Smith",
Address =
new Address
{
Street = "45623 Easy",
State = "TX",
City = "Dalals",
ZipCode = "73884"
}
};
order.OrderNumber = "Y984939";
order.Amount = (decimal) 1234.33;
order.CustomOrderDescription = "Testing adlkfjl 123";
order.Parts =
new List
{
new CustomOrderPart
{
Part =
new CustomPart
{
PartNumber = "Part456sdf34",
Description = "Test Partasd 87",
CustomPartText = "TEST",
},
Quantity = 12
},
new CustomOrderPart
{
Part =
new CustomPart
{
PartNumber = "PARTWITHNULLPULLLOCATION",
Description = "Test Part 848sasd8243",
CustomPartText = "TEST",
},
Quantity = 251
}
};

With.Transaction(() => Repository.Save(order));

Order createdOrder = Repository.Get(order.Id);

Assert.IsNotNull(createdOrder);
Assert.AreEqual(2, createdOrder.Parts.Count);
}

Don’t make fun of my test code, like I said, it’s a spike. But when I create a CustomOrder I am creating Parts as a new List<OrderPart> which is how it is implemented. But then I had new CustomOrderParts and CustomParts into that collection. NHibernate will persist this information correctly into the database and will retrieve it correclty from the DB. So seemingly all works fine right, sure I guess. Maybe it is just because I have been in Csla land so long that I don’t know any different but what I am really missing is being able for the concrete order object to know what concrete type of  OrderPart is contained in the parts collection. As I wrote that I just kicked myself, if that isn’t a violation of Seperation of Concerns I don’t know what is, or is it? I mean Order or a concrete Order is basically an Aggregate Root in DDD terms so it is the responsible entry point into the chain/web of objects that make up the aggregate.

So, for my real question which I am not sure of now, How would you tackle this design problem? How do you handle child collections? Am I just way off the reservation?

Tags: C#, DDD, Development

Gabriel Schenker has just posted an excellent article explaining in detail how to the 1st and 2nd level cache in NHibernate works. This is a long overdue article on caching that will greatly benefit the community. The article also explains the differences between Get(id) and Load(id) when retrieving entities through NHibernate. I am recommending this article because it is an in depth look at one of the pieces I covered earlier on Ayende’s session from KaizenConf.

Tags: alt.net, Caching, Development, NHibernate

When I got back from #KaizenConf I had to order a copy of Eric Evans book, Domain-Driven Design: Tackling Complexity in the Heart of Software. Main reason being that I went to a DDD session Dave had and learned a lot that just made sense so I figured it was a must have. So I ordered it, got it and have been reading it the majority of the weekend and I must say it is a very good book. For me though a lot of has been just giving formal names to the things we were already doing. Most of this is because we are a small team/company so we have always been the developers/business analysts etc…. But overall very good so far with good emphasis in the right places I think.

Tags: DDD, Development, software

In the first part of this journey I posted about two value stream maps we created. The next step after doing Value Stream Maps of our two primary processes was setting up our KanBan board. I would first like to explain some of the thought we put into setting up our KanBan board. During our discussion on KanBan in Small Teams Dave said to not over complicate your KanBan board, and I agree. Especially for smaller teams there is no need to have a 15 state KanBan board. So what Hiren and I cam up with is shown below:

What we have is 3 states for a task to be in: Backlog, Work In Process (WIP) and Done. I think there are several important parts to our KanBan board:

1. Limits– Notice there are limits on the first two columns (Done is a feel good state, no limit), this is to create blocks when necessary and to prevent a state from filling up with a pile of inventory as is possible with other methodologies. The limits are in place to effectively block processes up stream from piling up. When a state is blocked no other work can be performed in that state.
2. WIP has two tracks – We are a small company so we are developers and IT guys both so we decided we should leave a spot open in WIP for an IT task. I am thinking about making it so that if a Red IT task is in the slot then that “Stops the Line”, a Red task would be an emergency or super high priority that was really preventing any other work from being done.
   1. I decided to keep the WIP limit at 2 thinking that we won’t have an item in IT very often and if we do someone is probably not working on a Dev item anyway.
3. Standard word definitions / Constraints – Below the bottom horizontal line is where we list the standard work definition or other constraints that are associated with each state.

So this board is setup and we were just about ready to start using it when I started watching the video from the open spaces session Chad uploaded on viddler, see KaizenConf Article. When I got to the point we were talking about laying out boards I realized I had forgotten a column. So we will call the board above v1 and the one below v2.

In version 2 we have added a column between WIP and Done called Deploy. My thought behind this was that we don’t do release per feature, yet, and we also don’t have a set release schedule but what I want to do is release features in batches of about 3. So the standard work definition for deploy is if there are 3 or more tasks/features in this state then we should schedule a release. I don’t have it in the picture but I am going to have a limit of 5 or 6 on this state.

We are going to run with this KanBan board for a week or two and see if we need to make further improvements on it in that time. If we do I will post them up here, if not then I might make the lines a bit more permanent so they are straight.

Next up I am going to discuss the layout of our KanBan cards.

Tags: KaizenConf, KanBan, KanBan Board, Lean

I know this is a little late and somewhat out of order but I really feel compelled to write a public thank you note to all of the facilitators and attendees at the pre-conference workshops and the KaizenConf open spaces conference. I have made a boat load of new friends in the ALT.Net community that I know will be long lasting and very fruitful. The 4 day conference was by far the best conference I have ever been to. I came with so many questions got some answers and left with even more questions. It was very humbling to be surrounded by a lot of smart people, at the same time it is also very encouraging because these people are all very nice, friendly and real.

Workshops

The workshops that were put on were outstanding. I personally attended the Advanced NHibernate talk which was very helpful, you can see my notes here. I also went to the DDD Chalk Talk on Thursday afternoon, this was a very good talk about different aspects of Domain Driven Development. Friday started off with Jeremy and Chad’s Opinionated ASP.Net session and followed up with Dave’s Pull Don’t Push - Lean Systems and KanBan. All of these sessions were great. I have linked to what information is available now, and will link more as I find it.

Open Spaces

Friday night we “Opened” the space and one of the topics I suggested is Lean software engineering / KanBan with a small team. I didn’t know if anybody would vote for my topic or not but low and behold they did. So at my first open spaces event, I was also the convener of a space. This was a little bit intimidating at first but I handled it very similar to the way I do my college classes, we just all talked. Special thanks to Dave Laribee, Chad Myers, Chris Bilson and others that I don’t know your names, for being so involved and speaking during this session.

I spent time in some other very good sessions such as KanBan Applications, and Concurrent Set Based Software Engineering. There were so many good topics that I can’t even remember what all they were,  but there is a full list on the wiki.

As an action item on Sunday with KanBan in Small Teams I committed to documenting my teams implementation of the Lean Methodology with a KanBan task board.

In conclusion, Thank You again to all the great people in the Alt.Net community that came together in Austin to make this a very memorable event.

Tags: alt.net, KaizenConf, Lean

As promised at KaizenConf in Austin I am going to document our implementation of Lean Software Development as we go through the process of eliminating waste and creating a flow or pipeline process. We are in a unique situation as the rest of the organization is already following a LEAN approach for the most part due to the fact we are a Lean Manufacturer. So upon our return today we have gotten some guidance from internal “Lean Experts” and have started the process. The very first thing we did is two Value Stream Maps (VSM), this has helped us identify a couple of things already in the short amount of time it took to create them.

Value Stream Maps

I am going to first show the VSM’s and explain them a bit, then I will share some lessons learned already. Since we are a small company the IT department and Software Development department are one in the same, as in we do both. This means I need to have some value stream maps for both areas of concern. The VSM’s we created today are based on an average for each area. As we start and complete work in these areas I will create more VSM’s so that I have a better understanding of just where our waste and value times are and what happens in each. The way I like to create my value stream maps is that a box represents Value Add and a line represents no value add. Each box or line is then given an amount of time that a request/feature stays in that area.

Software Feature VSM

This is the VSM for a feature request in our company and it flows like this:

1. Customer Request comes in, usually via phone or email
2. Request enters To-Do List
3. Feature undergoes Design and Analysis
4. Feature enters Backlog
5. Development/Testing is done
6. Feature waits on customer approval
7. Dev/Test any fixes
8. Demo the feature with Customer
9. Release feature
10. Done Done

IT Request VSM

This is the VSM for an IT Request in our company and it flows like this:

1. Customer request comes in, usually via phone or email
2. Request then undergoes a quick Severity Check to determine how critical it is
   1. This gets a little interesting now as the path splits into two different paths, one for low or regular priority and one for high priority. The only thin different is the amount of time spent in each area.
3. Request enters To-Do list
4. Request is analyzed
5. Request gets worked on (WIP)
6. Request is complete.

Just creating these two value stream maps has identified a few errors that need to be worked on. The first area is Customer request, we need to create a standard way to handle requests. This should also put more responsibility on the customer than just accepting, “I need you guys to make X”. Second thing is that the VSM for a software feature is really just a guesstimated average right now. We have to work very hard to create like sized items to go on the KanBan board, which I will post about in a bit.

Tags: KaizenConf, KanBan, Lean, Value Stream Map