Developer, Engineer, or Architect?

I read an article on IEEE today that just annoyed me. The article can be found at: computer.org - careerwatch.

It is an interesting question but I don't think it was an interesting answer. One particular sentence summed it up: "Engineering is scientific, quantified, and disciplined, whereas development is random, not based on metrics, and stays away from engineering discipline." Given this definition I think that few if any people would claim to be developers. That really removes the value of the question.

At this point I use the terms programmer, developer and software engineer fairly interchangeably. I would like to see a distinction but any distinction that dismisses a group as not really knowing what they are doing is just going to lead to the term not being used.

Thoughts on being a Solution Architect

Thanks to Tom Hollander for putting together a list of requirements for a Solution Architect. I think this will be useful in justifying some more 'Architectural' effort as we continue to grow.

URL: Thoughts on being a Solution Architect

Schools Of Software Development

I thoroughly agree with Martin Fowler's recent comments on Schools of Software Development. He says that we don't know which school is right but I would go a little further I don't think that there is even a single right. There is no single right way to prepare a steak so why should there be a single right way to build a system. As with a steak there are too many alternative solutions.

That doesn't change Martin's point - we need to respect the existence of different schools and coexist.

Fritz Onion on Silverlight 2

I went to listen to Fritz Onion last night. I have to say that I was a little disappointed. The reason for my disappointment had more to do with my expectations than the presentation itself.

First I think that I have very high expectations of the well known names. I listened to a Presentation by Juval Lowy and I was just so impressed both by the content of the presentation and his knowledgeable handling of the questions. He is a hard act to follow.

Second I have significant reservations about Silverlight. This is partly because I can't see it being used in my company but also because we have been down this path before with Java and it hasn't really taken off. There are some differences a major one I suspect is that Java Applets were UGLY. They seemed to come from an earlier time. Silverlight has a subset of WPF that although it is missing the 3D features can still simply render some very beautiful user interface.

Sledgehammer for a nut Design/Process Pattern

I came across this the other day and thought that it was worth writing down as a pattern. In our specific example we wanted to control the client caching of our pages. The solution that the developer picked was to write an HTTPModule. (The reason for this was at least partly the 'If all you have is a hammer everything looks like a nail' pattern). It seemed at the time like overkill but I didn't have this pattern to apply...

Several weeks later we realize that none of our scripts are being cached on the client. This used to work but now it doesn't... The problem was of course that the HTTPModule was setting the cache control to no-cache for everything rather than just the pages we needed it set on.

The lesson to learn here is that to keep solutions focused but it you do need the big hammer to take extra care of avoiding collateral damage.

Learning new stuff

I have restarted a project that has languished for a number of years. I will save the description of the project for another post but the reason for doing this is to learn about all the new goodness in Orcas. So keep an eye out for more posts in this series.

Today I started to use a couple of new features. The first is the IEnumerable<> interface. We had the IEnumerable interface before but it has really grown up. What we have gained is a whole set of iteration based primitives. These include some simple ones like Contains. We could do this before on IList but now we have it on anything that is enumerable. The next primitive that I tried was the Aggregate function. This allows you to specify a function that will be used to combine each value in the enumeration.

I wanted to invoke a method (which returned a bool) on each element of the enumeration then combine these to see if the method returned true for all elements. I could do all this with one line of code:

m_parts.Aggregate(true, (prev, pred) => prev & pred.Apply(thing))

The true in there is the initial value for the aggregation. The second parameter is the new form for Lambda expressions/ anonymous methods. The way to read this is that the function takes two parameters the previous aggregate value and the next element. It combines the previous value with the value returned from calling the Apply method. It is pretty clever that the compiler can figure out all the types so this can be strongly typed without me having to specify them. The => notation is a very powerful thing but right now it doesn't feel very C# ish. I guess I need a little time to adjust.

The other new piece is actually more part of team suite - the testing support. I started just writing my tests using NUnit and running them through NUnit GUI (not as nice as resharper by far but functional). Then I found the add unit test menu item and I was taken down a different path. It is a pain that the attributes are all different but otherwise so far it seems quite workable. It handles the rebuilding and gives me the results in Visual Studio. There is plenty to try out yet so I will write more when I have used this more fully.

Tim Ewald speaks on REST

The Boston architecture study group met tonight to hear from Tim Ewald on the subject of REST. Let me say to start that if you get the opportunity to hear him speak it is worth making the effort. He was passionate, knowledgeable and thought provoking. He talked about why he was so excited about REST.

I have to confess that I am not sure that I completely GET it. There is certainly one part that resonated with me that was why build up all these layers on top of HTTP when we already have lots of interesting capabilities in HTTP.

One part that I am not convinced about is that English prose in the form of documentation is a contract. At some level of detail it might be OK but it doesn't have the ability to reason about in the same way that a WSDL definition does.

He made the very good point that 'in the wild' this is the way things are going. The big web services sites are using REST rather than SOAP.