Archive for September, 2003

Open Source and TCO

I came to remember my thoughts on Open-Source software while talking to a friend after lunch today. The idea is that even though reuse of third-party software is something that a lot of companies want to encourage, we don’t really know the total cost of third party software.


The problem as I see it is that under almost any circumstance, an organization delivering a composite product is always responsible for the totality of the product. Buying third-party software might make this responsibility even harder to manage. A lot of my hardest problems have been with overly complex or simple third party components.


Even though “you can sue your subcontractor if they don’t do their job right”, I have never heard of any legal action being taken against faulty third-party component vendors. It might be theoretically possible, but if it doesn’t happen, what good does it do? Involving more organizations increases the bureaucracy and cost.


So in the end you are always responsible for the quality of third party components. And this is where open-source comes in: First, with open source, you have to recognize this responsibity up-front, so you can plan and budget for it. Second, the open nature of open-source makes you able to enact your responsibility.


(As I see it: The only disadvantage of open-source is where it doesn’t exist, or where the license is too strict for your needs)

Comments

Java tech to check out

Just a little reminder list to myself. Check out this Java technology before next Java project:


Comments

Fowler on Architecture

Read: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. The following is an except:

Ralph Johnson: So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ […] the architecture only includes the components and interfaces that are understood by all the developers.”

“[..] Johnson’s secondary definition [is]: “Architecture is the decisions that you wish you could get right early in a project.” Why do people feel the need to get some things right early in the project? The answer, of course, is because they perceive those things as hard to change. So you might end up defining architecture as “things that people perceive as hard to change.”

“One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible.

There is no theoretical reason that anything is hard to change about software.
If you pick any one aspect of software then you can make it easy to change,
but we don’t know how to make everything easy to change.”

Software is not limited by physics, like buildings are. It is limited by imagination,
by design, by organization. In short, it is limited by properties of people,
not by properties of the world. “We have met the enemy, and he is us.”

Comments

JavaZone 2003

I have just recovered from JavaZone 2003. This year was quite good. A lot of good speakers this year.

I had great fun holding my presentation. I didn’t get through my whole program, but I do think people were entertained, and that was all I hoped for. It is a real rush to present for such a crowd.

eXtremeProgramming.no god off to a good start. Along with the other funders, I got to meet Kent Beck. His presentation was very entertaining, and I really wish my boss heard it too.

A lot of the presentations seemed to be on the subject on how to get the domain model back into programming. The two approaches presented were MDA, and a more Aspect-Oriented view. The advantage of MDA is that there are actually working tools supporting it. The problem is that it adds a lot of complexity, and was obviously standardized by people who don’t understand programming! The AOP-related approaches are marred by fact that there is no coordination of the efforts of a lot of different people. But it occurs to me that proponents of the AOP-related approaches understand programming, but the MDA people really don’t. But MDA might be the most complete framework available today.

The “AOP-related” speakers included Richard Öberg (using AOP), Totto (a collection of patterns to avoid obscuring the program by infrastructure code), and Jon Bratseth (the Simplest Possible Infrastructure Framework - spif uses strategically placed interceptors to decouple infrastructure code). Kevlin Henney’s presentation also included a lot of strategies for simplifying programs.

I am hoping to be able to show a more visionary presentation of the full story behind both the MDA, and AOP-based approaches in the future. I feel this is something all developers should care about.

Comments

Review: Infectious Greed

Infectious Greed: How Deceit and Risk Corrupted the Financial Markets
by Frank Partnoy is a fascinating book. Partnoy describes how the ever raising performance-related bonuses for brokerage bankers in the 1980s lead the brokers to create a succession of schemes to inflate bonuses.

The early waves of this phenomenon was in the dervatives business. Derivatives are financial instruments the payoff of which is determined by other factors. The stated purpose of a derivative is to sell the risk related to something to someone who is better prepared to handle it.

Dervatives can be linked to everything like from the price of a stock (options), the future price of a commodity (futures), the relative exchange rates of two currencies, or interest rates. Derivatives can even be linked to things like the weather. Now, weather derivatives may sound like nothing more than gambling, but in fact, industries like hydro power plants, farming, and travel depend critically upon the weather.

The real problem comes from the fact that when you sell risk, it is very hard to find someone who is really in a better position to handle it. As all derivatives are null-sum games, this means that it is in practice a gamble that big financial insitutions are allowed to make with the money they hold. Examples include mutual fonds, pension fonds, insurance fonds, and municipal authorities.

Around 1990, derivatives were made more and more complex. Buyers of derivatives were making money, but no one could predict how changes in for example the federal interest rate would affect people. Around 1992, the tables turned, and many investors learned the hard lesson of gambling: The house always wins. The house was the brokerage banks. The losers included for example Orange County, California, which went bankrupt from its investments in derivatives linked to the federal interest rate.

So, in the mid-90s, investors were scared off of derivates, and the brokers needed a new scheme to get their multi-million bonuses. What had made derivatives good was this: It was extremely difficult to assess their risk and value. Investors considered the only safe bets to be in stocks. So, the brokers wanted stocks whose value and risk was very hard to assess. Enter .com.

Partnoy provides a convincing explaination of the .com-phenomenon, which is very sobering to technologists: No-one never believed we could produce the values we thought they believed in. No-one never believed in us. We were just pieces in the game to deceive investors with financial instruments whose risk and value were hard to assess.

The book is depressing, sobering, and upsetting. The attitudes Partnoy describes are disturbing and sickening. The book is very well written, and reads easily. I guess the moral of the story is: There is no such thing as a free lunch. You always pay in the end.

Comments

Creative Commons Attribution 3.0 Unported
Creative Commons Attribution 3.0 Unported