Sharing Trough Implementation Patterns

The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who've thought carefully about how to program, but when I read them what I hear is a set of commandments, "Name variables like this, arrange your code like that, etc" and all those are good things to do in certain circumstances, but what doesn't ever come true for me is why? What's the context, what stage needs to be set before that's the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn't necessarily working well. So by writing a pattern kind of format I get a chance to say: "How do you name fields?" Well, let's see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don't work well for a variety of reasons, but why? Really long names don't work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don't really get it in the same sense that I care about, and more importantly when that is not the right rule, they don't get any sense of what thinking was behind that rule, so they don't know when to break it.

Source: "Kent Beck on Implementation Patterns" on infoq.com

The main point in Kent Beck's words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.

Sun is Buying MySQL

It should be something related to the sales period as the same day that Oracle scoop BEA Systems, Sun Microsystems announced it has entered into a definitive agreement to acquire MySQL AB for approximately $1 billion.

MySQL was forecasted to set an IPO this year, but it seems that with the difficult conditions of the stock market its initial investors have chosen the easy solution to cash their money by letting Sun acquire the company.

For Sun, who recently changed its NASDAQ stock ticker from SUN to JAVA, it is a confirmation that the new strategic direction is in software and services. This move is therefore an important step to transform itself more in a service oriented company. With MySQL, Sun acquires a fast-growing company that has already a dual open source-commercial approach. Its estimated 2007 revenues were around $70 million. It is also a quick and good ticket to enter the database market already occupied by its competitors (Microsoft, Oracle and IBM). We suppose that Sun will not touch a lot to the existing MySQL organization. Being backed by a bigger company will bring an increased credibility and a better sales channel. Sun could also provide additional resources to improve its product so that it will become a more fierce competitor against Oracle.

The acquisition could also help Sun to propose its own alternative to the open source Linux/Apache/MySQL/PHP (LAMP) architecture. As it put its Solaris operating system in open source last year, it could propose a Solaris/Apache/MySQL/Java (SAMJ) pack that could be optimized. This could be a real alternative to the Windows ecosystem that is backed by a “old” company, thus allowing medium-size companies to have the impression to make a safer transition than with a pack of dispersed open source projects.

This move also changes the landscape for the other companies operating in the open source database area, like PostgreSQL and Ingres. However it is also a financial validation of the open source commercial model and some companies could end being the target of a bigger fish in the future. I will not be surprised if companies like Red Hat, HP… or Yahoo! will make some acquisitions in the sector in a near future.

Oracle Finally Acquires BEA Systems

After a small one month battle with an offer at $17 for share last October, Oracle Corporation and BEA Systems announced today they have entered into a definitive agreement under which Oracle will acquire all outstanding shares of BEA for $19.375 per share in cash. The offer is valued at approximately $8.5 billion, or $7.2 billion net of BEA's cash on hand of $1.3 billion. It seems that the will of certain BEA investors to make a substantial gain and the fact that Oracle proposed a better price allowed finally the deal to be concluded, even if BEA board previously asked for $21. The current stock market situation is different from last October and this could be financially a good deal for BEA shareholders, also because it seems that nobody was ready to pay more than the previous Oracle offer.

What benefits could Oracle achieve with this deal? Technically, it will acquire Web server and transaction monitoring software expertise. Even if Oracle has already its own set of products competing with BEA Systems, its technical reputation is a little bit lower in this area. Combined market share put Oracle in the number one position in the middleware market. However, Oracle will have to play it tactfully to keep the core technical team behind BEA products. Financially, the acquisition could provide additional revenues, a strategy Oracle has followed these past years with PeopleSoft and other targets. In this area, Oracle seems to transform itself in a Computer Associates-like company, more driven by financial interests than technical capabilities.

In the winners side of this situation, we could certainly find IBM and Red Hat's JBoss, as uncertainty about the future of a product is always a strong topic that buyers will consider when the look for their Web server. Also some companies do not like to have too much of their software infrastructure locked to a single supplier. Losers will be BEA Systems customers, because a change of ownership always rise questions on the future roadmap of the products and the availability of knowledgeable people to provide some support. This is mainly true for BEA's Tuxedo transaction processing product, an old software that doesn't seem to fit into Oracle product portfolio.

Agile Software Development. Cooler Heads Must Prevail

I have been distraught at the level of dogmatism, bigotry, contempt, or just plain ignorance that I witness in the agile world. I am not blaming the topnotch agilistas, though they sometimes, and just for effect in writings and presentations, reduce their messages to their essential bones, to the slogan level, and they omit the context—both source and applicability.

As agility is crossing the chasm, however—as you can see if you attend any big software synod such as SD East or West or OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications)—many more people say (or repeat) rather uninformed messages with a strong conviction and little background, scoffing at anybody who dares to question their claims, even if it’s just a clarification about scope or context.

For writing these words, I’ll be shot dead as a traitor to the agilism cause, a defender of the waterfall church, a dinosaur, the über-curmudgeon, though I do value agility or agile practices in the proper context, and with the tainted glasses of my own 33-plus years of experience. But I would like my friends and colleagues to keep cooler heads, to question assumptions, not assume too much of a common, shared mental model, and contextualize what they hear, read, say, or write.

Source: Philippe Kruchten, Voyage in the Agile Memeplex

These are word of experience from Philippe Kruchten. It should be repeated that there is no silver bullet in software development and that many approaches will fail in specific contexts when their essence is not understood, but rather people are just trying to apply some recipes without intelligence and common sense. Every new approach will have its share of zealots that will apply them as strict religious rules. I am a strong believer that the success of software development depends more on adapting existing tools and processes to specific situations and not the contrary.