Over the last years I had the opportunity to work on projects for really big companies. My initial observations led me to think that the bigger the company the more inefficient its IT operations are. Economies of scale seem to work against Information Technology and software: the bigger the company the more inefficient, bureaucratic and slower it gets.
But it would be too simplistic to say that it’s just the “size” of the company what makes it inefficient. It’s not. There are big companies that are efficient. True, the bigger the company the harder it gets, but I think it has more to do with the company’s age, culture, and the simple fact that they are inadequately structured.
One important problem I’ve seen in big enterprises is that people are departmentalized by specific roles (Business Analysts, Software Engineering, QA, Operations and Support, etc) and they do not collaborate as they should: they actually fight. They see each other as the enemy. Their jobs are so “silo-ed” that it’s hard for them to see the work of others.
A guy in charge of IT Operations for a huge financial firm described it to me with examples:
“We get a request to put an application into production with little idea of what it does or how it behaves. The application might have been in development for over a year, but we (Operations) do not get to see it until it goes to QA… which is roughly a few weeks before going to production.”
A big problem: developers do not understand how their solutions are really used in production, and Operations has no input into the development process. A lot of non-functional requirements that are essential for keeping Operation costs down may not be taken into account (like proper logging and monitoring, management of the dependencies).
The Business people blame Operations, which in turn blames the Development team for building unmaintainable software, and the Developers blame it all back to the Business people who never gave them the full requirements in the first place, nor enough time to build it right. But since nobody is responsible for the whole thing, no one fixes it. And every new project is run in the same way.
In small companies (think “start-ups”), individuals wear many hats: from “business analyst” to “operations support”. They are all accountable. I bet they are much more efficient. They may produce better solutions, in less time, with shorter release cycles, with less money, leaving happier customers and happier employees.
If I were a chief, I’d try to use a different approach from that of a traditional company.
Did you know about gotAPI.com?
It provides as-you-type lookups of reference documentation for HTML, CSS, Java, Perl and other programming languages and APIs.
Old news: BEA Systems acquired Fuego Inc..
Starting March 1st, virtually all Fuego employees (including myself) became BEA employees. There are few organizational changes, which helps minimize disruptions on our productivity and service.
I’ve been with Fuego since its early days. I started working for Fuego’s ancestor company, InterSoft, as a Java/C++ developer in 1997.
I have different feelings about the acquisition. On the one side I feel a bit nostalgic: the company I somehow helped build is no more. But on the other side I’m proud to say Fuego was no “bubble”, and I’m very positive that BEA’s infrastructure and steering will provide the power to support the crazy growth we are experiencing, and bring the product to the next level.
All analysts are talking about BPM systems these days. BPM became a buzzword in the Enterprise software market. This is nothing but a proof of how far ahead the founders of Fuego were (and probably how clueless some analysts are?): the product itself was started in 1997, and it was called jBPM (yes, the same name later taken by the now JBoss-sponsored jBPM project).
I’m at the Saint Louis International airport (STL), waiting to board on my flight back to Dallas. I have just experienced another stupidity of the airport (in)security procedures. This post is not about software, but software security and “physical” security depend on each other.
It’s an American Airlines flight. You can usually do the check-in procedure online, and print the boarding-pass yourself before heading to airport. This is a welcomed service, but this time it gave me an error, something like: “Sorry, you cannot check-in online, please see an agent at the airport”.
No big deal. At the airport I used one of the automated kiosks to print my boarding pass. And it worked, without the need of an agent.
I proceeded to security screening. The TSA officer highlighted a “SSSS” imprint on the lower-right corner of my boarding-pass and said: “you’ve been randomly selected for additional screening, please come this way…”.
I couldn’t believe it!. They randomly selected me for screening, but they warned me about it in advance!… I mean, now I (and you) know that if a passenger gets a quadruple-“S” code it means he/she will get additional screening!
I asked the TSA guy how could the process be so flawed. He replied that he understood my concern, but he was not responsible for defining the process and couldn’t give me his opinion. Later, I asked one of the American Airlines agents:
After nearly two years of procrastination, I finally decided to spend some time on wrapping things up and putting AntDoclet online for public consumption.
AntDoclet is a little tool for documenting Ant Tasks. It automatically generates HTML and LaTeX documentation from the source code of your Tasks.
I wrote it initially in January 2004, for documenting the Ant tasks provided with the FuegoBPM product. Recently, I needed to improve it a bit, and decided to make it public.