SOLID software engineering principles

Back in 2009, the StackOverflow podcast #39, Joel Spolsky started openly bashing the SOLID principles and TDD (Test Driven Development) and claims they were put together by someone who doesn't really write a lot of code.

This made me a bit upset.

I listened through the Hanselminutes podcast in question and what I heard was quite different from what I think Joel heard because Joel went on about the adverse effect of writing unit tests, that it's, probably time better spent doing something else, and the absurdity of turning everything into an interface.

I think this story is really interesting, and Joel actually invites Robert Martin (Uncle Bob) to the show, after he published an open letter to Joel and Jeff, which became the topic of podcast #41. And Joel starts the podcast by apologizing.

Experienced software engineers realize when they are wrong.

But it's important to point out that Joel is also right, in that he creates a situation where you have a programmer that's at 99% code coverage and then presented with three choices:

1. Get to 100% code coverage
2. Deliver a key feature to a key customer
3. Dramatically improve usability

Only one of the above choices is wrong.

At this point I'm 50 minutes in to the follow up podcast and I'm quite confident that they won't actually be addressing the core issues. Joel has been going on and on about GUI testing and how unfruitful that is. And I'm tired of examples in which he appears to be trying to test layout quirks rather than stuff that matters.

It feels as if the whole discussion was geared towards using SOLID and TDD where it's not appropriate and it's unfortunate because they effectively fail to highlight the importance of SOLID software engineering principles.

The Pragmatic Programmer is a great read, but I think the key takeaway for any such book, is that as a programmer you should be pragmatic.

To answer the question, why SOLID and TDD? You only need take a look at the real world and make a simple observation.

Things change.

What SOLID is all about is understanding the underpinnings of SOLID software engineering principles. Why modular code better responds to change and how you avoid friction while adhering to principal object-oriented design practices. It's a lot of fancy wording to say that you can design code to not be tightly coupled and still deliver on schedule, all while quickly adapting to change in the real world.

I did say object-oriented, but actually SOLID has very little to do with object-oriented programming, it fits very well into any paradigm, because it's good advice and you're not a SOLID zombie, just because you care about system wide interactions.

Now, I tend to forget that the minds of people all work differently and don't typically share the same history. I often argue my point without realizing that people might not understand where I'm coming from. So, I'd like to drive this home with, why I value, the SOLID principles.

This all started with me trying to get into the habit of writing tests. I slowly realized that I couldn't test my code effectively because the implementation was in most cases tightly coupled. There was simply no way for me to pull out the important parts and isolate them in a controlled manner, and then run meaningful tests.

To enable the above scenario I had to learn new principles and through practice and hardship I eventually got to understand the SOLID principles.

The point of doing SOLID is that you're gearing up to be testable by design. But to accept SOLID you don't have to accept the entirety of TDD, you simply have to acknowledge that there's value in being able to do automatic testing, something which you cannot do if you don't design for it.

Testing is a way to drive SOLID designs, which is one way to tackle the constant change we have to deal with every day.

Initialization, JavaScript and HTML/CSS friendly behaviors

Way back (early 2009) I started a Stackoverflow question about this very same topic. I didn't find the answer I was looking for but recently I've managed to put some pieces of the puzzle together.

Normally, I'd rely on the HTML id="" property to be a known value and get at it using getElementById or $("#id"). I've never liked this approach but what are you supposed to do? This is how 99.99999% percent of the people I know do it and they think it's fine. Fine!? It's a freaking atrocity. I know it's very subtle but if you think about what your doing, your effectively duplicating knowledge everywhere, filling up your global namespace with a bunch of identifiers and having to go through hoops just to do parametrized initialization.

I think we can do better.

Oh, and If you haven't already gone there, that Stackoverflow question contains a bit of code I wrote as an example and answer to my own question. On how to go about this in an unobtrusive way.

It sort of began with the realization that jQuery addClass, hasClass and removeClass can be used to toggle a Boolean value. The state of this Boolean is reflected in the presence of a CSS class. Without thinking about it, I had stumbled on a system for handing visual states. When these CSS classes represents meaningful visual state information you can use them to style your JavaScript (or augment) using established CSS rules. These things fit well together.

All my client-side validation does is that it toggles an error CSS class at some place and I have a planned out HTML fragment with additional classes that let's me apply a style to the validation state without meddling with the original script.

I started using this more and more and it's truly an ingenious marriage between two technologies but I was still bugged that I couldn't do the same with client-side behavior, or so I thought.

By simply rethinking the way we've (or the way I've done it so many times in the past). I started thinking about CSS classes as more than visual state. What if I reserved a CSS class for a specific behavior?

By reserving certain classes for use with specific HTML fragments I can create very rich client-side behavior without violating the DRY principle, encapsulation or relying on other ugly hacks. Say good bye to printing ("<%=...") strings in JavaScript and hurray for that!

What you do is that you pick a CSS class to identify the HTML fragment and then use HTML5 data to attach properties (think of 'em as parameters). From within a document ready function, using jQuery, you query the document for all the CSS classes and do your initialization here. You have a reference to the DOM node, data availability (parametrization) and complete encapsulation (no publicly visible interface, except for the data members).

The Stackoverflow question contains a simple sample where I use this trick to add regexp validation using CSS classes and HTML5 data only (assuming that the script is already written). I can reuse this code in many different places without having to go back to my JavaScript or "hook up" these things thanks to the wonders of jQuery and CSS selectors.

I think this is something truly beautiful.

Hidden features of Visual Studio, enter watch expressions with format specifiers

Every now and then I find myself getting annoyed at these little refresh squiggles that the Visual Studio watch expression get if they potentially have side-effects. I reckon that's a good thing, however, sometimes I need to express a quick way to drill down some data structure and get at that specific value.

Format Specifiers in C# (see MSDN)

These format specifiers are for C# but some of these are language agnostic and some variations of these work with other languages.

There's more information on MSDN. But these are my favourite ones, the ones I try to remember. Because when I need them, I have know that I can use them.

Specifier	Format	Value	Displays
ac	Force evaluation of an expression. This can be useful when implicit evaluation of properties and implicit function calls is turned off. *
d	Decimal integer	0x0065	101
h	Hexadecimal integer	61541	0x0000F065
nq	String with No Quotes	"My String"	My String

* See Side Effects and Expressions.

And this is how you use them...

Watch

Name	Value
Text,nq	string without quotes
source.Skip(2).First(),ac	The 3rd element of an enumerable source
0xa,d	10
10,h	0x0000000a

The d and h format specifiers are especially nice when you find yourself toggling Hexadecimal Display on and off. And as a bonus, If you'ven figured this out yourself, these expressions also work in the DebuggerDisplayAttribute string. Very handy.

VSX Mercurial

I have a habit of leaving things unfinished if I find my self having solved the nitty gritty details. That last stretch stuff just isn't as fun as the technical challenges. Though that's a topic for another day.

This week I contracted a bad case of the flu. I've spent the last several days in bed trying to regain some strength. Laying there thinking (not really accomplishing much of anything) I thought I'd reboot that source code control plug-in for Visual Studio.

The thing about Mercurial (and this is equally true for git) is that it's super easy to get started. And with it you can distribute, patch and hack away effortlessly in mere minuets. What I felt was missing was a source control package for Visual Studio that embraced the same principles.

For all the SVN tools out there TortoiseSVN always struck me as odd because it attempts to turn every last folder in your computer into a version controlled system by integrating with the Windows Explorer Shell. I never got that and was somewhat surprised that TortoiseHg even existed. Mercurial not being SVN makes it somewhat less of an atrocity but I can't believe that people actually wants to use these GUI tools.

Unhappy with the performance of existing plug-ins for Visual Studio I decided to roll my own and I figured that it be a good opportunity to learn how to build Visual Studio Extensions.

I actually have decent statistics of the number of hours a day I actually spend within Visual Studio actively doing stuff. Learning more about the Visual Studio extensibility model felt like a smart move.

I have a very clear vision of where I wanna go from here, it's also my attempt at an open source project. I don't really have any strong feelings about open source but I've always learned a lot by reading source code. This could be a good opportunity to give something back.

If you're a Visual Studio user looking for a Mercurial SCC plug-in checkout VSX Mercurial on Codeplex.

I abandoned this project sometime ago. Mercurial is still a great tool but I use TFS and git today. I also find that the kind of integration I was planning with VSX Mercurial wasn't really what I needed, git extensions taught me this.

Microsoft PDC 2010

Windows Azure is the big topic of this years Microsoft PDC. I haven't payed much attention to Windows Azure in the past but after the PDC I actually felt the urge to write some code in the cloud (hilarious isn't it?).

The developer experience for Windows Azure is what you'd expect with Visual Studio 2010. The transition is easy to make, and the big difference is primarily on the Windows Azure Storage side of things. That did not sit well with me, and it took me a while to figure out that the out-of-the-box tools don't really support the development storage, which is what you use if you haven't paid for an Windows Azure account.

There's a lot of pesky things about the Windows Azure Development Storage that's not entirely obvious. e.g. there's only one development storage account (which limits you to exactly one database at any given time), it can be completely wiped simply by clicking a button on the storage service client and there is no built-in tool for managing the storage (only querying from within Visual Studio is possible). Given that I might wanna switch between different projects, I thought I'd keep my schema and data primarily in scripts, that made sense until I realized the way to talk to the Windows Azure Storage service is through this REST API. That's fine though, but not if you're expecting to write T-SQL scripts. Windows Azure Storage, is a no-SQL storage and fundamentally different from what you get out-of-the-box with SQL Server. I realize that's a good thing for writing scalable software, but it did catch me off guard. I believe I was expecting something along the lines of what Microsoft is offering with SQL Azure.

I'm interested in learning more about Windows Azure, but this sort of thing doesn't not help with that. Eventually, I would put up the money for it, (truth be told, it's not that expensive). However, it's hard to get an overview of the what you need (in terms of computing power) and the final cost when running in the cloud is pretty guess work. Though, you can scale back to whatever supports your revenue stream as well as scale up, if necessary.

It's likely that my concerns right now, will fade away with time. As I learn more about the platform my ability to make the right decision will certainly increase. Though, as of today, the first-class developer experience I've come to expect from Microsoft with Windows Azure is not quite there.

The hardest problem with computing is people

Gilad Bracha said this during the Programming Languages Panel at Microsoft PDC 2010.

The hardest problem really is this whole issue of compatibility that plagues software, that is so brittle, you can never take things out, you can never fix things early, you can just add stuff, and therefore contribute to bloat and the problem is not so much with the technology as it is with the people. The hardest problem with computing is people, and you know they need to be replaced but we cannot do that. Ultimately we need to find ways for software to evolve and update itself in such a way that it can not only grow but shrink.

Hopefully I'm not misrepresenting Bracha or quoting him out of context when I say this.

I've been looking into software composition and clearly found great use for dependency injection. Inversion of control IoC (IoC) represents a step in the right direction and dependency injection (DI) is the means to achieve both IoC and composition. As a proof of concept of this, I was refactoring some code written by co-worker this Friday, moving things into reusable services, and surprisingly yet satisfyingly so, I'm removing more code than I'm adding. The result is not necessarily a smaller code base, but the complexity is certainly more manageable (on top of being testable). I think this is what Bracha is getting at.

The benefit is that there's no longer a tight coupling between these objects. Which is what's allowing me to actually move this code into a separate assembly altogether. If I can partition my software into isolated compartments then that's a step in the right direction. What you get out of this is a problem which focuses on the management of several smaller instances instead of one very large code base and through experience, I've learned that managing complexity on a smaller scale is preferential to a big ball of twine (intermingled dependencies).

The compositional approach is of course not free. Nothing, is. For one, a loosely coupled software architecture that is compositional requires lots of abstractions and you should be aware that there's a fair amount of work to be done to orchestrate the composition of the software itself. Some work is going to focus on writing auxiliary software to make deployment and configuration easier.

I'm convinced that composition is the way to tackle software aiming at solving a diverse class of problems in some manner which is consistent on a higher level. It enables great flexibility without sacrificing architecture, testability or maintainability at the cost of initial bootstrapping when new requirements surface.

Windows Phone 7

After attended the Windows Phone 7 launch event here in Stockholm, Sweden. I started thinking about the Windows Phone 7 experience in a new way. Having read everything I could find on the Internet actually using the phone didn't really change my opinion. It's still a solid touch device. But one thing that became abundantly clear was that the phone can not be experienced through others.

I say this because so much of the phone experience is tied into social networking, such as Facebook and Twitter. If the phone is hooked up to your contacts it's personal and talks to you in a different way. The problem is that you cannot not buy the phone and get that experience, you basically need to rent it and spend time on it, before you can make a decision.

The Windows Phone 7 experience appeals to me differently than the iPhone and Android and if you have a chance to check it out, you should!