This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Simple ?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
So, what does simple really mean ?
Simple is not easy.
I am always surprised when the simple code I write actually does what I intended. Why is that ? Well, when I write complex code, it usually comes out of applying some design pattern, and then debugging, refactoring, checking, fixing, etc... When it finally does work, I'm not surprised that it works. Why ? Because when I go through that terrible process of getting it to work, in my mind I'm always thinking "this should work, why the $#@! isn't it !?"
I'm always more satisfied when I get complex code to work. Why is that ?
I think maybe because its a challenge, and I like challenges, I feel that they bring out the best in me.
When the simple code that I write actually works, I get no satisfaction. Probably because there wasn't any challenge.
Psychologically speaking, I like being satisfied. Thus, if writing complex code is more satisfying than writing simple code, I guess that would push me to write complex code. So, writing simple code is somewhat against my nature.
So, writing simple code demands an effort, going against my nature, my instincts. Just because I see that a Flyweight pattern would go great here, doesn't mean that's what I really should do.
I guess that when I write complex code, I'm not working at the proper level of abstraction. I'm up to my elbows in "code", not in what the system is about. Most of the design patterns that are out there deal with code, but not with the system that the code makes up.
When working totally object-oriented, I find that I get pushed into complex code. Why is that ? Maybe its because the object isn't the proper level of abstraction. I tend to get either bloated objects, or such intertwined lattices of objects and hierarchies that I can't really do anything easily anymore - although having computerized refactoring ( like in most of the Java world ) makes the lattice a little less rigid.
This is why I like the "new" SOA movement. Although its really been in existence from the 70s. Services, not "XML Web Services" trademarked, incorporated, blah blah blah have been around a long time. SOA - service oriented architecture, is just that, an architecture, which can be applied to almost any system, in any environment, built upon any framework. The famous "Layered Architecture" when done properly becomes an SOA. A properly built "Layer" behaves just like a service.
Remember that architecture is something that deals with the logical layout of the system, and not so much the physical/deployment part. I guess that that's been the cause of a great deal of misunderstanding about the whole SOA thing. When I say service, most people assume that I'm talking about a windows service, or some other deployment entity.
Just a small aside - I am sick of hearing about 3-tier architectures. A tier refers to a physical deployment. Anyone who is busy thinking about how to physically deploy the system before having a thorough logical understanding of what the system really IS, is in for a long, painful, project. Even if when saying "tier" in the above term really means "layer", I think that the magic number 3 has lost its charm.
Before I go into how to do a simple architecture, I'm going to go talk to some users.
That's all for now.
Previous Topic
