Welcome

Posted by indomitablehef | Filed under Uncategorized

in·dom·i·ta·ble
adj.
Incapable of being overcome, subdued, or vanquished; unconquerable.

Design In Drive

Posted by indomitablehef | Filed under Agile

When I started learning the Microsoft.Net framework and C# a few years ago, I was introduced to a whole lot of new “stuff” in the world of software development. In reality, it wasn’t “new”, just new to me. Apparently, there were a whole bunch of Java and C++ programmers out there who had been doing some deep thinking about Object-Oriented Programming and software development in general. Now, I knew about OOP. I had studied it in school (B.S. in Computer Science from Middle Tennessee State University, 1999). But when I got out of school, I went right to work building business apps with ASP, SQL server, and Visual Basic. I was busy learning the nuts and bolts of my trade, and I found I had a knack for it. Deep thinking about it, however, was not yet on my radar.

Then along came the .Net framework, and like all the other Microsofties, I started learning to write software on a real Object-Oriented framework. As I did, I was also introduced to Design Patterns, UML, “re-factoring”, Unit Testing, Domain Models, and a whole lot of other concepts that suddenly mattered in this new Object Oriented world I found myself in. A few years have passed since then, and I’ve learned a lot from the books those Java guys wrote while I was busy churning out little business apps. I’ve put the things I’ve learned into practice, resulting in some successes and some failures along the way. I’ve been lucky to be surrounded by a great group of developers who were also learning to do the deep thinking about design and process. I have learned a great deal from them and from the projects we’ve undertaken together.

Now, however, I suddenly find myself in the role of the teacher. While I have learned a lot, I’m no uber-philosopher of software design. I’ve never written any books about it, never written any articles about it, and I’ve never met Martin Fowler, Alistair Cockburn, Booch, Jacobsen, Rumbaugh, or anyone in the Gang of Four. And yet, I’ve just taken a position at a new company, where my job is to bring some direction in software development process and architecture. Well, I’ve heard that the best way to learn something is to teach it, and I hope that is true. Here on these pages, I hope to expound upon the things that I am teaching, and the things that I am learning, in the realm of software development, design, and process.

Design In Drive

I’ve seen several kinds of reactions from people (including myself) when they first get exposed to the realm of formal discussion about design, architecture, and process. My first reaction was mostly reticence: “Who do these Java guys think they are, coming in here telling me how to write software?” (But I eventually came around) Then there’s the “why do my eyes hurt” reaction, from The Matrix…

Neo: Why do my eyes hurt?

Morpheus: You’ve never used them before.

…that happens when someone sees it for the first time and immediately embraces it. Either way, what most people have to deal with when they stumble across Fowler, Cockburn, Evans, and the Gang of Four, is “how do I implement this in my organization/job/etc., and still get done all the stuff I have on my plate right now?” The answer is that it isn’t easy. It’s like changing pants while driving 70mph with a car full of screaming kids while towing a boat trailer. And yet, that is the situation that virtually everyone who has a real job when they discover this stuff finds themselves in. Thus, we will call our discussion “Design in Drive”. There’s no exit ramp and you wouldn’t have time to stop, even if there was.