Wednesday, December 15, 2010

Architect or something new?

Every year I go on a couple of interviews in order to stay on top of the industry. I want to know what people are getting ready to do in real life. This year, my recruiter buddy set me up for one interview with an Architect pre-screen. 2 other architect interviews were done via the normal face-to-face to whiteboard process.
I was so taking aback by the WIDE range in differences to the definition of an architect across the industry. In fact I contacted many folks around the country and found the same thing. Are we in the middle of the creation of a new position or do we need to redefine existing positions?
So on my pre-screen, the question stream attempted to head in a theoretical direction. Concepts and theories are what he wanted to discuss. In fact I was even asked how I could possibly mentor not knowing the details of what the GOF did for patterns and practices. Yeah, I know what they did, I know that the 4 patterns they defined are the basis for all others. I'll spare you the details but at the end of it, my ability to do, well my current job was questioned. So, I don't think that was the intent of the interview and as a leader and problem solver I started thinking, what just happened? But I'll get back to that ...
My other two architect interviews were face-to-face. They were very typical, I was asked to whiteboard some hypothetical designs/design problems. I was asked some harder technical questions but most of the interview was how to bring together all the systems necessary to create a hypothetical software package. My decision process for buy or build, mentoring developers/clients and customers on the package, and a host of other questions that make up a full SDLC. Pretty typical right?
I went on a couple of other interviews which included a couple of management positions, and Lead/Sr. Developer opportunities and did not find such a range or difference in the job definition.
So as I mentioned early, I wanted to confirm that pre-screen was just a one up. I go on one every few years where the individual interviewing has a chip on their shoulder. When I asked around I found the same wide range in interviews. In fact they were all so similar to mine it got me thinking.
As a leader I learned long ago that in this industry it's important to have a couple of different types of team members. You want that guy that is the head down programmer, shows up every day at 9, leaves at 5 but for 8 hours he is buried in his computer putting out lots of high quality code. You also want your next manager, somebody who could play any other part to the team but he is focused on being your replacement. You want a mentor, somebody who is knowledgeable, has a lot of patience and lives to share his knowledge, the last person you want is that person that questions everything. Yeah you need more than that and you frequently don't find exactly that, but those individuals in some form make a strong team that can, if mentored correctly, foster a highly productive, smooth running team.
That last guy, the guy that argues with everything is what I saw in my pre-screen. The one that is extremely book smart, they may or may not be functionally savvy, but there are incredibly smart on what is going on in the industry. They could tell you every detail of what the GOF wrote and a whole host of things you didn't even know existed. What are they incredibly good on a software team? They keep you honest. In the military, these guys rarely made it through basic training, frequently only stayed 2 years or became officers. In private industry they force you to evaluate everything you know, question your thoughts to ensure you don't get complacent and help you produce solid software designs that follow well established and current practices. I don't always believe you have to do the new cutting edge thing but this ensures you at least consider it.
I think this individual has always existed and in part is the reason our industry has grown so fast. I don't however believe architect defines what this individual should be doing. If you look at the commonly known version of an architect, the home builder, they know all the regional building codes, can put all the pieces together to make up an incredible home that is safe and meets the customer's needs. This individual is customer focused and can put together the solid foundation for that customer so that they can make their house a home. They work with builders and other contractors to put all the pieces together. The individual that I talked to knew industry trends and local standards as well, but this individual has focused his career on the theoretical, spending his time studying blogs and tweets to read between the lines. Creating in his mind possible ways to potentially steer our industry moving forward. I think what I experienced and what all these guys that "question everything" want to do, is be the theorist of our industry. Where as an architect asks what can I do with these "pieces" to make a whole, this theorist ask what can I do with these "pieces" to make something new.
I don't know but sounds like a new career path to me. Thoughts?

Tuesday, November 30, 2010

Compiling Thoughts

Years ago I dug into this niche part of the programming world called SOA. I say niche however it has certainly become mainstream.There are many people I talk to day-to-day that write a service here and there but not many that have put, wow ... 8 years of solid SOA programming in. Folks have said I should share some wealth, good, bad or otherwise but I have resisted. I have resisted because I have been so focused on the next stage of my career that I forgot about this one. I'm back ... I'm fired up and ready to start talking, and excited about it. If you tweet you can occasionally catch me @tazcapt.
So to get back in I decided to start a continuing series on a design/architecture I am working on now for the retail company I work for and cover, the design, development, troubles, testing and deployment issues.
With my next post we will hit the surface of design, problems we needed to address, expected loads on the services and more. We will continue my digging into design, on going development, agile (scrum) and finish up somewhere with the rather favorable outcome. You'll want to stick around for this, it will be fun.
I also have another project coming down the pike which may present with sone cool new ideas.
Till next time ... "stay thirsty my friends".

Monday, November 29, 2010

Microsoft Extensibility Framework

I have done a lot with reflection over the years. In the day it was a cool tool but because it was often grammatical a pain in the ... it lost it's way with me. I recently attended VS Live 2010 in Orlando and was reignited into the use of reflection or what we now call MEF (Microsoft Extensibility Framework). Microsoft has done all that clumsy work that used to make Reflection difficult for us.

My real world use is of course with WCF (Windows Communication Foundation). I produce a large number of services that talk to multiple outside partners exchanging product, inventory and order information. I have been working on ways to reduce the number of WCF services and thus TCP/IP ports. Reflection was one way where we could create one service and then dynamically call an interface based library for each timed service call. In other words at timed intervals we we make an interface call to a CRUD method that is exactly the same on every service. That service decides what to do on each of those interface calls.

Here is an example of what the code would like like in reflection:

var asm = Assembly.LoadFrom(Path.Combine(Environment.CurrentDirectory, "service.dll"));
var type = asm.GetType("service.serviceimp");
var service = Activator.CreateInstance(type) as IChannelInterface;
service.Create();


As you can see this has several areas that can cause both performance issues and flat out exceptions.
Anything in quotes makes me look twice, but to put the name of a library in quotes to me is just plain insane. This means first and foremost the very thing I was going for, not being bound to the library is now bound. Second, what if I spell it wrong, we all know how programmers spell, that's why some folks never leave VB. Last it means I can not change the name of the library without affecting some other program (I'm tightly bound again). Exception possibilities are numerous here but through this into a console application and try and run it.

So Microsoft wrapped this all up for us and in conjunction with the new Parallel library I was able to get the following to do the exact same reflection code from above:

var container =
new CompositionContainer(
new DirectoryCatalog(Environment.CurrentDirectory));
container.ComposeParts(this);

var t = Services.AsParallel();

t.ForAll(x => x.Create());


Now this is my kind of coding, nothing to specifically identify a library, multi-threaded and most of all NO QUOTES. So what are we doing here? We are using the CompositionContainer (a new MEF class) to say load everything in the currently executing direction that is marked as exported (we'll get to this in a second), ComposeParts, which means create the attributed parts from the composed container or in English, look through all the libraries for anything attributed for exports and compose those into usable parts so that our application can call the CRUD methods identified in the interface. The following code is placed at the top of the service:


[ImportMany()]
public List Services { get; set; }


This contains a reference to the ImportMany attribute, another member of the MEF framework, identifies a storage place for reflected objects highlighted below. This list of IChannelService objects can be iterated over as a parallel query as seen in the ForAll extension method identified in the code above.

The only way to make all this work is to expose you classes/methods to the MEF framework via an attribute. In this case:

[Export(typeof(IChannelService))]


This exposes the class, inheriting from IChannelService to the MEF framework so that when ComposeParts is called above it know what to expose. This is the glue that bind.

There is much more to discuss including many import features and export features that make a very open framework. Please feel free to post if you have questions.