Venkat has a very nice post on the importance of language idioms.  He starts with a small Java Swing application and transitions it to Groovy, JRuby, and JavaScript.  I can’t get enough of this kind of stuff, because it shows just how easy it can be to make the switch from Java to a dynamic scripting language (and back).  I, of course, think the Groovy version is the best for me because it’s so similar in feel to the Java version.  This is a huge win for me because it makes context switching simple and allows me to choose the language that is best for the problem I’m trying to solve.  Really, Groovy is even better than that, because I can mix in static AND dynamic typing, so I can basically get the best of both worlds right in one.

I am interested in finding out more about how people in the industry (web/software) utilize prototyping. To that end (and to try out some new software from questionform I have set up this brief survey. Please answer these 5 questions and send it on to your friends and colleagues.

(more…)

With many parallells to the Selling Agile to the Enterprise presentation Ross and I gave at last month’s minnēbar (un)conference, Scott Ambler, goes a bit further by providing specific language (like diminishing returns* or, my favorite, opportunity cost**) to use when speaking to senior management when speaking about agile methods and their benefits.

Senior managers are generally smart people, regardless of what we might like to believe, although they will often be operating with less than perfect information and choosing from a multitude of alternatives. If you go in with an “us vs. them” or an “I’m smart and management is stupid” mentality, you’re likely not going to get what you want. A better approach is to recognize that you need to provide sufficient information, or more importantly a coherent argument, to them using language that they understand.

While I agree that data is a very important aspect of presenting agile, (and Scott touches on this also) you shouldn’t underestimate the “gut-feel” that people have towards agile methods telling them intuitively that they do actually do work. This should not be surprising as it is how management felt about development years ago, before we (software developers) drilled it into their heads that software has to be planned carefully and methodically and that changes to The Plan^TM must be met with resistance, followed by pain and suffering. Things like communication, transparency, and dealing with ambiguity are things that top managers have known and have used frequently to get to where they are. They also happen to be three key strengths of agile methodologies. Still, maybe we can find beauty in NOT doing agile development.

* Diminishing Returns. As more investment in something is made, the overall return on investment (ROI) increases at a declining rate until it reaches a point where it begins to decline. For example, if a diagram isn’t yet good enough for the situation at hand, then you can keep working on it until it is good enough, at which point any more work on that diagram is a wasted effort. Although the continued work still adds value, it doesn’t add as much value as when you first started because you likely addressed the critical issues right away. The concept of diminishing returns is critical because it enables you to recognize that it doesn’t make sense to try to “complete” a work product.

** Opportunity Cost. This is the cost of passing up a choice when making a decision. For example, if you could have spent $10,000 in additional testing and avoided a mistake that ended up costing you $15,000 to fix, then the opportunity cost of not testing was $5,000 ($15,000—$10,000). The concept of opportunity cost enables you to communicate the value in taking, or not taking, a course of action.