John Reynolds's Blog

April 2006 Archives

The World (of IT) Heads To Austin

The World Conference on Information Technology (WCIT) is coming to Austin this year... and it should be a lot of fun. This event is held every other year in a different locale (this is the 15th edition). The last conference was held in Greece and the next (2008) will be held in Malaysia.

I've been volunteering for the event over the past week or so (doing some mundane tasks that just have to get done) and I will be helping out during the event itself. There is a tremendous amount of work that goes on behind the scenes... WCIT2006 professional staffers have been working on this event for two years and there are still a million little loose ends to tie up.

The logistics for WCIT2006 are being spear-headed by the brother and sister team of Lucas and Courtenay Daniels... they've got a handful of full-time staff to help them, and they've got an unruly band of volunteers like me to contend with (the phrase "herding cats" comes to mind).

Lucas and Courtenay have been in the convention business for many years, but Lucas confided in me that this event is in a league of its own... over 2,000 delegates are coming from over 80 countries.

The WCIT 2006 speaker roster includes the following:

• Steve Ballmer, CEO, Microsoft
• John S. Chen, Chairman, CEO and president of Sybase, Inc.
• Dato’ Seri Abdullah Ahmad Badawi, Prime Minister of Malaysia
• Michael Dell, Chairman of the Board of Directors of Dell Inc.
• Anne M. Mulcahy, Chairman and CEO, Xerox Corporation
• Professor Nicholas Negroponte, co-founder and chairman Emeritus, MIT Media Laboratory and Chairman, One Laptop per Child
• Paul Otellini, CEO of Intel
• Gen. Colin Powell (ret.), former United States Secretary of State
• Hector Ruiz, Chairman of the Board, President and CEO of AMD
• John W. Thompson, chairman of the board of directors and chief executive officer of Symantec Corporation

1. Privacy and security in an increasingly un-private world
   
2. Digital access for everyone
   
3. Improved heathcare through IT

(I'm hoping that volunteers get one too)

Continue Reading...

Teaching Kids to be Thoughtful Programmers

(Cross-posted at The Thoughtful Programmer)

Today's kids are amazingly creative technophiles... If you have any doubts about that, just check out some of the videos posted at sites like YouTube.

My personal YouTube favorites are Chips (by Brookers) and Hey (by Tasha)... Both of these videos demonstrate a significant grasp of the art and technology of film-making.

Given that these young people grew up with MTV and a wealth of cable channels, it is not completely surprising that they've mastered the basics of film-making so well... Learning by example (especially when there are so many good examples to choose from) is a time-proven method for mastering a skill.

With access to low-cost (and fun) film-making tools like Apple's iMovie, kids can now easily emulate the movies and music videos that surround them. Raw talent is quickly refined by contrasting their own work with the pervasive examples of "Good Film-Making" that they see every day.

We've got a seemingly endless supply of great want-to-be-Spielbergs on tap... which is really fun... but sadly we don't seem to have a supply of great want-to-be-Programmers (let's face it, film-making is sexier).

Given the relatively small number of want-to-be-Programmers, it is increasingly important that those who do accept the challenge learn their craft exceedingly well... Quality is going to have to make up for a lack of Quantity.

To teach these new programmers, we have to take our cue from the film-makers. Today's new film-makers are successful because they have access to great (and inexpensive) tools, and they have access to great examples to learn from.

Today's want-to-be-Programmers do have a wealth of great tools at their disposal, many of which are free. What they lack are pervasive examples of "Good Programming" to learn from. We are surrounded by some really great programs, but they are almost invisible... even when we are aware of them, it's hard to "see" how they work.

Do you have any idea at all how Google finds answers for you?

I think that our task (those of us who would educate these new programmers) is to seek out "Good Programs", and to discuss them and analyze them in the same way that film critics discuss and dissect movies. This has very little to do with specific computer languages or specific technologies... it has more to do with craft, style, and techniques.

There is science to programming, but there is also art... and the combination of the two is what really leads to Thoughtful Programmers.

"Programmer to the Stars" Bruce Tate spotted at swanky North Austin establishment

"What? No Elephant on the menu!?!"

Of course I am just kidding. I asked Bruce to pose for the picture (and supplied the sun glasses)... but there has been a bit of a nasty furor over Bruce's latest book: Beyond Java, and I wanted to poke a little fun at his critics.

Kudos to Bruce for stirring the pot, for as William Hazlitt (English essayist (1778 - 1830)) noted:

"When a thing ceases to be a subject of controversy, it ceases to be a subject of interest."

In this case, the controversy is Java versus Ruby On Rails: Is Java a great tool for creating web-based CRUD applications or does Ruby leave Java in the dust?

Bruce is still pretty sold on Ruby for this problem space, and his enthusiasm is hard to resist... I feel very tempted to try ROR, but in honesty I am rooting for Rick Hightower's JSF/Rife integration efforts.

Ruby aside, I am in total agreement with Bruce that many of Java's abstractions obscure the relationship between our customers' requirements and the code that implements the functionality.

Bruce and I talked of many things over lunch, but we kept coming back to questions regarding learning how to program: My starting point is to start teaching programming concepts (programming literacy, not computer literacy) in our middle schools... Bruce's approach is to eradicate distractions through the use of Domain Specific Languages.

One "sort of quote" from Bruce stuck in my mind. Bruce never thought of himself as a high-level programmer, but he finds himself spinning out DSLs on every Ruby project he tackles. This reminds me very much of my own experiences with FORTH. The basic tenet of FORTH was the creation of a vocabulary for the job at hand, and composition of the application from that new vocabulary (Maybe I need to dig out my old copy of Leo Brodie's Thinking in FORTH to refresh my "little gray cells").

Controversies aside... I really enjoyed my lunch with Bruce, as I really enjoy interacting with other programmers through my blog. What's really great about Java is the community spirit... the ability to interact with a diverse group of talented people who are truly passionate about what they do (sometimes a bit too passionate, but that sure beats apathy).

One thing is crystal clear... If we don't continue to question and rethink our basic approaches to Programming (and how Programming is taught) we really are going to have a Software Crisis on our hands.

As for Bruce: Hopefully the Javatollahs will rescind their fatwa and he can ditch the sun glasses ;-)

Product Architecture from a software perspective

When we began the effort, we quite frankly were not sure what "product architecture" meant, so with the help of Google I did some research and found the following:

An architecture has a two-part definition:

• The first part of an architecture is a decomposition of the overall functionality of a product into a set of defined functions and the component parts of the product that are going to provide those functions.

• The second part of the definition is the specification of the interface between the components, in other words, how components are going to interact together in the product as a system.

The specification of the interface is critical to the design of flexible architectures that allow you to substitute component variations within a product without having to make adjustments in other components."

- Ron Sanchez : Professor of Strategy and Technology Management at IMD

I like this definition for product architecture, but we need to clarify what we mean by "decomposition of the overall functionality".

A product's architecture straddles the boundaries between business and technical concerns, but it belongs to the business owner (typically a Product Manager). The functional components that the business is concerned with are components that can be assembled to provide new business functionality (new products).

With this business focus in mind, consider the popular Model-View-Controller (MVC) software architecture: Is MVC the basis for a product architecture?

MVC is a modular architecture that separates an application's data model, user interface, and control logic into distinct components so that modifications to one component will have minimal impact on the others. MVC is a very successful architecture, and one which every software architect should master... but it is not a meaningful basis for a product architecture for one simple reason: The component breakdown in MVC is not focused on business functionality.

In contrast to MVC; the component breakdown in Service Oriented Architecture (SOA) is focused on business functionality. SOA is a modular architecture in which applications are composed from distinct business-relevant services (hence the term composite application).

Let me hasten to explain myself... SOA is not by itself a product architecture any more than MVC is, but SOA is a useful tool for considering how an architectural model for a product family should be described.

Most software products automate business processes. The architecture of the product provides the framework for implementing the business processes. If the mapping from the process steps to the architectural components that implement those steps is clean, then the business owners will probably understand (and appreciate) the architecture.

So back to the phrase: "decomposition of the overall functionality"... We can expand this to: decomposition of the overall functionality into distinct, business-relevant functions...

If you start with the right set of business-relevant functions, the resultant products will likely be easier to maintain and to adapt in the future.

I know, business-relevant is not exactly a precise term either... but the only way to pin that one down is for you to talk with your business owner. Start talking ;-)

This work is licensed under a Creative Commons License.