Development

Zero Friction & Maintainability

Ayende Rahien — Fri, 16 May 2008 16:25:27 GMT

You probably heard me talk about zero friction and maintainability often enough in the past. But they were always separate subjects. When I prepared for my Zero Friction talk, I finally figured out what is the relation between the two.

I talk about zero friction as a way to reduce pain points in development. And I talk about maintainability as a way to ensure that we build sustainable solutions.

Let us go back a step and try to realize why we even have the issue of maintainability. Bits do not rot, why am I so worried about proactively ensuring that we will keep the code in a good shape?

As it turn out, while code may not rot, the design of the application does. But why?

If you have an environment that has friction in it, there is an incentive for the developers to subvert the design in order to produce a quick fix or hack a solution to solve a problem. Creating a zero friction environment will produce a system where there is no incentive to corrupt the design, the easiest thing to do is the right thing to do.

By reducing the friction in the environment, you increase the system maintainability

Actively enforce your conventions

Ayende Rahien — Mon, 05 May 2008 07:51:12 GMT

Glenn posted about a test I wrote PrismShouldNotReferenceUnity, in which I codified an assumption that the team made.

This is something that I try to do whenever I decide that I will have some sort of convention. If at all possible, I will try to make sure that the compiler will break if you don't follow the convention, but that is often just not possible, therefor, tests and active enforcement of the system convention fill that place.

Wait a minute, I haven't even defined what a convention is! By convention, I means things like:

All services should have a Dispose() method - add a Dispose abstract method to AbstractService
All messages should be serializable - create a test that scan the message assemblies and check for non serializable messages.
You may only call the database twice per web request - create an http module that will throw an exception if you call it more than that
A request should take less than 100 milliseconds - add an interceptor that would fail if this is not the case.
The interface assembly may not contain logic - add a test that would fail if it find a class with a method on the interface assembly.

All of those are ways to increase the feedback speed. This is especially true if there is some extra step that you need to perform, or you want to draw a line in the sand, from which you will not deviate.

Actively enforced conventions keep you honest.

Go with High End Solutions

Ayende Rahien — Sat, 03 May 2008 11:00:54 GMT

About a year and a half ago, I start an exciting new project (there is a demo of the actual project here). The actual application is fairly complex, and has some it gave me the chance to explore some very interesting ideas. Rhino Security is a generalization of the security scheme used in this project, and it is pretty much the driving force for Rhino Igloo. But that is not what I want to talk about.

What I do want to talk about is the infrastructure that we used for the project. We used IoC, OR/M, AoP, MVC and many other buzz worthy TLD. It was the first time that I had the chance in implementing real high end complexity reduction techniques. I left the team 10 months ago. In the meantime, the application was under active development, got a few new team members and had two major releases.

I am really proud of that system.

A few weeks ago I got a phone call from the current team lead, asking me about the windsor.boo file that is sitting there. The last time anyone touched it was shortly after I left, after which, it just... existed. I had the chance to do a code review on the new stuff that the team developed, about three months ago. I couldn't find any real difference between the code develop before and after I left.

Anyway, I had to spend 15 minutes on the phone, explaining the process that was going on there. Before I left (and during the time I was the team lead), I made sure that I passed on all the knowledge that I had about the system, the design decisions and the overall picture. However, there was a period of nearly three months in which I forgot that we even had this infrastructure, because we hadn't have to deal with it for that time period. After I left...

9 months.
2 major releases.
Zero issues with the infrastructure.

I asked the team lead what she thinks about that. Since it is her project now, and if she thinks that it was the right decision to make. She love the infrastructure, and wouldn't hear about using a lower end solution. Most of what we did was actually going over the file and explaining historical decisions, for that matter.

As an additional data point, I was able to look at a piece of code I have last seen over a year ago and figure out not only what it does, but the how and why of it with no ramp up time.

I consider this a success.

Frequent check ins frequent integration

Ayende Rahien — Fri, 28 Mar 2008 19:07:04 GMT

A few days ago there was a thread in the ALT.Net mailing list about the frequency of check ins.

Here is my opinion in this matter:

The best checkin comment ever

Ayende Rahien — Fri, 28 Mar 2008 19:03:04 GMT

Is this one:

The devil is in the details

Ayende Rahien — Wed, 26 Mar 2008 20:40:36 GMT

Quite often, I hear about a new approach or framework, and they are interesting concepts, with obviously trivial implementations.

In fact, the way I usually learn about new approach is by writing my own spike to explore how such a thing can work. (As an alternative, I will go and read the code, if it is an OSS project).

The problem is that obviously trivial implementations tends to ignore a lot of the fine details. Even for the trivial things, there are a lot of details to consider before you can call something production ready.

Production ready is a tough concept to define, but it is generally means that you have taken into account things like:

Performance
Error handling
Security

And many, many more.

One of the release criteria of Rhino Mocks is the ability to mock IE COM interfaces, as a simple example. That is actually much tougher than it looks (go figure out what RVA is and come back to tell me), as a good example;

But mocking is a complex issue as it is, let us take unit testing as an example, it is very simple concept, after all. How hard is it to build? Let us see:

public class MyUnitTestingFramework
{
	public static void Main(string[] args)
	{
		foreach(string file in args)
		{
			foreach(Type type in Assembly.Load(file).GetTypes())
			{
				foreach(MethodInfo method in type.GetMethods())
				{
					if(IsTest(method)==false)
						continue;
					try
					{
						object instance = Activator.CreateInstance(type);
						method.Invoke(instance, new object[0]);
					}
					catch(Exception e)
					{
						Console.WriteLine("Test failed {0}, because: {1}", method, e);
					}
				}
			}
		}
	}
	
	public static bool IsTest(MethodInfo method)
	{
		foreach(object att in method.GetCustomerAttributes(true))
		{
			if(att.GetType().Name == "Test")
				return true;
		}
		return false;
	}
}

Yeah, I have created Rhino Unit!

Well, not hardly.

I can write an OR/M, IoC container and Proxies in an hour (each, not all of them). Knowing how to do this is important, but doing so for real is generally a mistake. I am currently using a homegrown-written-in-an-hour IoC container, I really don't like it. I keep hitting the limitations, and the cost of actually getting a container up to par with the standard expectation is huge. I know that I can't use a written-in-an-hour-OR/M without sedation.

Here is the general outline of the cost to feature ratio for doing this on any of the high end tools:

There really isn't much of a complexity involved, just a lot of small details that you need to take care of, which is where all the cost goes.

One thing that I am not telling you is that I didn't show the entire graph, here is the same graph, this time with more of the timeline shown. After a while, the complexity tends to go away (if it isn't, the project fails and dies, see previous graph).

Nevertheless, the initial cost for rolling your own like this is significant. This is also the reason why I wince every time someone tells me that they just write their own everything. (yeah, I know, I am not one that can point fingers. I think that I mentioned before that I feel no overwhelming need to be self consistent).

My own response for those graphs tend to follow the same path almost invariably:

Build my own spike code to understand the challenges involved in building something like this.
Evaluate existing players against my criteria.
Evaluate comparability with the rest of my stack.

If it passes my criteria, I'll tend to use that over building my own. If it doesn't, well, at least I have a good reason to do it.

Programming to learn is a good practice, one that is important not to lose. At the same time, it is crucial to remember that you shouldn't take out the toys to play in front of the big boys unless you carry a big stick and are not afraid to use it.

Zero Friction and why Defaults Matters

Ayende Rahien — Sun, 24 Feb 2008 23:41:56 GMT

Several times recently I had to answer why I care so much for defaults if they are something that I can change. My answer is usually a derivative of "defaults matters". I have come to understand that this is not a sufficient answer and I need to clarify it.

I have talked extensively about Zero Friction environment and why I care so much about it. It is about how much I have to fight the tools that I have in order to get what I want.

I spent much of yesterday moving Rhino Tools from MsBuild to NAnt, because MsBuild doesn't have any way to get the current framework version. That is a big task, and considering that I can add this functionality to MsBuild in a few minutes, why did I do that?

Again, it had to do with the fact that when I need a solution, I had to work hard for it. With NAnt, it is just there. For most of everything, in NAnt, it is just there. Between the two, NAnt is the tool with less friction. In the long run, this mean that I would be able to work more efficiently.

How does this related to defaults? Well, consider this, if I have to extend / change something to get something that I consider a baseline functionality, this is a problem. This is friction, and if it generating that much friction early on, I can safely assume that it will generate much more friction when I want to do the advance stuff.

At that point, thanks but no thanks.

To put it in more familiar terms, whatever defaults you have are the Out Of The Box Experience that you have for your software. If you missed the default, it is as if you just hand me a product in one of those ugly and hard plastic shell (the ones that you need scissors just to open) and told me that I can put it in a pretty designer box.

Yes, I can, but you missed your chance to get me.

And that is ignoring the fact that default, for most people, are what is happening. You need good defaults.

Handling dependencies in a one assembly

Ayende Rahien — Fri, 22 Feb 2008 10:32:13 GMT

There were several comments for my recent post about the disadvantages of creating a single assembly for a project, instead of the more common multiply ones.

The main one seems to be related to dependency management. How you can be sure that the UI isn't accessing the database, and other fun violations of layering.

I have to say that I don't really have much issue with that. I want good layering, but I find that code style in a project tend to keep consistent over a long period of time in any reasonable time. As such, once you have sufficient size, it will more or less manage itself.

That isn't going to be an acceptable answer for a lot of the people that want to have more control over that, I know. There are two answers to that, the first is from the human perspective, the second is from enforcement perspective. Let us deal with the first one first.

Make it easy to do the right thing. I seem to be saying that a lot lately, but this is a core concept that all developers needs to assimilate.

If loading a user from the database is as simple as:

usersRepository.Load(userID);

Then you can be certain that no one will try to write this:

using(SqlConnection connection = new SqlConnection("Data Source=LocalHost;Initial Catalog=MyAppDB;"))

{

    connection.Open();
    SqlCommand cmd = connection.CreateCommand();
    cmd.CmmandText = "SELECT * FROM Users WHERE Id = " +userId;

}

Yes, it is that simple. And yes, this assume non malicious people in the team. If you have those, termination is recommended. It is your choice whatever it would be of them or their employment.

Enforcement is easy as well. Get NDepends and setup the appropriate CQL queries. Something like: error if class in "MyApp.UI" references "MyApp.Infrastructure".

The two project solution

Ayende Rahien — Thu, 21 Feb 2008 22:09:23 GMT

Back to technical content :-)

This post from Kyle Baley got me thinking about my last few projects. In them, I trended toward the assembly per logical layer of the app. So I had things like:

MyApp.Model
MyApp.Web
MyApp.Services
MyApp.Infrastructure
MyApp.Tests

It worked, but at one point I found myself managing 18 projects solutions, and that was only because I was committed to reducing the number (otherwise it would have been much higher). I hear about people talking about 30 - 60 projects in a single solution, and there are people with more. Considering the cost of just managing that (not to mention the cost for compilation per project), that sounds like a very bad approach.

Right now, I think that on the next project I'll have the following structure:

MyApp

/Model
/Web
/Services
/Infrastructure

MyApp.Tests

Everything that the application does will be in a single project, without the need to split it off to a lot of separate projects. I found that the vaunted isolation that we seem to seek is achievable easily without forcing artificial barriers between the different parts of the application. It also means shorter compilation times and easier deployment mode.

More than everything else, it means that I have less noise to deal with.

I would extend that to an assembly per physical location, so assuming that I had a smart client application, I would use the following scheme:

MyApp.Server
MyApp.Interfaces
MyApp.Client
MyApp.Tests

And that would be it.

Thoughts?

Disinterest in technology

Ayende Rahien — Mon, 11 Feb 2008 21:52:34 GMT

I just and took a look at the recent Dot Net Rocks show, as a way to look at "what the market is thinking about". I got some interesting responses from looking at the titles. I haven't listen to all of them (not by far), but I won't let that stop me from commenting.

Adam Nathan on Popfly and Silverlight
Not interested at all. Something that belongs to another planet as far as I am concerned. Combining Popfly (some sort of purple duck, I understand) and Silverlight puts it on the far reaches of Saturn, as far as I am concerned.
Miguel de Icaza and Geoff Norton on Mono
Defiantly interesting, I have been keeping an eye on Mono for a while, I am waiting to see how it works on the Mac, and I argued for Mono based deployment in several projects in the past. EC2 + Mono seems like a very interesting option.
Andy Leonard on Unit Testing your Database
Seems interesting, but mostly my answer to that is: Use in-memory database for that. Oh, and don't use SSIS. Rhino ETL is trivially testable, by the way.
Kirk Munro on Powershell and PowerGUI
Not interested in PowerShell beyond the most cursory of glances. If I want scripting, I got Boo.
Simon Peyton Jones on Haskell and Functional Programming
This is something that I have yet to listen, but it is interesting, mostly because it is a totally different mind-set than the one I usually use.
Les Pinter Looks Back
That was a fun show, not technical content, but really good to listen to it.
Aaron Skonnard puts BizTalk and WCF Together
I get the shivers just thinking about the subject, next.
Sahil Malik Shares the Point
And I'll keep on going missing the point.
David Aiken on Bridging the Gap between Dev and IT
This looks like an interesting show.
Steven Lees on FeedSync
Not interested, I even took a look at the description to ensure that I am not interested.
Kathleen Dollard on the Evolution of Software Development
That was a fun show.
Ken Levy on Visual Studio Extensibility (VSX)
I need to be interested in that, because I have a chapter about IDEs that I need to write, but... that is not an interesting topic to me. Go write in notepad.
Jeff Prosise Goes Deep on Silverlight
Did I mention that it is not interesting?
Joe Duffy on the Task Parallel Library
That was a good show, and something that I actively looking at.
Richard Campbell Tells All!
Very good show.
Jeff Palermo on ASP.NET MVC
It was a good show, but the topic is not interesting, as far as I am concerned.
Gael Fraiteur on PostSharp
PostSharp is something that I keep looking at, haven't found the need for it, but it is an interesting project, and surprisingly outside my usual circles.
Tomas Petricek on PHP in ASP.NET and Silverlight!
Yawn, yawn.
Open Source Panel Discussion at DevTeach, Vancouver
I refer to this episode as the "if loop" show.
Naveen Yajaman on Visual Studio Tools for Applications
Through this show, I kept thinking: Or they could use Boo, get everything that they want and not have to pay "undisclosed" amount in licensing.
Colin Miller and the .NET Micro Framework!
Interesting in the abstract, not sure of its utility.
F# Moves Forward
I have this low level urge to look at F#, but I am just not interested enough.
Dot Net Nuke Discussion Panel
Not interested.
Kent Alstad at Dev Connections!
This should be a scalability show, which are generally interesting, except that I am sick of hearing about "don't use view state", or the fallacy of "scalability means that you can't use convient idioms"
Tim Sneath and Ian Ellison-Taylor on Windows Past, Present and Future
That should be interesting.
Pablo Castro on Astoria
If I recall correctly, Anders Norås wrote an equivalent for that in a few hours. Not really interested.

I think that I'll leave interpretation of those for the comments, but it looks to me like technology topics are growing very old, very fast.