I had an interesting experience last week, watching another scrum master try and develop the concept of limiting work in progress and then explaining it to the team.  I found it interesting because of my background with lean development.  In lean, limiting work in progress is a core piece of lean, so it kind of goes without saying.  That started me thinking about the crossover areas between lean and scrum and the way they interrelate across similar problem areas.

That’s when I saw this post http://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/

I can’t say it’s comparing apples to oranges, more like comparing apples to the orange peel. Comparing scrum to kanban is kind of like comparing lean to a sprint planning meeting. A kanban board is one facet of using lean to manage a project, the same way that using a sprint planning session is just one facet of using scrum.

Read the rest of this entry »

I had an incident last week where another developer accused me of applying a double standard to contributions on a project. The root cause of the misunderstanding was that he was looking at the unit test that he copied from the other developer, while I was doing a code review of the code he submitted. That got me thinking about code reviews versus unit tests.

Ultimately, it comes down to the quality of the code review and the quality of the unit tests. A lousy code review is waste of time for all parties and is less effective than good unit tests. The reverse is also true, a good code review beats poor unit tests.

Read the rest of this entry »

I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.

To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”

Read the rest of this entry »

I'M LATEI’m late! I’m late!  My whole project is late!

Can an agile project be late? What does it mean for an agile project to be late? There are really two different kinds of lateness for agile projects.  First, there’s the kind that everyone thinks of “this project will take 8 sprints instead of 6 so release it”.  Then there’s the more insidious kind, “these stories got started but not completed in the sprint”.

Read the rest of this entry »

I just went to a training class, the first formal training class that I’ve gone to in years. Advanced Distributed Systems Design using SOA & DDD

To say my mind was blown is an understatement.  It’s the entire contents for a semester long class in system architecture condensed into a five day span.  It was the equivalent of trying to drink from the fire hose, far to much, far too fast to really take it all in.

Read the rest of this entry »

Git is a great cross platform version control system.  However, for windows users it’s got a really steep learning curve, especially when resolving merge conflicts. Working with some people that are just starting to use git, I see a lot of files getting checked back in with the merge markers like “<<<<<<< HEAD” still in the files.

In most compiled languages, leaving that stuff in the source, kind of breaks things. So there should be a way to let my more graphically oriented peers deal with the merges and inevitable conflicts more gracefully. P4merge seemed like it was the most highly thought of  graphical merge tools among the team, so setting that up for merges and diffs would probably be easiest.

Read the rest of this entry »

One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.

Read the rest of this entry »

One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.

The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.

Read the rest of this entry »

An Enterprise service bus is a cool piece of technology designed to solve a specific problem. Basically, it’s and N to N multicast communication device. You can have a variable number of message senders and a variable number of message recipients. Decoupling the senders and receivers and decreasing the number of touch points in inter-service communication.

The downside of an enterprise service bus solution is that you need to make sure you have an ESB type problem. Like a lot of enterprise patterns such as CQRS, an ESB is great at solving it’s specific type of problem and truly horrible when it’s not applied to the right problem.

Read the rest of this entry »

The SOLID principles have been kind of a cornerstone in software development for me. I think if the SOLID principles as part of the foundation of what makes good software. I kind of wonder about the fad for using closures now. Maybe I’m just an old crusty developer doing the equivalent of “you kids get off my lawn!” but it seems like closures are just another way of doing function pointers that made working in C/C++ such a pain in the butt.

This article http://arstechnica.com/information-technology/2012/09/should-i-continue-teaching-myself-how-to-code-or-should-i-go-pro/ started me thinking about closures in a different way. In a lot of ways a closure is all about inversion of control. They’re about passing around the logic to work on various sets of data. That’s pretty much the definition of inversion of control.

Although, I will admit that I’m not the greatest fan of the C# style of anonymous closures. I think that they tend to be over used, like all fashions. They have they’re place, but that place isn’t every place.

I think the case against closures is really about the Law of Demeter, the D in SOLID. The way that the law of demeter works is basically the transitive property of objects.  “The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).”

Closures, particularly anonymous closures that access variables outside of their lexical scope increase the brittleness of software by breaking the law of Demeter, just for variables instead of objects. By creating super complex closures, we lose sight of what’s defined where and it’s easy to create errors that flat out wouldn’t happen with named closures instead. If you’re in C#, this is no big deal you get a compile error, but it adds hours of debugging time in an interpreted language like javascript. Basically, the closure function is making assumptions about what is defined in the outer lexical scope(s).

In the end, I think that the SOLID principles are still the fundamentals and should be followed as a default.  Although, we should keep in mind other ideas, like closures that can help when appropriate.  “Rules exist to make you think before you break them.”