CIO magazine has an interesting article on one company’s success with outsourcing; I’ve posted some excerpts over
It’s a good article because it fully embraces the perspective of the CIO who just wants to/has to save money. As a programmer, I usually get nothing but the opposite perspective about outsourcing: understandably so, as “outsourcing” to an American programmer translates 1-1 with “shit-canned.”
As the man says, “Oh, smashing, groovy, yay capitalism!”
Also, as a previous poster has pointed out, you should be aware of the cultural differences. Europeans and Americans have many more cultural differences than you might imagine. You see them as disorganised, unproductive, and process bound. They probably see you (generally, not personally) as willing to work unreasonable hours rather than have a decent lifestyle, lacking in any formal methodology, and willing to start coding too soon. It’s all a question of perspective :-)
Unrelated, but a good quote from another thread,
[T]he investment you put into a company is always more than the investment the company puts in you. When you lose a job, who hurts more? You or the company?
Citing purchasing delays and the troubled economy, a flurry of software vendors have already warned that the numbers will be grim when they release later this month their financial results from the quarter ended June 30.
My mother sends this from Florida:
G’ma is enjoying herself,
she swims laps in the pool daily.
As far as books are concerned, I highly agree with you but also disagree.
One habit that Americans do that I am not aware of that occurs in other
cultures is reading while in the bathroom. We bring newspapers into the
crapper. Why not bring a book? Online is ok, but by purchasing books one can
learn even more than our counterparts.
All ya’ll dorks totally need to listen in on the AgileOutsourcing mailing list. It’s entertaining to no end: the posters are either incredibly pompous or (as above) just outright funny. I can’t remember for sure, but I believe the poster of the quote above dubbed himself “The Father of Agile Outsourcing.” Such a title equals a strong YUH! rating.
Just sign up for the daily digest, and have yourself a good scan every evening. It’s an interesting topic, and there’s actually good dicscusion from time to time. Essentially, it’s de-generating into two camps: “American coders are lazy ass-waste that should be outsourced” vs. “Non-Americans can’t produce quality code/working with other timezones is difficult.”
An interesting article over on InfoWorld (pardon the choppy sentence there). I haven’t had time to think too much about it, but it made me think that there’s been a real trend lately, in the trade rags and anaylist chatter, towards system integration. Maybe it’s just blind excitement, as usual with the integration topic. At the very least, the integration focus seems to have a more componentalized motif than usual: that is, instead of just saying “businesses want/need to integrate their IT/applications,” the actual architectural notion of the integration being extremely component based seems to be creeping up.
Or maybe I’m reading too much into it. At the very least, “everyone” seems convinced that your product must be able to talk with other products, by (1.) at least inputting and outputting data real-time, and, (2.) on the frilly end, they should be able to tell each other to do things. One can imagine that missing piece is that, from a high-level perspective, you’d never know you had seperate products, you’d just have “The Business Process,” but that’s pretty pie-in-the-sky at the moment.
Usually a website that forces sound on you is anoying as all hell, but this one is super-dope! After all, if I’m going to a band’s website, I’m interested in their music, esp. if I just heard there’s a new album. I’m sure it could get anoying after awhile, but at first blush, it’s cool.
We had the right idea in the beginning
And and we just need to maintain our focus, and elevate
We what we do we update our formulas
We have certain formulas but we update em
with the times, and everything y’know
And and so.. y’know
The rhyme style is elevated
The style of beats is elevated
but it’s still Guru and Premier
. . .
Here’s how BAM works: In EAI, applications talk to one another through a message bus, called a publish-and-subscribe model. BAM acts as a wild card to a lot of different events coming across that bus. The message bus duplicates the event and sends it to the monitor. “Sort of like a sniffer,” Gassman tells me.
. . .
BAM for IT people provides business service views by correlating the infrastructure with the delivery of a business process. For example, it’s no longer enough to know after the fact that the credit card validation process took 10 seconds; rather, the system needs to monitor the operational time itself, not just downtime. BAM can make this happen: If IT service guarantees say transactions will be complete in 5 seconds, BAM notes when the time goes beyond 5 seconds and triggers a warning. Perhaps the warning also executes a command to another system, giving the process a boost to get the validation completed before the buyer disconnects.
From a TIBCO BAM Whitepaper we get these 3 steps/components:
- Modeling – the ability to model the business processes. This would include capturing rules and relationships, I’d assume, and defining the essential entities that are being modeled, e.g., PO’s, inventory, networks, etc. See BMPL for something that sounds like this.
- Interface – an interface that collects together all the data, filtering out the fluff, and provides contextual information:
Systems that provide real-time alerting have been around for a while, but the
combination of real-time notification and hotspot identification along with
supporting information in context is unique to BAM - especially in environments
with many applications and data sources.
- Data Integration – being able to pull business data from all the otherwise disparate data sources.
That’s just a quick overview. The TIBCO whitepaper is actually quite good: the sales pitch is limited to a few paragraphs on the last page.
Hide your ugly code inside a Ghetto. The ghetto is a single file or class where issues of code cleanliness do not apply. It is entered by reputable developers with no small amount of trepidation, and left as quickly as possible. On the other hand, it does the job, and it keeps the bad elements away from more cultured code.