20100906

The problem with MVC [introducing Triple D]

Here is the problem with MVC; it is not fit for the purpose to which it is often misused.

I have had endless arguments with developers over what is the Model and what is the View and what is the Controller and where the line is. The problem is that line is obfuscated.

What is a "view" or a "model" or a "controller"? It should be pretty easy to define, but it simply is not. A database instance is a de facto example of a model (assuming your application has a database). But a database can also contain a view. Your GUI is a view, but it also has a model, but it isn't the model from MVC, it is simply the model of the GUI, and so on.

MVC is fine at a high level. We can say Apache Struts is MVC. An Architect can say here is the "Model" and this is the "View" and this is the "Controller". But at a granular level this becomes more complex to discuss in an MVC context.

At the lower Object Oriented level developers require a common language that help them identify specific classes and their purpose. Enter Triple D.

Triple D = Doing Data Display (DDD)

This is a way for developers to discuss and purpose lower level objects without getting confused with MVC terms.

There is much more to discuss on DDD, but the premise is simple: Every object in a system has a purpose. It is much easier to identify that purpose if you can quickly categorise that object.

Each level of either M, V or C can contain all three types of Dobject and by categorising the object in Triple D and documenting it as such, following developers can know instantly what additional things they should or shouldn't add to that object.

Objects can be one or two Ds, but never all 3. If you have objects with all three Ds then you have failed every aspect of Object Oriented Analysis/Design/Programming.

Example: An object provides a GUI button for display. By this we know that it has to be a Display object. We also know that it needs to display some kind of text which can be set to it, so it is also a Data object. Therefore, it should not be a Doing object as well.

Looking at existing GUI frameworks we know this to be true. When we create a button we pass it a listener (Doing) object that will perform some business logic when the button is pressed.

By sticking to the Triple D principle developers can easily communicate during any stage of development what  type the object is and isn't, without trying to apply MVC to low level objects.

20100723

Why Facebook is the next Yahoo!

I am not sure that I actually need to point this out because there is no chance I am alone in thinking that Facebook is quickly becoming the next Yahoo! for better or worse.

Let's examine the evidence:
  • Fast growing.
  • People are still suprised over it's success and speed thereof.
  • Appears to act like it's the centre of the internet.
  • Appears to be dominant.
  • Appears to be extremely profitable in a short space of time.
  • Appears to be at the forefront of web development.
  • Appears to believe things will always be this way.
Everything listed above is exactly what was almost ubiquitously believed about Yahoo! back in 1998.

Yahoo! used to be the place to be, it was everything to everyone, had it all on one page and then index the "entire" web. Sure there were other competitors, but at the end of the day Yahoo! was king, and at the time very few people could have predicted it's fall.

Think about it, who would actually take on Yahoo! for web dominance? Even Mr Page and Mr Brin probably thought their little venture would end up selling to Yahoo! I can imagine the conversation:

L: Hey, we should do that idea for a search engine algorithm.
S: Yeah, but what's the point? No one will beat Yahoo! they are dominant.
L: Yeah but that doesn't mean we shouldn't try.
S: True, it could be huge and if not we could use it to get jobs at Yahoo!

Yes, believe it or not the founders of Google probably once dreamed of working at Yahoo! in the same way many now dream of working at Google.

Yahoo! probable seemed unbeatable and forever dominant, they had cornered the search and homepage market of the internet and I'll bet many executives and investors thought that too.

What were the odds that one of the biggest selling features of their destructor would come from the simplicity of Google?  Those of you who were there will remember the revelation on discovering Google for searching was that one of it's major appeals was speed. Speed it took to load the home page and speed it took to search. Google themselves were so proud of the speed that they announced it on every results page.

Facebook are looking at the same problem that Yahoo! did. The same problem which Yahoo! never recovered from. When you are the king, there is always a successor.

Speed on the internet isn't such a problem any more, unless you live in my house. But simplicity is. Credit to Facebook they have changed their layout several times and they persevered with change even in the face of user complaints. But it only takes one person to have an idea based on simplicity that Facebook will overlook for it to come crashing down to the floor.

I don't know what that idea will be, but history tells me that it will come as Facebook continue to become  Yahoo!. It is not so much a "maybe" as a "when". It is an inevitability.