- "Service Oriented Architecture" is an empty buzzword label designed to squeeze money out of unsuspecting clients
- Good ideas (e.g: "role playing" a presentation) needs to be executed flawlessly to be effective and cannot be substitute for a belief in what one is speaking about.
- Having one set of people selecting topics and another set of people being "volunteered" to speak is a terrible way of attempting to deliver a great speech/session.
- Having original insights arranged in a logical structure is key to a good speech. Presentation skills provide a final finish.
- Insight arises from taking the time to rigorously think about what is important, and by asking "why" for things everyone takes for granted.
- Here is a way to test your "hacker quotient" (assuming you are a programmer). How much of your code is written by you wanting to code it vs having to code it?
- If a series of sessions is to be arranged on a single theme, care should be taken to have them rise to a peak, in terms of quality of content and speakers. An abrubt decline in (relative) quality drives the audience away (fast).
- If you don't have a good, genuine question to ask the speaker after a speech, for God's sake, shut up and sit down. Nobody thinks you are smart if you ask vague, inchoate and stupid questions .
Saturday, April 08, 2006
Learning from a Master{Class}
I attended a series of lectures on technical topics today and here are my "take away points" in no particular order.
Subscribe to:
Post Comments (Atom)
3 comments:
Ravi,
I am an avid reader of your posts and enjoy them very much. But, something I noticed is that I dont see you talk too much about enterprise programming. Now, I dont know if it is due to your dislike/inexperience or some other reason.
I have seen an enterprise group grow through difficulties trying to consolidate what they have developed into a single maintainable platform. I have seen first hand, an enterprise system's ongoing struggle through trying to structure something like that. They never got to start from level zero highly maintainable/portable/upgradable technologies or architectures.
Why I said all this is to argue your first point - SOA - As I understand it, it is a way of consolidation for these guys who are trying to make a whole platform inter-operable, without going through nightmares of knowing that the version of visibroker they are on is going to be without support in a year's time, while they are just going through a websphere upgrade.
Anup.
"I dont see you talk too much about enterprise programming."
That is because I don't do any "enterprise" programming these days :-) No more no less.
"I dont know if it is due to your dislike/inexperience"
No dislike. And lots of experience. I *am* against the *way* in which enterprise softwrae is currently developed, especially in an off shore, "cheap indian ", bodyshopping context.
Now this particular blog entry is made in the context of a particular technology meet I attended yesterday. Unless you were there some of what I said may not make too much sense to you (that is all right!).
The speaker who spoke of soa is very articulate, technically proficient, and a good friend of mine.
The problem was with a content-lite topic, not with the speaker, who did a good job presenting the concepts.
That being said, "SOA" is just (imo) old wine in new bottles. Your application should (of course) be composed of loosely coupled(to the degree possible) subsystems and provide cohesive service facades that make sense in the domain.
These subsystems should respond to xml-rpc/corba/soap/blah messages where appropriate. these are all very standard software principles.
If top notch enterpise programmers programmers (like some of the people who work in Thoughtworks), work in a stress free environment, and are allowed (and encouraged) to do their best in terms of code and design, you will get "service oriented architectures" automatically.
Th points you raise (which version of visibroker for e.g), if they are serious concerns ina codebase ,seem to indicate incompetence in the design and architecture, either in the present team, or more likely in the original team which created a (what is now legacy) code base.
No decent architect/programmer (and I have worked as both in the enterprise software world, the latest being in Thoughtworks a couple of years ago) would tie a system into a particular version of an ORB.
A "Maintainable platform" should be the **default** state of enterprise software. You don't need new buzzwords for that. You need good programmers and a good process("agile" anyone?).
*I* think "soa" is an empty buzzword. To confirm my impression, I had extensive conversations with some very (very)technically capable folks in the audience (some of the best people in software, I have ever met).
*Without fail* everyone was deeply skeptical of "SOA".
When all the good people are skeptical of a concept and all the dumbos lap it up, you know which side is probably right :-)
Anyway, as you know, I have no problems with people disagreeing with me. :-) If the concept worked for you /enabled you to do things you weren't before, more power to you !
*I* found it a complete waste of time/neural cycles.
Ravi,
I completely agree with the speaker that it is old wine in new bottle. But, i deal practically here when i normally talk about these generic architectures/frameworks. It enables me to get my architect to think differently of how crappy the existing system is.
Most of these architectures are old, and things have changed, the way we think of interoperability and such. SOA, I think of like the term "framework". It is just documenting what should have been done in the first place.
So, essentially, it is more of "Think differently, you moron" Cos its a new standard...because they dont think differently otherwise.
The point is that i think it is a reiteration of thought architectures. But if that is what it takes to get through some thick skulls, Im all for it. empowerment :-)
Post a Comment