Audio Interview: Futurescale Chief Architect Cliff Hall

Complexity and chaos do not have to go hand in hand. And certainly there’s no greater need for organization than in a complex environment. Enter Cliff Hall, President and Chief Architect of Futurescale which offers architectural guidance and development expertise to aid in the implementation of Rich Internet Applications. Hall has more than 25 years of experience in the software development industry. Prior to founding Futurescale, he delivered solutions for such companies as About.com, Prodigy Communications/SBC, and Register.com. He possesses a solid understanding of the principles behind robust and scalable enterprise software design. Cliff Hall speaks with Ecommerce Developer’s Kevin Patrick Allen.

Transcript

Kevin Patrick Allen: For Ecommerce Developer, I’m Kevin Patrick Allen. Complexity and chaos do not have to go hand in hand. And certainly there’s no greater need for organization than in a complex environment. Enter Cliff Hall, President and Chief Architect of Futurescale which offers architectural guidance and development expertise to aid in the implementation of Rich Internet Applications. Hall has more than 25 years of experience in the software development industry. Prior to founding Futurescale, he delivered solutions for such companies as About.com, Prodigy Communications/SBC, and Register.com. He possesses a solid understanding of the principles behind robust and scalable enterprise software design. Cliff Hall is our guest today. First of all, Cliff, thank you very much for your time.

Cliff Hall: You’re welcome, you’re welcome. Thanks for your interest.

Kevin Patrick Allen: I have a basic understanding of the model-view controller meta pattern and I know that it dates back to 1979 and I may get the man’s name wrong, but I believe it’s Trygve Reenskaug. Would you describe for me what makes MVC effective and explain why developers should use it?

Cliff Hall: Well, as you mentioned, 1979, that’s eons in software development time so this is a concept that’s been around for quite a while and the reason for its continued relevance really is that it’s abstract enough to apply to basically any object-oriented platform and it isn’t very complicated. It doesn’t have that many very specific rules. It separates the code for any application into three functional areas and defines just simple basic rules for how occupants of those areas should communicate with each other. So, it doesn’t dictate a lot. What you get is you get much cleaner code. Why developers should use it, I mean there are lots and lots of reasons really, but first you have in stock a methodology that keeps your spaghetti code to a minimum and it improves your development speed and reliability of the speed because, you know, when you’re developing, you know, every function doesn’t have to be a road block where you begin to wonder, “Well, how am I going to wire this up?” and get my data from this server into the view and continually be making decisions about how to do that sort of stuff. Reliability because when you have a methodology, you tend to do things the same way over and over and that makes for reliable code.

Kevin Patrick Allen: So, for a developer out there…

Cliff Hall: Yeah, go ahead.

Kevin Patrick Allen: That would ask just, you know, “Why can’t I keep these separate myself?” somehow you would say that it’s better organized this way?

Cliff Hall: Yeah. You know, I’ve spent a lot of time, I started out writing machine language and went on through Basic and on into Perl and Java and over the years slowly began to understand the reasoning behind an object-oriented approached programming. I used to have this thing I call the unified file theorem. It was put everything in one file. That way, it’s faster on the interpreter if you’re running an interpreter language and it’s easy to understand or write these web applications in Perl. That would be these big Pachinko machines basically where you pass down all of these modes and it would follow down through all of the switches and find itself in the right place and it was certainly a pattern where you could find, okay, if we’re in this mode and the sub-mode, then down your line 2000 that’s where you’re actually going to begin executing some code, but the problem is that in these big monster file applications like that, only one person can ever be editing at once. So, that’s the reasoning for breaking all of your functionality into the actors, into different classes that do things, the object-oriented. Why would you even be object-oriented to begin with is the first question a lot of people are really asking and if you’re going from a point of view like I was doing with the unified file theorem, I can remember forking aside the evil eye as Java and things like that were yet all these classes just turned in terms of classes and it just seemed like complexity for no reason at all, but really what it is, is you’re breaking down the functional parts of your application into discrete entities just like you would a business. You’re going to have a receptionist and you’re going to have some developers, you’re going to have some people who are back in shipping, shipping out [unintelligible] products, whatever, and everybody has a role and they’ve got responsibilities and they also have patterns for how they interact with each other. Everybody in the company has a view on the company based on the other people in the company that they have to interact with on a daily basis. [Unintelligible] understand that a company that doesn’t have these sorts of patterns can be sort of difficult to work with. You don’t know who to talk to for what and so companies that really get this end up being very successful. This is true in our code as well. MVC is just basically how can we if we’re going to separate this code in all these classes and how can we make these roles and responsibilities do this very, very simple thing like separating your laundry. How can we keep the stuff that defines our model, our crown jewel of the system that defines our data, how can we keep that all from becoming adulterated by the logic of the application that you may have multiple applications and [unintelligible] stay there and they all need to do different things with it and so fort and so how can we keep that model data safe and then how can we when we have our different applications that need to have their different views on the model and allow you to do different things with it, how can we separate the code that presents stuff to us in the view from the stuff that orchestrates how we update the model and sort of help buffer that view code from having to do so much stuff with the model. That’s where the spaghetti comes from is every class being able to do to access any other class for anything at all. That’s pandemonium.

Kevin Patrick Allen: Is that more or less…?

Cliff Hall: That’s exactly why you really want to apply this sort of stuff. It’s going to bring some order to your code.

Kevin Patrick Allen: That was the motivation really, to put some order into the whole framework?

Cliff Hall: Yeah. By the time I got around to doing pure MVC, I had moved from doing server side stuff to doing client side stuff and Flex, loose, just fresh out of beta and I was using this framework called Cairngorm from some guys who eventually were bought by Adobe and it was really great because it did this thing for me. They had already done a number of these applications and they had figured out, “Well, if we separate all these responsibilities like this, then here’s how we can write a nice, rich Internet application, a rich client portion of Internet, rich Internet application in a nice, orderly way that the team can set about working on and that can be maintainable as a legacy. I’ve done that for a couple of years actually and it was just like any sort of product or thing that you use. You sometimes have developer love-hate relationship with it. It gives you all sorts of wonderful rewards for using it, but sometimes there are things that you wish were different and that’s basically what caused me to go out and write pure MVC and I was just very serious and I wanted something that wasn’t just another dreamed up on the spot sort of thing. I realized from Cairngorm that bringing in this industry standard patterns, which I recognize from Java, which is what made Cairngorm really attractive to begin with, I was thinking, well, you know, what is a simpler way of doing this and I began doing some research and Cairngorm doesn’t necessarily say that they are a model-view controller framework. It’s just a kind of micro architecture, they say, but I kind of had also heard of MVC and began to think, “Well, maybe it’s application here,” but the playing field has changed a bit. I mean 1979, the applications that were being written are different from the applications being written today. A rich client outside if a Flash player in your browser, some virtual machine, is much different than and talking to distributed services across the Internet for data is a lot of different than a CAD program, say, which was running on a local machine and accessing local resources and things like that. So, there were some twists that just sort of needed to be addressed to kind of make this pattern work for the business at hand, that’s building rich clients. So, I did quite a bit of research and each time along the way, I dreamed up a new name for a class and tried to give it a what’s this thing do. I knew I was off-track because I was bound and determined to stick with the known patterns. In the end, I think that’s really what makes it successful. I mean their implementation, the patterns used to have very small handful of patterns that are being used to implement a meta pattern that really doesn’t say what actors or classes need to [unintelligible]. So, to call it purist is just sort of a chuckle to kind of [unintelligible] because it couldn’t be [unintelligible]. MVC can’t be pure because it’s a meta pattern. It’s up for interpretation.

Kevin Patrick Allen: Cliff, in just a minute or two, we’re out of life here, I wonder if you have any advice for developers that want to get started with pure MVC?

Cliff Hall: I would say go to the website. Look in the documentation. Read the best practices. Read their benefits and there is a framework overview document and a best practices document that really kind of gives you of an idea of what the whole approach is about and there are plenty of [unintelligible] and utilities out there to extend the functionality of it. So, the first thing to do would be to sign up for the forums so that the second you have a question, you can pop in and ask it. It’s pretty thriving community going on there and most questions get answered the same day. So, make sure that you when you have questions, look through the forums because lots of these questions have already been answered and it’s always good to answer them again. People, it’s a constant collaboration. There’s a lot of history there, a lot of how you do things and it’s being ported to other platforms and so forth, on a platform that doesn’t have a whole lot of demos and you happen to know ActionScripts and Flex and [unintelligible] and you enjoy the project and consider porting over utility or a demo to your favorite other language and maybe help give that port a push.

Kevin Patrick Allen: He’s Cliff Hall of Futurescale and Cliff, thank you very much for your time.

Cliff Hall: Ah, you’re welcome, Kevin. Thank you.

View full post on Practical eCommerce Podcasts

Leave a Reply