photo credit: °Florian

Yes, Cloud Foundry has been acquired by Spring Source and seems to be morphing into a for-pay service, and there hasn't been a new build packaged on the Cloud Tools project page since January of 2009, but if you dig in the SVN repo, you see there's a bit of activity. Before I try building from source, I wanted to see how hard it would be to get 0.6 Grails plugin working with a Grails 1.1.1 app.

Well, harder than I thought. There's a real lack of documentation around cloudtools for one, and the radio silence on the project page over the last few months hasn't helped. Fortunately, Don over at AlterThought has put together a nice post that covers most of the pitfalls and problems with the CloudTools Grails Plugin. A few things they don't address and I thought I'd throw in here:

1. The CloudTools scripts expect the plugin to be located in the Grails project directory.

That isn't the case anymore. The plugins have moved to ~/.grails/1.1.1/projects/<your-project-name>/plugins/. The one script that barfs on this is ~/.grails/1.1.1/projects/<your-project-name>/plugins/cloud-tools-0.6/scripts/CloudToolsDeploy.groovy which tries to determine the plugin dir through a process that just won't work anymore. Edit the file and replace all the pluginHome cruft with a single line:

pluginHome = "${cloudToolsPluginDir}"
 

That's it.

2. The CloudTools deployment ignores your production configuration and just deploys development.

If your development data source is configured to create-drop, you'll be very disappointed that your database is constantly getting nuked. So, ignore the production environment and just use development! (This will need to be fixed, of course.)

3. When deploying, you need to have a local db running with the same login info/credentials as your production.

What a huge pain. I only discovered this after shutting down my local development mysql instance. Not so good for automated build and deploy. Again, needs to be fixed.

4. Using EBS is pretty dead simple.

Using EBS to persist mysql tables is rather trivial. Just tack on a withNewEbsVolume method call the first time through, then a withExistingEbsVolume, some the first time:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withNewEbsVolume(20, "/dev/sdq")
 

CloudTools will create a volume, format it and mount it, populate the db tables to it. Next you find the volume id with something like ElasticFox and edit your config file to look like this:

clusterSpec = new ClusterSpec()
                .tomcats(1)
                .topology("SingleInstanceTopology")
                .instanceType(EC2InstanceType.SMALL)
                .slaves(0)
                .withExistingEbsVolume("vol-1234", "/dev/sdq")
 

Obviously replace vol-1234 with your actual volume id.

OK, that's it. With this configuration, I'm able to get a Grails app up in a matter of minutes with a persistent mysql db.

Next time: building from source.

Related posts:

1. Making Vaadin, PureMVC and Grails Work Together
2. Grails and Google App Engine: Birthing Pains
3. Grails and JSONP: How Easy is That?

I'm especially eager to use UiBinder to do declarative UI creation. Just specify how your interface should look in XML:

<!-- UserDashboard.ui.xml -->
<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:my='urn:import:com.my.app.widgets' >
 
  <g:HTMLPanel>
    <my:WeatherReport ui:field='weather'/>
    <my:Stocks ui:field='stocks'/>
    <my:CricketScores ui:field='scores' />
  </g:HTMLPanel>
</ui:UiBinder>
 

and write some Java to instantiate it:

public class UserDashboard extends Composite {
  interface MyUiBinder extends UiBinder<Widget, UserDashboard>;
  private static final MyUiBinder uiBinder = GWT.create(MyUiBinder.class);
 
  private final String[] teamNames;
 
  public UserDashboard(String... teamNames) {
    this.teamNames = teamNames;
    initWidget(uiBinder.createAndBindUi(this));
  }
 
  /** Used by MyUiBinder to instantiate CricketScores */
  @UiFactory CricketScores makeCricketScores() { // method name is insignificant
    return new CricketScores(teamNames);
  }
}
 

Obviously there's a little more to it than this. I'll try to post a little howto over the weekend. There's already a few examples out there, but when it comes to a new feature like this, the more explanations, the better.

Related posts:

1. GWT, Gadgets and OpenSocial
2. Released: QxWT-0.8.2-RC1 – GWT Wrapper for qooxdoo
3. GWT and XUL

I've been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some  of the usual grails GORM goodness, you can write some reasonably interesting grails apps.

There are still a few flies in the ointment. Some of them are grails issues, and are due to the immature state of the plugins. Those are forgivable and will clearly be addressed given time. Some of them, however, are App Engine Java SDK issues. Those are really more problematic given the 1.2.6 version number on the SDK. f I had to boil it down to it's essentials, then I would say that the SDK doesn't barf in consistent ways. Up until 1.2.5, the SDK in development mode wouldn't even complain if you were doing privileged operations. With 1.2.6 you at least got some complaints. For example, with 1.2.6 you now see the following exception on grails startup:

[java] Unable to use direct char[] access of java.lang.String. Disabling this method.
[java] java.lang.IllegalAccessException: Private fields can not be set on JRE classes.

That's because Groovy is trying to modify the String class. But still, there are any number of things that behave differently in the actual App Engine container than the local environment. One solution is to frequently deploy the app the the App Engine container. That's a pretty expensive step, however, and can't be a part of your development and test cycle. Also, even if something does blow up in the App Engine environment, you don't always get a log message. I've been trying to track down a "404 NOT FOUND" problem for a couple of weeks now that doesn't happen at all in the local SDK environment and leaves no log file traces in the App Engine environment.

I have my fingers crossed that version 1.2.7 of the SDK will solve all of those problems.

Related posts:

1. Grails: Delegating to GORM Persistence in Java
2. Grails and JSONP: How Easy is That?
3. Making Vaadin, PureMVC and Grails Work Together

I should have a full review of it up in a week or two.

Related posts:

1. From the Grassy Knoll: Google Android Undermining Java ME
2. ZK on Android
3. Book Review: Core Animation for Mac OS X and the iPhone

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?

Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.

I'll make some more posts here as my thinking and experimenting evolves.

Related posts:

1. Griffon Plugin Development: Some Nitty Gritty
2. Griffon: Convention over Configuration for the Desktop
3. Questions About Griffon

I have a short list of things that I don't like about GWT. They are:

1. You have to use a special browser to debug in Java. That browser doesn't always behave the way IE or Firefox or Safari does. And you need OS specific distributions which can make it a little tricky to share a project between developers with different OS platforms.
2. GWT apps download as a massive hunk of code. There's no way to dynamically load code as you need it.
3. Building UI's dynamically, through a sort of XUL mechanism is a pain in the ass for non-standard components. Just talk to the Vaadin folks about the hoops they had to jump through.
4. The annoying dependency on SWT for tests.

So, what does 2.0 promise? To resolve these four things, and a few more. Check out the GWT 2.0 Milestone 1 release announcement:

In-Browser Development Mode: Prior to 2.0, GWT hosted mode provided a special-purpose "hosted browser" to debug your GWT code. In 2.0, the web page being debugged is viewed within a regular-old browser. Development mode is supported through the use of a native-code plugin for each browser. In other words, you can use development mode directly from Safari, Firefox, IE, and Chrome.

Code Splitting: Developer-guided code splitting allows you to chunk your GWT code into multiple fragments for faster startup. Imagine having to download a whole movie before being able to watch it. Well, that's what you have to do with most Ajax apps these days -- download the whole thing before using it. With code splitting, you can arrange
to load just the minimum script needed to get the application running and the user interacting, while the rest of the app is downloaded as needed.

Declarative User Interface: GWT's UiBinder now allows you to create user interfaces mostly declaratively. Previously, widgets had to be created and assembled programmatically, requiring lots of code. Now, you can use XML to declare your UI, making the code more readable, easier to maintain, and faster to develop. The Mail sample has been updated to use the new declarative UI.

Bundling of resources (ClientBundle): GWT has shipped with ImageBundles since GWT v1.4, giving developers automatic spriting of images. ClientBundle generalizes this technique, bringing the power of combining and optimizing resources into one download to things like text files, CSS, and XML. This means fewer network round trips, which in turn can decrease application latency -- especially on mobile applications.

Using HtmlUnit for running GWT tests: GWT 2.0 no longer uses SWT or the old mozilla code (on linux) to run GWT tests. Instead, it uses HtmlUnit as the built-in browser. HtmlUnit is 100% Java. This means there is a single GWT distribution for linux, mac, and windows, and debugging GWT Tests in development mode can be done entirely in a Java debugger.

Looks like Xmas has come early. I've been working with the browser plugin for a little bit and it is just a joy to use. One down side, of course, is that Intellij 9.0 will be out of date re: GWT the day it is released.

Related posts:

1. Plugging Some Cool Tools
2. Grails and Google App Engine: Birthing Pains
3. Don’t be lazy, download a good browser

Time to answer some questions about Griffon:

1. What is the size of the jar that gets generated for a Griffon jar?
   If you package it all up ('griffon package'), then a vanilla Griffon jar weighs in at 4.7M. That's mostly the Groovy runtime (4.4M) and the Griffon runtime (204k). If you're concerned about download size for Java Web Start, then you won't want to bundle it as a single jar, but rather let your users download the Groovy and Griffon runtimes once, then your app specific jar as it is updated.
2. Can Griffon apps be distributed via Java Web Start?
   Yes. When you run 'griffon package', you get an executable jar, an applet, a JWS app and a 'zip' that is structured as a directory with bin and lib subdirs and batch and shell files to run the application. In short, most ways that you may want to deploy the application.

There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

Related posts:

1. Griffon Tutorials: Adding Useful Logging
2. Griffon Plugin Development: Some Nitty Gritty
3. Griffon and a PureMVC Plugin: Some Initial Thoughts

So, the question is: How to determine if your project/organization has that collective code ownership culture. And what team members (including managers ) can do to create/encourage it.

Does your project have collective code ownership?
Here are few things you may want to ask yourself to determine if your organization/project has collective ownership culture.

• Are tools like continuous integration and testing, code coverage and code metrics considered nice to have but not necessary?
• Is the project release schedule determined and then enforced with little or no involvement from developers?
• Is failure to slip on iteration stories viewed as failure on developer's part?
• Does your velocity seem to decrease with time?
• Do developers talk about my module, your module instead of our module?
• Do members aspire to leave your project and join other project?

If answers to these questions are mostly in the "yes" range, you may have a code ownership problem.

What's a developer to do?
Be a good citizen, strive to write good code. Leave any codebase cleaner than how you found it. Developer need to tame their tendency to guard their masterpiece code from other people's changes, infact welcome those. If you really really hate some design, try to pair with the person who concieved it and influence his thought process. This might be slow and furstrating but it will be better in the long term. If you rip out everything you don't like, you will end up owning everything. Remembership, it is a collective ownership. Code is very fluid, which means when coding, you can always take short-cuts to get stuff you are responsible for, done. Or you can take ownership and fix the general code quality (even if it take a little longer). These are all things that a developer is in control.

However, there are stuff that are beyond developer's control. It is hard to continue to be a good citzen when other members don't feel the same way and when your boss is holding your neck against a timeline. This is where managers can play a role.

Why do manager care about code ownership?
A manager cares about the quality of deliverable, team morale, attrition and deadline. An agile project manager can remote obstacles that prevent such culture from growing. Managers need to cultivate a culture where developers are not hard pressed to deliver on timeline at the cost of quality, atleast not often. Managers need to develop a culture of trust where developers are free to over-estimate stuff (atleast from their point of view). Hire team players overs smart but solo players.

What's a Architect to do?
Managers can't judge the quality of code and hence success of code ownership culture. Yes, there are code metrics like code coverage that attempt to quantify the code quality but those are not precise measures. Here is where architects can make a different. By architect, I mean anybody how has the direct or indirect authority to influence other developers and modify their behavior. Install tools like continuous integration, testing, code coverage and various other metrics. Encourage pair programming to reduce bus number and prevent knowledge silos (the bad side of code-ownership).

In summary, it could be a good thing when a team feels responsible when the project when in it and proud that they were part of a project that completed successfully. They owned the outcome of it, good or bad.

Related Services: Agile Development, Custom Software Development

Related posts:

1. What makes a good requirement document for an agile project
2. Data Driven Design and the Culture at Google
3. Code Coverage – Why?

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy-- specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes...

 
import org.gmock.GMockTestCase
import org.asteriskjava.manager.event.JoinEvent
import org.asteriskjava.manager.event.LeaveEvent
 
def queueObject = // .... some object representing an internal queue
 
/*
 * Verifies caller entering a call queue will trigger behavior
 */
void testCallIAddedToQueue() {
  mock(queueObject).add('SIP/123', '3125551234').once()
  dispatchJoinEvent([channel: "SIP/123", callerId: "3125551234"])
}
 
/*
 * Verifies caller leaving call queue will trigger behavior
 */
void testCallRemovedFromQueue() {
    mock(queueObject).remove("SIP/123").once()
    dispatchLeaveEvent([channel: "SIP/123", dateReceived: new Date()])
}
// ...
 

The testcases above are fairly straightforward, hiding much of the details involved when working with Asterisk-Java. The 'queueObject' can be anything, really, as long as it contains behavior which we wired into the event-handling system Asterisk-Java provides. The important part here is how we can easily bind properties to the underlying Event types, and dispatch them so that our behavior is invoked.

 
private def dispatchJoinEvent(properties) {
  dispatchEvent(JoinEvent, properties)
}
 
private def dispatchLeaveEvent(properties) {
  dispatchEvent(LeaveEvent, properties)
}
 
private def dispatchEvent(eventType, eventProperties) {
  def event = eventType.newInstance([:])
  eventProperties.each { name, value -> event."${name}" = value }
  play {
    asteriskService.connection.dispatchEvent(event)
  }
}
 

Here I have a 'service' class defined in Grails which I call 'asteriskService'. It encapsulates access to the Asterisk-Java ManagerConnection instance, which in turn can dispatch specific events.

Of interest to those new with Groovy is the binding of properties within 'dispatchEvent()'. It looks perhaps a bit more complex than one would hope, but unfortunately JoinEvent and LeaveEvent do not have default constructors, requiring the code to 'new' them up with a placeholder argument, and then set any properties on the fly.

Asterisk-Java is worth checking out, but particularly nice is using a bit of Groovy to tie it in nicely. While this can benefit the application, you can see how it helps ease testing-- particularly as you start using more and more of what the library offers.

Related posts:

1. GWT Testing With Groovy? (Heck yeah!)
2. Grails: Delegating to GORM Persistence in Java
3. Groovy 1.6 and Per-Instance Metaclass

Start with Basics: Books, Tutorials etc.

Yes, getting hands dirty is the first thing. If you are "programmers don't read manuals" type and/or you know enough about the new language, just download and give it a ride. Or you can pick a book or two, read getting started tutorials and then give it a try. The gist is start relating what we learn to what we already know and ask questions. How can I upload file in the new framework, how do I do testing, how can I write library/reusable-code etc.

All major language framework now-a-days have atleast 2 types of mailing lists: user and developer. It's a good idea to subscribe to user mailing list and start reading it from a few weeks or months ago depending on how fast the language is changing and how relevent the posts are to current version.

All this may get you coding and get by for the day but you haven't really understood the framework. Fear not, here are a couple of things you can do.

Download and Peruse Example Apps

Most frameworks come with an example application where it is being used to exhibit its strengths. If not, it shouldn't be difficult a reputed open-source project even if the framework itself is proprietary. This is a good place to learn best practicies and design patterns as it applies to that framework.

Subscribe to Bug Tracker

Bugs and new feature requests are a great way to learn about the the "other" side of a cool framework, the deficiencies that is. No quick tutorials focus on the internal nitty-gritty that we run into as soon as you start on a non-trivial project. The discussions that happen on whether something is a bug or a design choice becomes clear from this place. Again, not a bad idea to go a little back in timeline to read fixed bugs, and finished features.

Subscribe to Core mailing-list

Peek into the future that is. Here is where the core maintainers discuss what is the next high priority items are and how to implement them. While it may be too early to contribute here, it is a place to learn some advanced stuff.

Download and Peruse Source Code & Tests

This takes time but it has tremendous advantages. The code is the full truth. Besides good coding practices, it also helps us understand the undocumented features of a framework. And, if code is the full truch, tests are the key to that truth. Tests help us understand what was being achieved in a piece of code.

Pair and Ask Questions

Pair with somebody who has had a head start with the new language. This can quickly give us the soft side tools: the efficiencies your pair spent time building and websites, blogs they use.

blogs/wiki/screencasts

Tutorials, API documentations, technical articles has always been there and are important. Blogs and Screencasts are even better since they are the most current and most applicable to current state of affairs with the language or framework.

Blog your experience

Yes, blogging about your experience will help you learn a new framework. Others who read your blog will point out what you have missed and point you in the right direction. It is also a place where you have documented your journey to refer back to.

Work for Consulting Company

No, this is not entirely madeup Keeping up with latest technologies is a survival trait for any consulting company and its employees. This is where we can meet other motivated folks with different interests and keep up with what is new out there. With plethora of new languages and frameworks coming and going each day, you have to be able to pick winners to add to your tool box. Blogs, RSS feeds help but a lunch time remarks from experienced gurus can go a lot further.

Photo Credit: Daniel Voyager

Related posts:

1. When is an Ajax Framework Worth Mentioning
2. Are You Building an Application or an Antique Web Framework?
3. Programming Books, Mostly Not By Me

Recently, I needed to create a special tag in Grails which would render specific children in a way that is aware of their order. I wanted to stick entirely with markup (not passing an array to a tag), and also wanted to avoid putting lots of logic inside a .tag file. While it was possible to write a tag lib which first parsed the children in a "non-render" mode, I preferred a solution which did not require doing my own parsing before render. The solution I came up with isn't the most flexible, but it got the job done in a relatively clean way with minimal custom code.

The following is an example solution with the associated code and tests.

The problem is this: I want a parent tag which will add different class names to the children depending on their order. For this example, we will be adding even/odd and a first/last class to the appropriate children. For the purposes of this example, we will ignore CSS 3.0 Selectors, which could do this entirely in the stylesheet.

First, let's generate our tag lib through grails.

grails create-tag-lib ParentChild

Now that we have our empty files, we can write a test to define the expected behavior in the generated test file. Make sure that you are extending grails.test.GroovyPagesTestCase.

 
class ParentChildTagLibTests extends grails.test.GroovyPagesTestCase {
 
    void testParentContainerShouldRenderChildren() {
        def writer = new StringWriter()
        def markup = new groovy.xml.MarkupBuilder(writer)
        markup {
            ul('class':'myParent') {
                li('class':'myChild even first') {
                    a(href:'/first', 'one')
                }
                li('class':'myChild odd') {
                    a(href:'/second', 'two')
                }
                li('class':'myChild even last') {
                    a(href:'/third', 'three')
                }
            }
        }
 
        assertOutputEquals(
            writer.toString(),
            '<example:parentContainer><example:child label="one" url="[controller: \'first\']"/><example:child label="two" url="[controller: \'second\']"/><example:child label="three" url="[controller: \'third\']"/></example:parentContainer>'
        )
    }
}
 

Now that we have a failing test, we can write the actual code. Notice that I used a custom namespace here (just for the sake of example).

 
class ParentChildTagLib {
 
    static namespace = 'example'
 
    def parentContainer = {attrs, body ->
          // we'll be using this to keep track of our children
          def children = []
          this.pageScope.parentContainerChildren = children
          // this will execute the body, so that the children are
          // appended.  obviously, anything other than child
          // tags will not render correctly.
          body()
 
          def mkp = new groovy.xml.MarkupBuilder(out)
          mkp {
              ul('class': 'myParent') {
                  // iterate over all the children, and
                  // render them here
                  children.eachWithIndex {child, index ->
                      li('class': determineClassNames(child, children, index)) {
                          a(href: g.createLink(child.url), child.label)
                      }
                  }
              }
          }
      }
 
      private def determineClassNames(child, children, index) {
          def classNames = 'myChild'
 
          if (index % 2 == 0) {
              classNames += ' even'
          } else {
              classNames += ' odd'
          }
 
          if (child == children.first()) {
              classNames += ' first'
          } else if (child == children.last()) {
              classNames += ' last'
          }
 
          return classNames
      }
 
      def child = {attrs, body ->
          // simply keep track of the tag attributes
          this.pageScope.parentContainerChildren << attrs
      }
}
 

Now, given the following GSP code:

 
<example:parentContainer>
    <example:child label="one" url="[controller: 'first']"/>
    <example:child label="two" url="[controller: 'second']"/>
    <example:child label="three" url="[controller: 'third']"/>
</example:parentContainer>
 

I get the following HTML generated:

 
<ul class='myParent'>
<li class='myChild even first'>
    <a href='/first'>one</a>
  </li>
<li class='myChild odd'>
    <a href='/second'>two</a>
  </li>
<li class='myChild even last'>
    <a href='/third'>three</a>
  </li>
</ul>
 

There are some limitations to this strategy. First, any other markup outside of the child tag inside the parent is not going to render how you'd expect. Also, nested parent tags aren't going to work for this implementation unless you make some changes. Finally, this implementation won't support body markup in the child tags; however, given a little tweaking it could be made to do that (I'll leave that as an exercise for the reader).

Despite these limitations, if you are looking to do something like breadcrumbs, tab navigation, or custom list rendering, then this may fit your needs.

Related posts:

1. Grails and JSONP: How Easy is That?
2. Grails and Google App Engine: Birthing Pains
3. Grails: Delegating to GORM Persistence in Java

Security is hard

Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.

Oh, and if the code base isn't sufficiently tested, you're in for a world of hurt.

If you are a developer that was just asked to 'do a quick security check and plug any holes', you are now in the difficult position of managing the expectation that a two-week security review means "we're covered". Be realistic about what you can accomplish, setting out some short-term and long-term goals.

Do More With Less. Start with a research 'Spike'

Instead of pushing for more time to be able to 'cover it all' (even though you have no idea what 'it all' is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I've found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.

Plan for success

With your analysis and recommendations in hand,
you'll be in a better place to give an estimate on what it will take to correct the problems, and any potential side-effects, (ie. "our legacy data partners might not be able to implement their side of this new security plan on time"). Plus, the team can decide which items are the highest priority, and more importantly, you'll have put some practices in place to prevent any new security issues from slipping in later.

Because we are never really 'finished' with security, now would be a good time to schedule the next security review, tapping another member of the team to head it up (with your guidance), so that everyone knows that security is something they should be thinking of. Instead of doing a single 'big-bang' security audit headed by one person under an unrealistic deadline, you'll rotate the responsibility through the entire team, taking smaller more managable bites, and educating everyone in the process.  Eventually your 'security-review' will be a natural part of the iteration and your everyday work.

(Tomorrow I'll post a quick checklist of general areas to look into for web application security.)

This same 'analyze, prioritize, estimate, rotate' technique could be applied to any 'big-bang' approach, such as:

• Performance tuning
• Adding unit tests to legacy code
• Refactoring
• Releasing to Production

Your team will get into a rhythm and become more efficient as the knowledge is evenly distributed. But more importantly your customers will appreciate the stability of having smaller but more frequent changes instead of massive buggy 'overhauls'. They'll see bugs getting fixed faster, and notice that little things that have bothered them for awhile are also getting fixed. Who knows, they might even give you the feedback that leads to your next million dollar idea!

Related posts:

1. Web app security checklist (Braindump)
2. App Security: Throw Out the Org Chart!
3. The Truth About Designing For Security

In an earlier post about the benefits of Agile and Scrum, I made a statement that bugs by their nature are not the same as normal features, and I wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a slightly different take on the subject.

My definition of a bug is: A feature that was specified, and you attempted to deliver, but is not working according to your intentions. (ie. "I thought it WAS saving to the database")

Not a bug: A feature or variation that you hadn't intended to create in the first place. ("Oh, I didn't know it was supposed to do that when you clicked the back button")

And with that understanding I say "Bugs can't be estimated"

The reason I make the distinction that way is because I think there are a lot of things that should be considered 'Missed Requirements' or 'New Requirements' that often get classified as bugs, when they are not. Both of those things should be as easy to estimate as any other feature work. I try to keep them separate from bugs because they are not bugs in software, but rather 'bugs' in communication. Perhaps the requirements criteria weren't clear, the acceptance test cases insufficient, or the developer just skimmed past a clearly defined and well-stated requirement. Either way, these things can be estimated, and should, and the estimates and actuals should be accounted for in your normal velocity calculation.

True bugs, however are things that aren't working the way you expected them to, and you aren't sure why, and you most likely aren't sure how long its going to take to fix it. When I've seen people give estimates for bug fixes in the past its either a complete guess that will be drastically over or under, or the more common is that they spend some untracked amount of time figuring out what the issue is, and then produce their 'estimate', but I contend that its the 'figuring out what the issue is' that needs to be tracked and accounted for, and is the un-estimatable component that can throw your iteration off.

I try to make this point in such black and white terms to defend against some common anit-patterns I see.

1. Missed requirements get called bugs, and the team doesn't measure the time it actually takes to resolve them, or adjust their velocity and relative point scale accordingly. (Imagine someone estimates it will take 2 days to complete feature X, and feature Y looks pretty similar, so they estimate 2 days for it as well. After 2 days feature X is 'done', but then there are several missed requirements and 'bugs' that take an additional 3 days to fix. Its critical to make sure that the estimate for feature Y is updated accordingly)

2. New Requirements get called bugs, which most of the time is just an honest misunderstanding, or it could be a more insidious attempt to cover up a communication problem, but when they are called bugs, they are often not treated in the same manner as other requirements (UI design, analysis, acceptance test definition, etc).

One my worst experiences with this was on a project where both the BA and QA resources had significant domain expertise, but disagreed on some implementation details. The QA person was unable to make their case during the requirements review, so they just waited until testing to say that there were several bugs, but in fact these bugs were variations on functionality that were not originally specified. On that project, only certain people could define and approve new functionality, but any bugs opened by the QA team were assumed to be top priority and didn't need to be reviewed or approved. (an extreme example I know, but it just points out the importance of making sure that you treat bugs as bugs, and requirements as requirements)

3. Planning to take care of 'all outstanding bugs' in the 'bug-fix iteration' as the final iteration at the end of the release. Here's where I'm really saying "you can't estimate bugs", and that it might be very dangerous to set the expectation that you can fix all of the issues in that iteration. What if it takes twice as long? What if fixing the bug causes more bugs?

You can't be so sure of these things, which is why I say you should plan for them differently.
1. Requirements disguised as bugs should be put in the backlog and prioritized and estimated as normal features (and figure out why they were missed)
2. Allocate a 'bucket' of time within each iteration to tackle bugs.
3. The stakeholders prioritize and define the expected behavior for bugs
4. The burndown chart for the bug fixing reflects the amount of time remaining in the bucket, and the amount of bugs left
5. When the time is all used up, the product owner has to make a decision for how best to utilize resources, either pull someone off of a feature to continue working on the bug, or hold off on the bug until the next iteration.

Now it might seem odd to stop working on a bug, but the reality is you have a fixed amount of time each iteration, and you have to leverage it as effectively as possible. The goal is to have fully testable and hopefully releaseable software at the end of the iteration so you can't leave a feature half-done. One way or the other you have to find a way to get it done. When you don't track the amount of time spent on bugs, you can end up short-changing your other features, which in turn can lead to more bugs.

Do you track time spent on bugs? (do you relate it back to the original estimate for that story?)
How do you estimate and plan for how long it will take to fix bugs?

(slightly unrelated) The recent client project I was on had 'Urgent' bugs that went back more than 90 days. Who is in charge of cleaning up bugs on your team? (are there any bugs more than 30 days old, and why?)

Bonus question: What would it take for your team to have a 'zero bug' policy? If at the end of every iteration there were no outstanding bugs?

Related posts:

1. Scrum defined in under 10 minutes
2. 800 on Your Math SAT, Software Development and Bugs
3. Estimating Bugs and the Complex Behavior of Simple Systems

photo credit: dave_7

A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.

My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It's actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.

After feature number 30, I turned to him and asked, "don't you have any business features in this thing?" His features were not about business use cases -- editing or updating some business entities, performing a business transaction -- they were instead about how this web application could function just like the client/server app it was replacing, i.e. "the administrator will be able to update the checkbox cascading order via the module screeen..." Blech! So next we trimmed out all of the UI features which cut the volume of features by 80%.

As it turned out, my friend had been so focused on UI specs that he forgot some critical business user stories. After adding these we were still down 70% of the feature volume. The trimmed features looked a lot like the specs for a web application framework, and not a very good one.

At the end, my friend asked me what he should do with those UI features we had trimmed out. "Delete with extreme prejudice," I told him. "I wrote that application in 1996 and made all of the mistakes you were about to make."

Lesson: If you're renovating an old application, go back to the business requirements and let the application and user interface come as a natural part of the development process, otherwise you will find yourself spec'ing out a web framework circa 1997.

Related posts:

1. How to learn a new programming language or framework
2. YAACGF – Yet Another AJAX Component GUI Framework
3. Week in Review

photo credit: Potato Benevolence

The recent acquisition of Sun by Oracle, and not IBM, took the community by surprise. Open source Java developers have benefited immensely from Sun's Java and IBM's contribution to Java space. IBM has a generally favorable view from open source community since IBM has few significant open-source contributions including those to Apache software foundation and Eclipse. When I heard about IBM's talk of acquiring Sun, I was certainly bothered by the demise of Sun as a company but nevertheless hoped that whatever happens, Java and MySQL, and the strong community behind it, should stay largely intact. And I felt comfortable with Java landing in IBM's lap considering its largest contribution to Java community by any corporate vendor. Oracle is a strong and focussed company but its contribution to open source world is minimal. As open source developer or company, you are also concerned about the fate of mysql. Like everybody, I am trying to make sense of what this will mean for the open source developers.

Why not IBM? And, more importantly, why Oracle?
Although talks between IBM and Sun dragged a bit, I felt certain that sooner or later, IBM would be Sun's choice. Why? because outside of Sun, IBM is the largest single company that has probably the largest stake in Java remaining successful. And Sun, for its part, will not give away the ownership of its crown-jewel, Java, to a company that is not committed to Java. IBM offered about $7B while Oracle acquired it for $7.4B. I strongly doubt this was the main reason. After all, Sun did open-source Java recently and Solaris not long ago. To me, Sun's concern over regulatory approval was a bigger reason. The impact that a failure of approval would have on future of Java and Solaris was probably unacceptable. Hence, they decided to go with safer alternative, Oracle.

Besides regulatory compliance, Sun may be thinking that Solaris is certainly dead in the hands of IBM. IBM already has a OS and hardware base that would conflict with Sun's offering. Whereas, Oracle may see value in preserving Sun's Solaris and hardware offering and bolstering its suite of offering. Oracle's press-release refers to the fact that they are planning to offer full application-to-disk suite of tools. Oracle's efforts with RedHat Linux based Unbreakable Linux haven't had tremendous success and there may be large market for Oracle Database on Solaris platform that is mature and proven.

What can open-source community and customers expect?
Just as Websphere, DB2 go together from IBM and .NET,  SQL-Server go together from Microsoft, Java/J2EE usually go with Oracle Database on Solaris or Linux. This is a preferred technology stack for quite a few large corporations (banks and financial institutions included). Oracle also has BEA Weblogic and will have not problem going with any other application servers like JBoss or Tomcat since its own Oracle Application Server isn't widely used anyway. There may be some benefits to such large corporations with the increased synergy between Java and Oracle and Solaris and Linux. However, Oracle's plan for application-to-disk sounds more like Microsoft's Vendor Lock-In strategy and needs to be taken with a grain of salt.

For small and mid-size companies it could be a different story. A large number of these either Java/J2EE and/or MySQL. Sun's Open Sourcing of Java is certainly going to help the community stay away from much of the impact. Prime contributors like Apache Software Foundation, Springsource and JBoss should be able to continue to innovate on Java front. The future of MySQL, a favorite not only for Java/J2EE but also LAMP and Ruby/Rails community, seems clouded now. Today's article from Wall Street Journal (WSJ) rightly raises the concern of small and mid-size companies that have been counting on mysql. Oracle does have a huge conflict-of-interest in perserving the status quo, and letting MySQL grow. Whether Oracle wants to admit it or not, mysql does represent a revenue forgone for its own database offering. Granted Oracle is much more powerful and featureful than MySQL, but if mysql can work for websites such as facebook and google, it should be good enough for lot of other websites.

For Oracle, it is best if it accepts that open source databases are here to stay. Killing or limiting MySQL growth will only alienate the community and lead them to look for alternatives, and they are a few (Postgresql etc.). Oracle should find a way to make it easier to migrate from MySQL to Oracle when they are ready (and companies do as they grow). Oracle may even decide to create goodwill in open-source community by letting MySQL, InnoDB combination grow. Oracle has thus far shown little interest in furthering open source community. With the acquisition of Java and MySQL, it has a great opportunity to please or to annoy open-source community. We can only hope that Oracle finds a way for both itself and open source to survive and grow peacefully.

Related posts:

1. Another Brain Fart on Why Open Source is Bad
2. Adobe “Open Screen” is not “Open Source”
3. FlashDevelop: Open Source Flash IDE

I've been spending some time with our internal sales and marketing team to hash out some of our goals for the year, and it became quite clear to me that non-developers are on their computers all day long facing some of the same technical challenges we do.

Some of the tasks they have to do:

• "take the data out of the spreadsheet for last quarter and compare it to this quarter"
• "gather the bounced emails from our newsletter posting, and update our list, pulling out duplicates"
• "replace all the names and addresses from our NDA agreement each time it is sent to a new client"
• "slice and dice google ad-words and google analytics data"

So I've resolved to take some time each week to 'Adopt a non-techie', and help them spend less time 'screwing around with the computer' and more time on the most valuable tasks they do.

In the same way that developers need to be as efficient as possible with the tools they use, so do the rest of the people at your company. At Pathfinder a good number of us have attended Neal Ford's Productive Programmer talks at the NofluffJustStuff conference, which covers a series of strategies for becoming extremely efficient as a developer. For those on our team that haven't attended the presentations, they pick up the best tricks through pairing and internal developer brownbags, but now I suggest we take the same approach with our business team.

While the benefits of having two developers pair on a technical task has been covered a million times, I would say it also applies to pairing with your UI designer, QA and BA resources as well. Whenever they need to take lots of text and reformat it, search/replace, etc, they might be tackling that problem manually, when you could help them solve it with a quick script or finding the plugin they need.

A few areas you might be able to help them with:

1. Forms and mail merge in word
2. Advanced searching and replacing in word
3. Google docs now has more powerful regular expression capabilities for searching and replacing (Actually, I could do a whole post on the benefits of getting your team to use GoogleDocs, would anyone be interested in that?)
4. Building a quick survey with google forms or surveymonkey
5. General text manipulation
6. Searching through all of their emails or local documents for anything related to the 'Jelly Belly vs. M&Ms' case
7. Excel spreadsheet manipulation, charts, etc.
8. Web searching and data extraction
9. Managing and sharing bookmarks and research data with others
10. Even tools like Selenium or iMacros could help your Business team automate repetitive form filling, web searching or web site testing.

Goals (First do no harm!):

1. Find the right problem. Just like we see in Product development, sometimes the most difficult problem is also the rarest, and not the best use of your time. In fact, the greatest area of efficiency is more likely to come from something they know how to do, but could be doing faster. (Instead of saving them 30mins off of a task they do twice a year, you might find something that saves 15mins every day!)
2. Don't expect them to become a developer. The goal is to reduce the time these things get in their way, so they can focus on the higher value stuff.
3. Make it easy for them to repeat the process (let them document it in their words, or even make a screencast while you're doing it)
4. Share your successes with the rest of the team (notes and screenshots/videos up on the wiki)

Use the right tools for the job!

While its best if you can help them to become more efficient with the tools they use everyday, you may find that they are just not using the right tool for the job, or if its a one-time thing, and you need to bring your toolkit with you.  For that I recommend a usb drive with your favorite PortableApps (notepad++ is great for text editing), or my new favorite PortableUbuntu (which lets you run linux off the usb drive, while accessing the files on the windows system)

What gets in your way?

To the business folks out there, what are some of the tasks you do to manipulate data? What frustrates you or eats up a lot of your time?

Reach out to your nearest techie, I bet they can help, or post your problem here and we'll make some recommendations.

Related posts:

1. Can your Selenium do that? Testing flash/flex and silverlight in web apps with iMacros
2. Stick with ERB or move to Haml
3. Does your project have Code Ownership Culture?

Having learned a long time ago the value of automated testing tools like Selenium, jMeter, and soapUI, I'm always on the lookout for new improvements in these tools. While I love Selenium and other frameworks like it, it has the limitation of not being able to test Flash/Flex/Silverlight or Java Applets. But if you need to test flash and silverlight components of your web app, in an automated way, the  iMacros testing tool might be worth checking out.

No Free Ride

While the free version of the iMacros plugins for InternetExplorer and Firefox allow powerful web scripting similar to Selenium, to be able to do the flash/flex and silverlight, you have to get the paid version or the 30-day trial. I downloaded the trial version to see how it compares to Selenium and what kind of damage I could to.

Going through some of the online demos, I saw you can actually do an image comparison to assert that something is visible in flash, and even have the test click on that part of the app.  The process involved taking a screen shot of the app, grabbing the section you want to use as the target, and then specifiying if you want the script to just assert that section is contained with in the app, or if you want it to also click on it.

I  followed the example to create a test that opened up a flash swf file and navigated through the app, asserting that certain image sections, like buttons and instructional messages appeared in the flash app. While the process wasn't that hard, I could see how it would be brittle as the tests would break whenever slight changes to the graphics happened.

One possible way to defend against brittle tests is to share the image assets that make up a flash app and its assertions between the flash designer and the tester. If the testing person has the access to the source code and images that make up the app, the script could refer to 'start_button.png' from the source tree, and even if the designer updates that file, the test will still pass.

You don't have to use the image detection to drive the script, you can just have it click on things according to their position, but the image detection was more interesting to me,  and I noticed that if you resized your window, the positional detection would be incorrect.

Feeding the script with User Data

One of the stand out features is having the script prompt the user for input, which I think could be extremely powerful when using the test as a data generator.  One of the ways that I've found to encourage Selenium adoption on a new project is to set up the tests so that they automate the most common tasks, and help developers and the BA/QA team generate test data to aide their manual testing.  With Selenium that required that we put some extra components into the iframe, to let the user select values that would be used within the script. I've also used selenium in the past as a way to automate certain personal tasks like filling out online surveys, or reconfiguring my stupid motorola router after a power failure, and I could see the prompting feature of iMacros making those scripts easier to create.

iMacros also lets you feed a script with a .csv file, and have it loop over and repeat for each row, which can be a good way to seed some test data in an app, while putting it under a bit of load. (Not sure how to best have two iMacros scripts going against one server like I used to with Selenium, but I bet its possible)

Iopus, the company that makes iMacros, is actively encouraging a community to share common scripts, and includes several good examples of their own, one which fires off searches against multiple sites, after prompting you for a search term.  (which I plan to create my own to blast searches against my favorite online classified sites like craigslist, oodle,  googlebase, kijiji,  listpic, and ebay)

Overall, I would say compared to Selenium, iMacros is:

• Slightly less intuitive to me in terms of syntax, assertions, and scripting capabilities
• Capable of working in Firefox and InternetExplorer
• Loaded with great examples, documentation and video tutorials
• Similar to the Selenium IDE interface for recording, editing, and  rerunning tests
• Designed with user interaction in mind (easy to record, prompting for user input, csv import)
• Taking web scripting to the next level with powerful  data extraction capabilities

Stuff I didn't look into yet

• Integrating the tests into the Continuous Integration build with either Cruise or Hudson
• How to use the Data extraction capabilities
• Invoking Javascript from the test
• Having the script take  a screenshot on failure
• Invoking the test script from  Java  or Ruby
• Drag & Drop Ajax
• Stepping through the debugger
• Firing off multiple sessions

No matter which tool you choose, having some level of automated functional and UI tests is critical. It saves everyone on the team time on menial and repetitive tasks, can be a great way for new people to learn the app, provides a suite of smoke tests you can run throughout the development cycle, and it can help you free up your QA resources to focus on higher value goals.

And what about you?

1. How do you test flash/flex/siverlight/java Applets in your apps?
2. Is there anything that Selenium can't do for you? (Other than Flash/Flex, Selenium has always been able to do what I need)
3. What parts of your UI testing have you been able to automate? (And what's your next goal?)

What do you think you could do with iMacros? Could you use it to help your Business team be more efficient? (Post a challenge, we'll see if we can tackle it with iMacros or Selenium)

Related posts:

1. Ajax Testing: Doubling Down with Selenium and JMeter
2. Skinning Flex with Illustrator CS3
3. Flash/Flex physics engines and examples

In an interview with Newsweek magazine, Irene Au, User Experience Director at Google discusses her responsibilities, and in the process, reveals some telling things about the way design decisions are made at the multi-billion dollar internet company.  Perhaps not surprisingly, she makes it clear that Google takes a data driven approach to interface design just as it does to everything else.  The subjective opinions of art directors or visual designers don't play a key role in the design of their products.  As she states, "A lot of our design decisions are really driven by cognitive psychology research that shows that, say, people online read black text against a white background much faster than white against black, or that sans serif fonts are more easily read than serif fonts online."  No argument here.
But is a completely empirical approach to interface design desirable, or even realistic?  Isn’t it more likely that the left brain culture at google puts greater weight on the opinions of engineers, even if they are being just as subjective? One blog commenter put it this way, regarding Au’s interview with newsweek:

She says on the one hand that they rely on cognitive psychology research to improve the design, then in the next answer says that their pages have high information density, which cognitive research has shown to slow people down. She also says that they do what's best for users, but that the founders believe there should be one way to do things (presumably whether that's the way that performs the best or not). Sounds to me like what she's really saying is that they rely on human judgement when it comes to certain people (Larry and Sergey), but when professional designers try to use their own judgement (to suggest more line spacing, etc) that judgement isn't enough. That's less a coherent approach to design and more a hierarchy of who's opinion counts. And not surprisingly in a tech company, sounds like designers lose.

Douglas Bowman, Google's first lead Visual Designer recently blogged about this very issue as he discussed why he was leaving the company.  According to him, Google always has relied on an empirical approach not just to how their products should behave internally, but how they should look and feel to the user, down to the pixel level.  However this reliance on data for every minute detail of the user interface is no substitute for true creative design.  And the culture at google which thrives in a numbers only game is stifling the visual design talent that Google has hired, leading to a vacuum of true visual design leadership.  Although gathering and analyzing data regarding interface decisions is definitely a good thing, Google has reached the point where it has become a crutch, and without leadership from people that understand visual design principles there is a creative vacuum that will negatively impact user’s enjoyment of the products that google ships.  Ultimately Mr. Bowman left because when it came to promoting a new design thinking, it felt like "Google was a massive aircraft carrier, and I was just a small dinghy trying to push it a few degrees North."
By data driven design, I am referring to the approach that says, anything at the GUI level needs to be tested with users and measured empirically using standard metrics like speed, efficiency, error rate, etc.  I don't disagree that given a problem, the more data I as a designer have, the better my design solution will be.  However, I don't think it's even realistic to think that every little nook and cranny in on a web app can be tested on, and even if it were, I agree that that type of thinking can create design paralysis under the wrong conditions.
As it turns out, although Google may suggest that it's product's interface designs are completely performance and data driven, that isn't possible.  The subjective, aesthetic decisions are made, it's just a matter of who makes them.  Those with an engineering or hard science background will invariably have more say in the direction the company takes, including the way it goes about designing its products. One such person is Marissa Mayer, who controls the look and feel of the search engine and related products.  According to a New York Times article recently written about her, and her role at the company, "Almost every new feature or design, from the wording on a Google page to the color of a Google toolbar, must pass muster with her or legions of Google users will never see it."  The article makes it clear that although they like to test as many design decisions as possible, Mrs. Mayer makes many design decisions absent any hard data.  For instance,

Google’s home page — spartan white embroidered with splashes of blue, red, yellow and green — mirrors her Wausau home and her penthouse.
“It used to be people would come over to my apartment and say, ‘Does your apartment look like Google or does Google look like your apartment?’ ” she says with a staccato laugh that has earned a following of its own in Silicon Valley. “I can’t articulate it anymore. I really love color. I’m not very knick-knacky or cluttery. My place has very clean, simple lines. There are some elements of fun and whimsy. That has always appealed to me.”

So it's clear that google does rely on the subjective decisions of some people when it comes to product design.  I have no problem with that.  But they should be honest with themselves about how they design, and stop insisting to us and to themselves that everything is numbers driven.   Embrace design as a distinct culture within Google.  Discourage the culture that would require designers to prove every design decision.  Realize that visual designers have something important to provide and then give them leadership positions so they can have the influence google needs them to.

Related posts:

1. Visual Design as a Balancing Act
2. Developing Good Wireframes Ahead of Visual Design
3. Does your project have Code Ownership Culture?

For my first trick, I give you JChemPaint.java from the JChemPaint project:

  if (file.getName().toLowerCase().endsWith(".cml"))
  {
    FileUtils.saveModeltoCMLfile(file, getCurrentModel());
  }
  else
  {
    FileUtils.saveModeltoMDLMolfile(file, getCurrentModel());
  }

This little beauty sits inside a Swing Action's actionPerformed() method. Sweet. There's similar logic for loading and renaming files as well. The point is that this logic shouldn't be sitting in the UI layer at all. It should probably reside in FileUtils. If you want to go a touch farther, you could have a working document model that contains the file name, whether the model has been modified without being saved (a "dirty" flag), etc. This would wrap the base model and intercept calls that might necessitate updating the dirty flag.

There are other ways to go here, but I think you can see how the tempting getName() led to introduction of file name extension logic here.

OK, tag, you're it. I look forward to seeing cases where getters and setters are absolutely necessary.

Related posts:

1. Bean of the Devil: Why Getters, Setters and Such are Evil
2. Bean of the Devil: Tally-Ho CMS
3. Ruby Internals: Overriding Object.require() to watch files as they are loaded

How do these pernicious little getters and setters undermine OO? Let me count the ways.

1. Encapsulation: the detailed implementation of an object is hidden from the rest of the system. Yes, yes, 99.99999% of all getters and setters are just fronting a private field and that's bad enough, but this is more about the getters, pulling data out of the object and doing things with it outside the object. They leak out, bit by bit, until you repeat yourself all over the place with slightly different manipulations of the data. Before you know it, you are looking at a siloed procedural applications that spurred the invention of OO in the first place.
2. Polymorphism: one type can substituted for another. If your implementation is out there flapping in the breeze, it's hard to swap types. Even if you do, the application of polymorphism is usually pretty weak. Leaking implementation into the collaborating classes really ties your hands.
3. High Cohesion: responsibilities of an object are strongly related and focused. If you pull information out of objects and deal with it in the collaborating objects, the cohesion is going to be progressively more diffuse.
4. Low Coupling: low dependencies between classes, low impact of changes in a class on other classes and high reuse potential. This is a killer. Again, you have your implementation info spread all over the countryside like in a procedural application. You change the implementation and you are in for a mega refactoring.
5. Information Expert: the responsibility goes to the object with all the relevant information. When you leak data into the collaborating classes, how can you identify the information expert?

There's more, of course, but the worst part is that in a system with getters and setters, the rot gets worse the longer the system is under development. A little enhancement can be done so easily by pulling an integer here, a string there and doing a little dance in a method without arranging the collaboration of necessary classes. You need to refactor and refactor to stem the tide. It is a problem of your own making that costs you time and budget.

So, think twice before you expose everything with getters and setters. I would argue that they be the exception and not the rule. A rare sprinking to season the system boundaries.

Related posts:

1. Bean of the Devil: Arguing the Affirmative
2. Bean of the Devil: Tally-Ho CMS
3. Scriptaculous and Why ‘extends’ is Evil