Agile IT

Career Survey

Jared Richardson — Sun, 04 Jan 2009 18:00:00 CST

The upcoming Career 2.0 book is in high gear, but we'd like to include more than our experiences. Over on the Career 2.0 blog we've posted a few questions about your career. Best moves, worst experience, etc.

Please drop by and let us know, or send Matt or me email. We're hoping to gather nuggets of wisdom for the book, but we won't quote you without permission. ;)

What's your strategy?

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

Neal Ford — Fri, 02 Jan 2009 12:10:00 CST

This is the first in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. The first installment is about how the need for SOA arose: tactics vs. strategy.

No company starts out as an Enterprise, they all start as a company, with just a few employees. As such, their IT needs are small, handled by a small group of developers who can chat with each other over lunch about what's going on in the IT "department". As the business needs software, they have some process to get the requirements to the developers, and they write code. Thus, the accounting department comes to the developers and says "Here are our requirements for our new accounting application", and the developers build some version of it. Inside that application are some small parts of something that the entire company cares about, for example, some of the aspects of customers. Meanwhile, the marketing department comes to the developers and says "We need an application, and here are the requirements", and the developers build it. Of course, this application also encapsulates some aspects of a Customer (not the same as accounting, but possibly with some overlap). It is rare indeed that anyone looks around and tries to come up with a comprehensive strategy for application interoperability: you don't have time for that -- you're a small company, and if you don't get your software, you'll go out of business. This goes on for a while.

Then, one day, you wake up, and you're an Enterprise. The CIO looks around with dismay at all the actual entities the corporation cares about because they are scattered in bits and pieces in all these different siloed and packaged applications. And the database stuff is a mess, with shared tables and views and ETL jobs running on cron jobs. And the CIO throws up in his mouth, just a little. The CIO looks at the landscape, and realizes that the technical debt incurred over the last few years can only get worse from here, so he calls out "Help." Big software vendors are highly attuned to people in big companies (sorry, Enterprises) who can write checks saying "Help". They ride in with a solution wrapped around the SOA moniker. More about our friends the Enterprise vendors in a future part of the series.

What I'm concerned about in this post is the overall landscape, which is another way of asking "How did you get where you are now?" You got here because of 2 reasons: first, you took the path of least resistance when you were a company (before you became an Enterprise) because, if you had taken the time to build a comprehensive strategy, you'd have never survived as a company. Second, and more important, what is strategic to the business is always tactical to IT. Business people can go into a conference room and change the entire direction of the company in 2 hours. Or, the business may decide to merge with another company that has truly dysfunctional IT, but other business concerns override that. IT can never move as fast as the business, with means that IT always has to respond tactically to the decisions and initiatives brought forth from the business. No matter how much effort you put into a comprehensive, beautiful, well-designed enterprise architecture, it'll be blown out of the water the first time the business makes a decision unlike the ones that came before. The myth of SOA sold by the big vendors is that you can create this massively strategic cathedral of enterprise architecture, but it always falls down in the real world because the COO (and CEO) can override the CIO (and his sidekick, the CTO). If you can convince your organization to allow IT to set the strategy for what capabilities the business will have long-term, you should. However, your more agile competitors are going to eat your lunch while you build your cathedral.

Any enterprise strategy you implement must realize that you will always be in tactical mode in IT because the business strategy doesn't require physical labor. Any enterprise architecture you develop must allow the business to evolve according to it's wants (and needs). This is what my colleague Jim Webber calls "Guerrilla SOA" and what I call "Evolutionary SOA". More about the details ofp evolutionary SOA in upcoming installments.

Collaborating with Other Writers

Johanna Rothman — Fri, 02 Jan 2009 10:54:00 CST

Merlin, via 43 Folders Clips has a video of Eric Idle, on John Cleese’s Approach to Writing. Aside from John Cleese’s specificity, Idle talks about how he had trouble finding collaborators until he started working with John Dupre (I don’t know how his name is spelled).

Collaborating with other writers for natural language writing is difficult. I find pairing for code much easier, and even for code, I have trouble. No one can read my mind, I want to name variables something else. I want a different setup. There’s always something.

If you find some good collaborators, treasure your relationship with them.

Happy New Year

Johanna Rothman — Thu, 01 Jan 2009 09:38:00 CST

Everyone, I thank you for reading and commenting. I hope you have a healthy and happy 2009.

Ruby Conference in North Carolina! Ruby RX

Jared Richardson — Tue, 30 Dec 2008 18:00:00 CST

We turned the website on for Ruby RX yesterday. It's a regional Ruby conference in North Carolina. We may still tinker with the speaker list a little (one person might bow out and be replaced). If all goes well we'll take this conference to several other cities next year, much like the Java/Agile No Fluff Just Stuff touring conference.

Here's the URL: RubyRX

From the website:

Ruby is a dynamic, open source language with a focus on simplicity. Since it's release in 1995, Ruby is now among most popular programing languages. The Ruby on Rails web framework has created a major shift in the web development space. If you haven't experienced the simplicity of ROR's Convention Over Confituration model, it is time to learn what all the buzz is about.

RubyRX will cover a lot more than just Ruby and Rails. Other languages will be covered including: Clojure, Erlang, Scala, a

Video Posted: Lessons Learned in Project Management

Johanna Rothman — Mon, 29 Dec 2008 15:31:00 CST

The nice folks at SQE have posted my keynote from the Better Software conference, Lessons Learned in Project Management. Yes, some of the material is from Manage It!: Your Guide to Modern, Pragmatic Project Management.

P.S. Thank you for telling me the link was broken originally. It’s now fixed. Sorry about that!

Who Should Be a Product Owner?

Johanna Rothman — Mon, 22 Dec 2008 14:18:00 CST

At a recent workshop, one of the participants asked me this question, “We want to start a new Scrum team. But we are confused about who to ask to be the product owner. We have a choice of someone who doesn’t know how to be a product owner, is 10 time zones away, but knows the current product, the customers and what they want. We also have a choice of someone here (same time zone) but he doesn’t know the current product or the customers. Who’s the better product owner?”

What a terrible choice. I didn’t like either choice.

I would look for a third option. I would look for someone who is interested in being a product owner, can either learn the product or learn how to be a product owner, and is local so he/she can participate in demos and sprint planning. My colleague says there is no one who could do that.

My colleague wants to know who you would pick, of the two options above: a local person who doesn’t know the current product or customers, or someone 10 time zones away who doesn’t know how to be a product owner. Please leave a comment if you have an opinion.

Why Projects Don’t Need Specialists

Johanna Rothman — Mon, 22 Dec 2008 10:24:00 CST

I taught several PM workshops last week in Israel. The Israeli project managers have the same concerns that my US students do–it’s difficult to imagine moving to Agile or even just integrating agile methods into your project if you have specialists.

Specialists increase project delays in these ways:

They aren’t available when you need them. Because they are specialists, it’s too easy for the specialist to be busy on another task when you need that specific person. And, because you or the specialist estimate only the time the specialist needed, if you ask anyone else to do the task, the task will take too long.

The work backs up. No, you don’t need a specialist all the time. But when you do, you need them. So, since work doesn’t arrive as an even distribution, but instead arrives more in a Poisson distribution, the specialist has some periods of time when they aren’t busy, and more times when they have a queue of work.

Murphy’s Law will happen. Just when you need a specialist, that person will want a vacation, or want to get married, or go skiing for two weeks, or have a baby. Or, leave the organization.

PMs (and projects) don’t need specialists. They need people who are multi-talented and can finish tasks. Am I saying that we turn GUI designers into kernel developers? No, but there are many more things that a GUI designer or a kernel developer can do, rather than just one specialty.

If you have specialists now, rethink your staffing, and offer people opportunities to learn new skills. Your projects will progress faster and you’ll be more effective.

Look! Santa brought evaluations and a new column

Ryan Shriver — Wed, 17 Dec 2008 19:20:00 CST
Today while sorting amongst the pile of Christmas cards from friends and relatives, I noticed an envelope from the recent Agile Development Practices conference. I opened and found my session evaluations for Agile Engineering for Architects. In this internet-age, it’s weird getting pen-and-paper feedback forms from a conference over a month ago. But it was cool nonetheless.

So, the good news is I got all 8’s, 9’s and 10’s for an average score of 8.941. And yes, that’s correct, the person compiling my average score went to three decimals of precision...because 8.9 just wasn’t good enough! The bad news is that I only had 22 people in my session. Not bad I guess, but I’d like to get a better turnout next time. At least now I can say, “other people seem to like it” and not be lying. Actually, truth be told, I followed up with Lee Copeland last week asking if I was going to receive any feedback. He told me I had done well, the “2nd best amongst the non-silver tongues” and “13th best overall”.

Getting these evaluations today in person and seeing positives scores feels re-assuring that I’m on the right track with respect to the topics I’m covering. I got the Agile 2009 call for papers today and will plan on doing this presentation there. I’m sure by next August with all the readers I get I’ll have a full session ;-)

Oh, the second bit of news related to this Agile Engineering presentation is that I’m going to be doing some articles for gantthead.com next year on subjects related to agile engineering. Well, at least one needs to be on agile engineering, the others can be on broader agile topics. Doug DeCarlo found out about my work and asked me to contribute.

Like any software project, I have no idea what I’m going to do for my first article, but have a due date. January 15th.

Try What You Can't Do

Jared Richardson — Wed, 17 Dec 2008 18:00:00 CST
"Creative people should always try to do things they can't. That's when creativity is needed." -Marcel Wanders
When's the last time you tried something you didn't know how to do, just to stretch your brain a bit?
Marcel is a fashion designer (not a programmer), but his comments were very timely for our field. Think about software design when you read his next words.
"People think design is fluff, but it's a disciplined approach to something difficult. This is hard stuff that makes business better." and later "People who work in creative projects are excited to come to work. That's radical."
The really great projects are the ones we get excited about... recognizing the creative aspects of programming, including design, architecture, and implementation, is often neglected. How can we fix this?
If you're in management, recognize that an excited team works faster. Depressed teams work slowly. They come into work later. Leave earlier. Take longer coffee breaks and lunches. It's not in

Agile 2008 - Jochen Krebs - Agile PMO, Agile Portfolio Managment, Scrum and More

Bob Payne — Tue, 16 Dec 2008 07:43:00 CST
I talk with Jochen about his new Portfolio Management book among other things. He has been working on a large agile transformation and give some insights into his rollout of agile.

A great listen if you are looking at scaling agile.

-bob

MSI Wind: Kubuntu 8.10

Jared Richardson — Mon, 15 Dec 2008 18:00:00 CST
It took me some time this evening, and some helping/shaming by Dan Hinojosa, but I got X running on 2 monitors nicely on the MSI Wind. So I'm posting the xorg.conf details so I can find it next time I need it. :)
First, to conserve memory, X caps itself at the maximum resolution of the monitors it sees when it's starting. You fix that by adding the "Virtual" section to your Display block.
And in the "Device" block I added a few performance tweaks I found on the web.
It's still not as snappy as I'd like (and as I'm sure it can be). Anyone spot anything else I can add?

Section "Device" Identifier "Configured Video Device" Option "AccelMethod" "exa" #Option "AccelMethod" "xaa" #Option "MigrationHeuristic" "greedy" # mess up systray Option "FramebufferCompression" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifie

Ruby Conf Videos

Jared Richardson — Sun, 14 Dec 2008 18:00:00 CST
I spent a little time tonight watching some of the Ruby Conf 2008 videos. I especially liked Dave Thomas' keynote on forking Ruby. The parallel Ruby suggestions were very intriguing and looked very practical. Also, Nathaniel Talbot's Fear of Programming was great.
You can find them all at Ruby Conf 2008 at Confreaks
There are a number of others I'm going to try to catch this week. Looks like I missed some great topics!

OSGi explained

Andrew Glover — Sun, 14 Dec 2008 12:43:00 CST

Not long ago, I had the distinct pleasure of chatting with Sebastien Arbogast regarding OSGi for JavaWorld’s Java Technology Insider. In this hip fat-chewing session, Sebastien introduces the concepts behind OSGi and explains why its contribution to Java modularity is copasetic news for Java community. He also discusses the competing Java modules specifications (JSR 291 and JSR 277) and about application server migrations to OSGi; plus, he makes a tentative prediction about what might be coming next for this exciting technology.

If you are new to the term OSGi or just want to learn more about it, Sebastien does an excellent job of educating — I certainly learned a few things! Have a listen and see for yourself!

You can follow thediscoblog on Twitter now!

Attack of Self-Denial, 2008 Style

Michael Nygard — Sat, 13 Dec 2008 10:42:00 CST

"Good marketing can kill your site at any time."
--Paul Lord, 2006
I just learned of another attack of self-denial from this past week.
Many retailers are suffering this year, particularly in the brick-and-mortar space. I have heard from several, though, who say that their online performance is not suffering as much as the physical stores are. In some cases, where the brand is strong and the products are not fungible, the online channel is showing year-over-year growth.
One retailer I know was running strong, with the site near it's capacity. They fit the bill for an online success in 2008. They have a great name recognition, a very strong, global brand, and their customers love their products. This past week, their marketing group decided to "take it to the next level."
They blasted an email campaign to four million customers. It had a good offer, no qualifier, and a very short expiration time---one day only. A short expiration like that creates a sense of urgency. Good marketing reaches people and induces them to act, and in that respect, the email worked. Unfortunately, when that means millions of users hitting your site, you may run into trouble.
Traffic flooded the site and knocked it offline. It took more than 6 hours to get everything functioning again.
Instead of getting an extra bump in sales, they lost six hours of holiday-season revenue. As a rule of thumb, you should assume that a peak hour of holiday sales counts for six hours of off-season sales.
There are other technological solutions to help with this kind of traffic flood. For instance, the UX group can create a static landing page for the offer. Then marketing links to that static page in their email blast. Ops can push that static page out into their cache servers, or even into their CDN's edge network. This requires some preparation for each offer, and it takes some extra preparation before the first such offer, but it's very effective. The static page absorbs the bulk of the traffic, so only customers who really want to buy get passed into the dynamic site.
Marketing can also send the email out in waves, so people receive it at different times. That spreads the traffic spike out over a few hours. (Though this doesn't work so well when you send the waves throughout the night, because customers will all see it in a couple of hours in the morning.)
In really extreme cases, a portion of capacity can be carved out and devoted to handling promotional traffic. That way, if the promotion goes nuclear, at least the rest of the site is still online. Obviously, this would be more appropriate for a long-running promotion than a one-day event.
Of course, it should be obvious that all of these technological solutions depend on good communication.
At a surface level, it's easy to say that this happened because marketing had no idea how close to the edge the site was already running. That's true. It's also true, however, that operations previously had no idea what the capacity was. If marketing called and asked, "Can we support 4 million extra visits?" the current operations group could have answered "no". Previously, the answer would have been "I don't know."
So, operations got better, but marketing never got re-educated. Lines of communication were never opened, or re-opened. Better communication would have helped.
In any online business, you must have close communications between marketing, UX, development, and operations. They need to regard themselves as part of one integrated team, rather than four separate teams. I've often seen development groups that view operations as a barrier to getting their stuff released. UX and marketing view development as the barrier to getting their ideas implemented, and so on. This dynamic evolves from the "throw it over the wall" approach, and it can only result in finger-pointing and recriminations.
I'd bet there's a lot of finger-pointing going on in that retailer's hallways this weekend.

Conferences in Emerging Tech Countries

Neal Ford — Thu, 11 Dec 2008 10:09:00 CST

I speak at lots of conferences in the US and Europe, and they pretty much have the same feel (modulo different languages, both programmer and spoken). But I also speak at a few conferences in emerging technology markets, like my recent conference appearance for JAX-Asia, a Java-centric conference that happens over the course of three days in Singapore, Kuala Lumpur, and Jakarta. Attendees at these conferences are very much like attendees at conferences elsewhere: slightly geeked out, interested in learning about new stuff, and inquisitive. They also exhibit a lot of enthusiasm: there aren't as many conferences there as here, so going to a conference is a bigger deal.
I have two observations from my recent trip. I first observed (with the help of my colleague, Erik Doernenburg) that all the conferences in Asia have lots of sponsorships. Generally, attendees pay very little (if anything) to attend the conference; most of the cost is offset by vendor sponsorships deals. But along with the booth in the exhibit area, vendors get one or more keynotes. Now, I don't want to completely denigrate vendor keynotes. I've seen a couple that had actual content, not just blatant marketing. But, for the most part, the mode in Asia seems to be outrageous over-the-top marketing, making them not so much keynotes as "marketing-notes". Because most of the attendees aren't yet jaded and cynical, they stick around for the marketing-note, succumbing to the danger that their marketing bullshit detector is not as well honed as ones in the US and Europe. They might actually believe what this vendor is saying about SOA -- what a frightening concept! To their credit, the conference also books in regular sessions that offset some of the damage caused by toxic marketing-notes. One of my talks at JAX-Asia was my Evolutionary SOA talk, which is pretty much the polar opposite of what most vendors say about SOA. One of the reasons I like speaking at out of the way conferences like JAX-Asia concerns around this very issue. I'm very interested in providing my (and ThoughtWorks) perspective on technology and methodology to offset the message of people just trying to sell something. I genuinely want to advance the state of software development, which has no geographic boundaries.
The second observation from JAX-Asia is the span of sophistication of the attendees. Just like any conference, you get a fair number of wide-eyed innocents, who just discovered Ant last week and want more cool stuff like that. To those attendees, preaching about dynamic languages and other cutting edge stuff is pointless: their primary interest in the conference is shoring up their current development practice, not spelunking into the future of technology. But it's a mistake to assume that all the attendees are beginners. Like any conference, a wide variety of skill sets and experience show up. For example, for JAX-Asia, I did a talk on JRuby, and another comparing Groovy & JRuby. JRuby was one thing: at least a few of the attendees had heard of Ruby. But the comparison talk was brutal on both me and my audience. No one had even heard of Groovy, so discussing the nuances of the differences between a technology represented by a word they had heard ("Ruby"), with another technology for which no one was familiar ("Groovy") was tough. Yet, generalizations are dangerous. After my talks in Jakarta, I was chatting with one of the attendees, who turns out to be the president of the Ruby users group in Jakarta, which has 50 members! To me, this shows two things. One, never assume that the crowd to which you are speaking in homogeneous. Even if the majority are novices, chances are good that there are some experienced developers there as well. And, two, Ruby has managed to penetrate pretty far and wide. A 50 person Ruby users group in Jakarta encourages me greatly because it shows that the foothold that dynamic languages have in the US and Europe is spreading to other parts of the world.

Quote of the Week: Teddy Roosevelt

Matthew Bass — Wed, 10 Dec 2008 15:07:00 CST

“In the first place, we should insist that if the immigrant who comes here in good faith becomes an American and assimilates himself to us, he shall be treated on an exact equality with everyone else, for it is an outrage to discriminate against any such man because of creed, or birthplace, or origin. But this is predicated upon the person’s becoming in every facet an American, and nothing but an American… There can be no divided allegiance here. Any man who says he is an American, but something else also, isn’t an American at all. We have room for but one flag, the American flag… We have room for but one language here, and that is the English language… and we have room for but one sole loyalty and that is a loyalty to the American people.” — Teddy Roosevelt, 1907

All things Spring with Rod Johnson

Andrew Glover — Tue, 09 Dec 2008 12:34:00 CST

I recently had the pleasure of chatting with Rod Johnson for JavaWorld’s Java Technology Insider regarding all things Spring, baby. Spring has come a long way since its early days; in fact, a recent study shows spring adoption reaching 73% of Java development shops; plus, SpringSource, the commercial entity behind Spring, recently, acquired G2One (the entity behind Groovy and Grails).

In this conversation, Rod discusses how SpringSource walks the line between commercial success and its driving role in open source projects such as the Spring framework and Tomcat. Similarly, he explains what factors might cause developers to migrate from Spring’s strictly free and open source products to the commercial, and costly, SpringSource Enterprise package. He also chats about the new, OSGi-based SpringSource Application Platform, which Rod says is designed not for where the Java enterprise market has been, but for where it is going.

All in all, I had a great time learning from Rod and I hope you pick up a nugget or two listening to him as well, baby!

You can follow thediscoblog on Twitter now!

(Human | Pattern) Languages, part 2

Michael Nygard — Mon, 08 Dec 2008 00:56:00 CST

At the conclusion of the modulating bridge, we expect to be in the contrasting key of C minor. Instead, the bridge concludes in the distantly related key of F sharp major... Instead of resolving to the tonic, the cadence concludes with two isolated E pitches. They are completely ambiguous. They could belong to E minor, the tonic for this movement. They could be part of E major, which we've just heard peeking out from behind the minor mode curtains. [He] doesn't resolve them into a definite key until the beginning of the third movement, characteristically labeled a "Scherzo".

In my last post, I lamented the missed opportunity we had to create a true pattern language about software. Perhaps calling it a missed opportunity is too pessimistic. Bear with me on a bit of a tangent. I promise it comes back around in the end.

The example text above is an amalgam of a lecture series I've been listening to. I'm a big fan of The Teaching Company and their courses. In particular, I've been learning about the meaning and structure of classical, baroque, romantic, and modern music from Professor Robert Greenberg.1 The sample I used here is from a series on Beethoven's piano sonatas. This isn't an actual quote, but a condensation of statements from one of the lectures. I'm not going to go into all the music theory behind this, but it is interesting.2

There are two things I want you to observe about the sample text. First, it's loaded with jargon. It has to be! You'd exhaust the conversational possibilities about the best use of a D-sharp pretty quickly. Instead, you'll talk about structures, tonalities, relationships between that D-sharp and other pitches. (D-sharp played together with a C? Very different from a quick sequence of D-sharp, E, D-sharp, C.) You can be sure that composers don't think in terms of individual notes. A D-sharp by itself doesn't mean anything. It only acquires meaning by its relation to other pitches. Hence all that stuff about keys---tonic, distantly related, contrasting. "Key" is a construct for discussing whole collections of pitches in a kind of shorthand. To a musician, there's a world of difference between G major and A flat minor, even though the basic pitch (the tonic) is only one half-step apart.

Also notice that the text addresses some structural features. The purpose and structure of a modulating bridge is pretty well understood, at least in certain circles. The notion that you can have an "expected" key certainly implies that there are rules for a sonata. In fact, the term "sonata" itself means some fairly specific things3... although to know whether we're talking about "a sonata" or "a movement in sonata form" requires some additional context.

In fact, this paragraph is all about context. It exists in the context of late Classical, early Romantic era music, specifically the music of Beethoven. In the Classical era, musical forms---such as sonata form---pretty much dictates the structure of the music. The number of movements, their relationships to each other, their keys, and even their tempos were well understood. A contemporary listener had every reason to expect that a first movement would be fast and bright, and if the first movement was in C major, then the second, slower movement would be a minuet and trio in G major.

Music and music theory have evolved over the last thousand-odd years. We have a vocabulary---the potentially off-putting jargon of the field. We have nesting, interrelating contexts. Large scale patterns (a piano sonata) create context for medium scale patterns (the first movement "allegretto") which in turn, create context for the medium and small scale patterns (the first theme in the allegretto consists of an ABA'BA phrasing, in which the opening theme sequences a motive upward over octaves.) We even have the ability to talk about non sequiturs---like the modulating bridge above---where deliberate violation of the pattern language is done for effect.4

What is all this stuff if it isn't a pattern language?

We can take a few lessons, then, from the language of music.

The first lesson is this: give it time. Musical language has evolved over a long time. It has grown and been pruned back over centuries. New terms are invented as needed to describe new answers to a context. In turn, these new terms create fresh contexts to be exploited with yet other inventions.

Second, any such language must be able to assimilate change. Nothing is lost, even amidst the most radical revolutions. When the Twentieth Century modernists rejected the tonal system, they could only reject the structures and strictures of that language. They couldn't destroy the language itself. Phish plays fugues in concert... they just play them with electric guitars instead of harpsichords. There are Baroque orchestras today. They play in the same concert halls as the Pops and Philharmonics. The homophonic texture of plain chant still exists, and so do the once-heretical polyphony and church-sanctioned monophony. Nothing is lost, but new things can be encompassed and incorporated.

And, mainframes still exist with their COBOL programs, together with distributed object systems, message passing, and web services. The Singleton and Visitor patterns will never truly go away, any more than batch programming will disappear.

Third, we must continue to look at the relationships between different parts of our nascent pattern language. Just as individual objects aren't very interesting, isolated patterns are less interesting than the ways they can interact with each other.

I believe that the true language of software has as much to do with programming languages as the language of music has to do with notes. So, instead of missed opportunity, let us say instead that we are just beginning to discover our true language.

1. Professor Greenberg is a delightful traveling companion. He's witty, knowledgeable and has a way of teaching complex subjects without ever being condescending. He also sounds remarkably like Penn Jillette.

2. The main reason is that I would surely get it wrong in some details and risk losing the main point of my post here.

3. And here we see yet another of the complexities of language. The word "sonata" refers, at different times, to a three movement concert work, a single movement in a characteristic structure, a four movement concert work, and in Beethoven's case, to a couple of great fantasias that he declares to be sonatas simply because he says so.

4. For examples ad nauseum, see Richard Wagner and the "abortive gesture".

(Human | Pattern) Languages

Michael Nygard — Mon, 08 Dec 2008 00:19:00 CST

We missed the point when we adopted "patterns" in the software world. Instead of an organic whole, we got a bag of tricks.

The commonly accepted definition of a pattern is "a solution to a problem in a context." This is true, but limiting. This definition loses an essential characteristic of patterns: Patterns relate to other patterns.

We talk about the context of a problem. "Context" is a mental shorthand. If we unpack the context it means many things: constraints, capabilities, style, requirements, and so on. We sometimes mislead ourselves by using the fairly fuzzy, abstract term "context" as a mental handle on a whole variety of very concrete issues. Context includes stated constraints like the functional requirements, along with unstated constraints like, "The computation should complete before the heat death of the universe." It includes other forces like, "This program is written in C#, so the solution to this problem should be in the same language or a closely related one." It should not require a supercooled quantum computer, for example.

Where does the context for a small-scale pattern originate?1 Context does not arise ex nihilio. No, the context for a small-scale pattern is created by larger patterns. Large grained patterns create the fabric of forces that we call the context for smaller patterns. In turn, smaller patterns fit into this fabric and, by their existence, they change it. Thus, the small scale patterns create feedback that can either resolve or exacerbate tensions inherent in the larger patterns.

Solutions that respect their context fit better with the rest of the organic whole. It would be strange to be reading some Java code, built into layered architecture with a relational database for storage, then suddenly find one component that has its own LISP interpreter and some functional code. With all respect to "polyglot programming", there'd better be a strong motivation for such an odd inclusion. It would be a discontinuity... in other words, it doesn't fit the context I described. That context---the layered architecture, the OO language, relational database---was created by other parts of the system.

If, on the other hand, the system was built as a blackboard architecture, using LISP as glue code over intelligent agents acting asynchronously, then it wouldn't be at all odd to find some recursive lambda expressions. In that context, they fit naturally and the Java code would be an oddity.

This interrelation across scale knits patterns together into a pattern language. By and large, what we have today is a growing group of proper nouns. Please don't get me wrong, the nouns themselves have use. It's very helpful to say "you want a Null Object there," and be understood. That vocabulary and the compression it provides is really important.

But we shouldn't mistake a group of nouns for a real pattern language. A language is more than just its nouns. A language also implies ways of connecting statements sensibly. It has idioms and semantics and semiotics.2 In a language, you can have dialog and argumentation. Imagine a dialog in patterns as they exist today:

"Pipes and filters."

"Observer?"

"Chain of Responsibility!"

You might be able to make a comedy sketch out of that, but not much more. We cannot construct meaningful dialogs about patterns at all scales.

What we have are fragments of what might become a pattern language. GoF, the PLoPD books, the PoSA books... these are like a few charted territories on an unmapped continent. We don't yet have the language that would even let us relate these works together, let alone relating them to everything else.

Everything else? Well, yes. By and large, patterns today are an outgrowth of the object-oriented programming community. I contend, however, that "object-oriented" is a pattern! It's a large-scale pattern that creates really significant context for all the other patterns that can work within it. Solutions that work within the "object-oriented" context make no sense in an actor-oriented context, or a functional context, or a procedural context, and so on. Each of these other large-scale patterns admit different solutions to similar problems: persistence, user interaction, and system integration, to name a few. I can imagine a pattern called "Event Driven" that would work very well with "Object oriented", "Functional", and "Actor Oriented", but somewhat less well with "Procedural programming", and contradict utterly with "Batch Processing". (Though there might be a link between them called "Buffer file" or something like that.)

That's the piece that we missed. We don't have a pattern language yet. We're not even close.

1. By "large" and "small", I don't mean to imply that patterns simply nest hierarchically. It's more complex and subtle than that. When we do have a real pattern language, we'll find that there are medium-grained patterns that work together with several, but not all, of the large ones. Likewise, we'll find small-scale patterns that make medium sized ones more or less practical. It's not a decision tree or a heuristic.

2. That's what keeps, "Fill the idea with blue" from being a meaningful sentence. All the words work, and they're even the right part of speech, yet the sentence as a whole doesn't fit together.

MSI Wind: A Tiny Laptop

Jared Richardson — Sun, 07 Dec 2008 18:00:00 CST
I just bought an MSI Wind laptop/netbook and so far I love it. It's tiny, weighing in 2.2 pounds. This includes the bigger, 6 cell battery that provides 6 hours of use. I haven't had a chance to push that envelope yet, but it's on my list of things to do. :)
Here's a picture of it sitting on my 15" MacBook Pro (link). It literally makes the sleek MBP look clunky. It feels that way too. 2.2 versus 5.5 pounds.
The most surprising thing about the Wind is that it's got a hyperthreaded CPU. (Traditionally ultra small notebooks had a single CPU and were slow). It's got the Intel Atom CPU, but with hyperthreading, so it's amazingly responsive. My model came with 1 gig of memory (I've already upgraded it to 2) and a 160 gig hard drive. The external monitor drives my 19" widescreen nicely. So far I can't tell that it's any slower than my MacBook Pro for almost everything.
The keyboard's alphanumberics are fine to use, but the "edge keys", like CTRL and ? are odd

Jon Stewart and the Automaker Bailout

Johanna Rothman — Sun, 07 Dec 2008 15:58:00 CST

Orac’s post, Jon Stewart on the Detroit bailout, points to Stewart’s perspective on the bailout. (Watch the video; it’s hilarious.) Some paraphrases and quotes from Stewart:

‘Congress… doesn’t know what the financial industry does and doesn’t want to look stupid.’ (paraphrase of Stewart)

“The auto industry has a product that’s tangible and easy to complain about. … Even the crappy ones [cars] are useful.” (quote)

‘The people you bailed out make derivative paper transfers of derivative groupings of said loans to China.’ (paraphrase, because I’m not sure I wrote it down properly)

“Wall Street lost all the money without making anything” (quote)

Who else makes an ephemeral product? Software-only producers, that’s who. Especially software as a service. Especially if they don’t release and get feedback frequently.

More food for thought when you start thinking about your strategy and your ability to execute.

easyb does it at CodeMash 2009

Andrew Glover — Sun, 07 Dec 2008 13:23:00 CST

I had such a hip time at last year’s CodeMash that I can’t wait to attend this year’s bash; what’s more, I’ll be presenting a talk entitled “Executable documentation with easyb” (hopefully with my good friend Rod Coffin), which is going to explore how easyb enables teams to develop stories in a specific format (i.e. a DSL, baby) which are then implemented as verification assets which marries the underlying application.

In this talk, those who attend will learn how to embrace collaboration and change rapidly by defining easyb stories that exercise a Java application end to end. Attendees will learn how to define specific easyb structures, how to plug them into real code, and how to run them in an automated fashion– people will see first hand how non-coders can define tests easily and how the collaboration this brings yields working software faster.

CodeMash is a unique event full of a lot of energy and myriad interesting disco dancers — plus, Cleveland is a wonderful place to visit in January. That is, if you plan on spending your visit in an indoor water park, man.

You can follow thediscoblog on Twitter now!

JavaFX released. Finally.

Andrew Glover — Sat, 06 Dec 2008 14:43:00 CST

JavaFX 1.0 made its debut a few days back amid high hopes and a sea of doubt — some in the Java community believe JavaFX could become “the application environment for the Java platform,” while others say Sun has made nothing but mistakes on the client side, and JavaFX is too little, too late.

I had the pleasure of chatting with Param Singh and John Burkey, both of Sun — in our conversation, we chat about both the concerns associated with JavaFX 1.0 and its future potential on the desktop, web, and even mobile. What’s more, we also chatted about what does JavaFX 1.0 mean for Swing and can JavaFX compete with Flex or Silverlight? Have a listen and find out, man!

You can follow thediscoblog on Twitter now!