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.”




After 20 years off earning my daily bread writing software, it’s still thrilling to start a new project.  That feeling of hope, knowing that this time we’ll do it right rather than cut corners and choose good over expedient. Every new beginning makes me think of what should happen, and reflect a little on what makes good work. That gets me thinking about what makes quality software.

One of the most important things in any endeavor is solid fundamentals. Whether it’s playing a sport or writing software, the basics matter. Always.

Read the rest of this entry »