I have enjoyed building a few AJAX prototypes using GWT and now I am just now starting to look at Google's Android SDK - also built on Java technology. I have done a couple of consulting jobs using the Java ME platform, and I would guess that eventually I will do something (professionally) with Android - what is not to like about an open cellphone platform built on Linux and programmable with Java :-)

I don't use Smalltalk professionally but I wanted to try the new Seaside 2.8 release. I did a fresh Squeak 3.9 final installation on my MacBook running Leopard. Installing Seaside was as simple as starting the SqueakMap package loader, doing an upgrade to all installed packages, then do a Seaside install answering yes to all optional package offerings. Everything 'just works' and has a very polished feel to it - important when I am giving up an evening or two to play with something very cool. One very important aspect of this "feeling of quality" is an active community that maintains a central package web site - good examples are SqueakMap (Squeak), Gems (Ruby), and CPAN (yuck, Perl :-) Having a central package repository is more than just a time saver: time spent dealing with too many installation and configuration options disrupts what I would call problem solving mode or thinking. I used to take great pleasure in staying on top of most J2EE technologies, but ...

Small is better at all levels of software development: Small projects have lower failure rates than larger projects . Smaller classes are easier to understand and use. Small functions and methods are easier to write, understand, test, and reuse. I think that the first point is the most interesting. It is difficult to get requirements right and reducing the size of projects by breaking them up reduces risks involved with poor understanding of requirements. To use web applications as an example, by implementing a minimal system that still provides useful functionality, we learn early on what are the most important requirements. We also keep team size small - more efficiency and less risk. We also get something useful to users developed faster. I think that ego is the negative force that fights against the goodness of small and focused projects. At the customer level, they often want all of their ideas implemented sooner rather than later instead of setting priorities. At the developer l...