ArchiTechie Journal

In Which I Claim that Java is NOT Dead, and Groovy will be Bigger than Ruby

UPDATE 12/11/2007: I have recently started using Ruby and Rails on a Java project. Does this invalidate my assertions here? I don't think so, it merely underscores the key application for Groovy: tight integration with Java source and libraries. I had the need to do some schema management, for which Rails migrations are the simplest approach I know, and some batch scripting; neither of which intersected with Java at all. A final factor is that I just know Rails far better at this point.

As I have talked about in previous posts, Java (EE) has been optimized for Enterprise requirements: Big applications with heavy-duty scalability, performance, and security, often weaving together many disparate databases and integrating with other applications. On the other hand, Java has most decidedly NOT been optimized for productivity, maintainability, or developer self-actualization. Although some frameworks and tools have attempted to address the latter set of requirements, nothing comes close Ruby and Rails.

For green-field development, small-medium sized projects (and medium can mean easily thousands of users nowadays), I would really, really lean toward Ruby on Rails. However, what about for projects in organizations that have standardized on Java, or for developers who are already Java ninjas? Enter Groovy, and Grails.

The promise of Groovy, and Grails (though I am sure there will be other frameworks), is to bring productivity, maintainability, and, well, fun to the Java world. Because these are Java-based technologies, projects can leverage these capabilities to get to market quickly, and Scale Later, falling back on all those nice big E Enterprise features of the Java EE stack. That, I think, is the Holy Grail of Java development: Rapid development early, beefing up later.

That is why, IMHO, Groovy and Grails might be as big as, if not bigger than, Ruby and Rails. I expect I will be writing a lot more about this in the future. Also, look forward to a new blog called GroovyCode, where I intend to capture bits of Groovy coding goodness.

For your further reading pleasure, I include here an email thread I had with Scott Davis, a Groovy pioneer and operator of aboutGroovy (as well as all around coding Rock Star) [from Aug. '06]:

> Thanks for the info, very helpful. As for the client, it's an
> outside shot right now but I will see where it goes. I originally
> suggested ROR, but he wasn't "comfortable" with it. He couldn't
> really state the requirements that he thought were lacking, but I
> think he just feels it is not industrial-strength enough. In order
> to get his business, then, I proposed a Java solution.
>
Ahh, "industrial-strength". Now he's showing his cards. Grails is
based on "industrial-strength", well-proven technologies like Spring,
Hibernate, et al. I firmly believe that RoR is "industrial-strength"
as well, but it doesn't have the track record that Java does at this
time. +1 Grails.

>
> Now here comes GOG, seemingly on the cusp of critical mass. Which
> got me thinking that I could offer ROR productivity, with the
> option to (readily) leverage all the enterprise capabilities of
> Java down the road. And I can talk about reusing some of the code
> I have, though it might not actually make sense.
>
You've hit on the sweet spot of Grails. I honestly haven't gone into
a Grails app and seen what exactly is salvageable in terms of pulling
out the Spring, Hibernate files and using them in a pure Java
environment, but I can't imagine that it'd be too hard.

> Well, there. Probably more than you wanted to know. Before I let
> you go... What do you think the productivity (functionality /
> time) advantage of GOG is over Java Webapp development? Any reason
> it could not scale to, say, 100s of 1000s of users?
RoR folks like to claim 5x-10x increase in time to production over
J2EE. I'm not *even* going to venture into that rats nest for Grails,
especially this early in the game.

The bootstrapping aspect of Grails is pretty compelling -- download a
single tarball and *poof*, instant app. It, however, is running Jetty
and HSQLDB. I haven't played with hooking it up to an external db, or
running it in another servlet container, but that certainly
diminishes the "out of the box" / time-to-production. Of course, this
is pretty much a one-time cost.

Creating initial views is pretty easy (grails generate-all), but hand
editing them takes some time and coordination. If you don't like the
default ordering of the fields, for example, you need to hand edit
list.gsp, edit.gsp, view.gsp, new.gsp, etc. If you add a single new
field to the table, there is no clean/automated way to migrate your
views as well. This is an ongoing cost.

I think the biggest win is letting Grails handle all of the
"plumbing" issues for you -- Spring, Hibernate once again.
Infrastructure like that getting autogenerated is huge.

> How about ROR by comparison?
Much more mature, and I think at this stage of the game it has a
better coordination/migration story for iteratively adding fields and
keeping your model and view in sync. For green-field development with
no ties to Java, it's a pretty compelling story.

I have recently made my independent business more official, I have a card and everything:

For more information on me and what I do, you can browse to Rapid and Affordable Development or take a look at my Resume.

- John
jtroxel@yahoo.com

OK, so now I guess I am becoming a "Rails Guy." At least, I have been doing some Ruby on Rails programming lately and am generally very impressed.

It is still Web programming, there are no major paradigm shifts here. However, Ruby on Rails is an example of how a lot of little things done right can really add up. Ruby is a fine scripting language, improving upon popular languages like Perl and Python. And Rails is an example of getting the little details of Web programming right. Rails is optimized (as I see it) for (1) Productivity and (2) Maintainability. The following are what I really like:

• The clean, simple ActiveRecord ORM layer.
• A full-fledged yet simple MVC that is easy to comprehend and get around in.
• Sensible defaults and very little configur-bation; "convention over configuration."
• A good job of making the most common tasks simple; the 80/20 rule.
• "rake migrate" is the coolest way to manage schemas that I have seen.

So, is Rails the answer to everything? Of course not, you won't find sweeping generalizations here. As always, it depends on *specific* requirements. Ruby and Rails are geared toward fast and simple development and maintenance. Java and JEE technologies generally have not prioritize these factors as highly as Enterprise requirements, e.g. massive scalability, security, etc. And I am not saying that one or the other stack is incapable of solving a kind of problem, rather that it is a matter or priorities, focus, and fit.

So I do like Rails a lot, I think it is probably the best solution for many small-medium sized webapps. But it is not necessarily a replacement for Java, especially in the enterprise. The trick is for decision-makers to weight their needs for big E Enterprise requirements against speed and simplicity.

I went to a great presentation by Neal Ford last week at the DJUG, entitled the Productive Programmer. Neal is a sharp guy, a good speaker, and a solid thinker on improving productivity. Go ahead and CRTL-Enter nealford in your address bar to check out his site (you'll see what I mean).

The talk was a bit of a wake-up for me. His premise is that the rise of the IDE has made programmers, well, lazy (my words, I don't think he went so far). I realized that I have let some old but valuable skills languish in the past few years. So Neal's talk has inspired me to sharpen the saw back up. For example, I have made the decision that Ruby will be my scripting power tool moving forward (used to be Perl), and I will not shy away from opportunities to explore automation (even if it is initially just exercise).

Another point that resonated with me was the idea of the "perfect" editor. I do think that I am now as productive over all in Eclipse as I used to be in Emacs (with a side trip through NetBeans). But Neal hit on two things that are missing: Multiple cut/paste buffers (kill-loop in Emacs) and editor scripting. Though I am intrigued by the lightweight JEdit, I am determined to stay in Eclipse and make the best of it. I think that surely these two deficiencies can be addressed.

On the multiple buffers front, I quickly came up with an answer that works for me: CLCL. This tool is actually a utility that caches your Windows clipboard. So CRTL-C still works like normal, but you can also reach back in time and paste something from 30 cuts ago. Sounds trivial, but it can change the way you edit.

As for the scripting integration, I haven't looked very far. Prashant Rane's blog led me to Eclipse Monkey, which looks interesting--it's Javascript, which I can defnitely code. I might keep looking, though, for something that provides editor hooks for Ruby, Groovy, or BeanShell. I'll post again if I find the silver bullet.

I am available to help Clients develop applications cheaply and quickly, applications that help them to reach more customers and reduce costs. I can help clients use the Web to make breakthroughs in marketing, sales, and operations.

I have built dozens of successful applications for the Web and other environments. I can provide hands-on expertise across the software development lifecycle: from strategy and requirements to architecture and design to development and testing. I also provide project management and "general contractor" services, so I can bring the right talent to the table for most any web development project.

The following is a quick summary of the skills and capabilities I provide to help you achieve robust solutions quickly and at affordable rates:

• Experience in online communication, eCommerce, and improving efficiencies.
• Technical lead, architect, and developer experience on dozens of projects, including complex applications for Sheraton Hotels, Travelocity, Budget Rent-A-Car, and the Veteran's Administration.
• Programming experience in Java (5+ years), C (3), VB/ASP (3), Perl (2), and lately Ruby.
• Effective, hands-on skills as a software engineer, architect, and business/systems analyst.
• MBA and a Bachelor's in Computer Science.
• Extensive network of software and Design professionals for general contracting services.
• Very competitive rates, for myself and subcontractors.

My Resume describes my skills in much more detail. I'd love to make your development project a huge success, drop me a line if you are interested.

- John

jtroxel@yahoo.com

The ability of an organization to Manage for Agility is one of the most important success factors for modern software development. This factor encompasses the critical role that Management--or the project Client or Sponsor--plays in Iterative Development. In this post, I will attempt to address what this factor entails and how it is accomplished. I will also briefly recap why this management style is superior. I have yet to complete the Overview of the Reference Model, but Agile Management is so important that I wanted to flesh out this success factor first.

What
Iterative development is perhaps the key attribute of modern software success, but without management support it is impossible. To manage for agility, leaders must go against many traditional management styles and ingrained practices. It is a natural for successful business people to try to avoid future change through detailed planning and up-front analysis, but changes are inevitable. Trusting the team and the process to produce the best solution, allowing the scope, the design, and even the process to emerge, is what it means to Manage for Agility.

How
To manage agile projects, sponsors must resist the desire to plan and design the entire project before starting any development. To be agile, management must instead embrace a flexible model that responds to changing requirements and an evolving understanding of the solution. Management must trust the process and the team to produce top quality software, without a relying on a rigid scope.

Often it is the "commercial Model," contracts, SOWS, etc., that most influences the interaction between management and the project team. To manage for agility, the commercial model must provide for evolving scope and design. Put another way, attempting to fix the scope in agreements up-front is simply at odds with an agile style. When using consultants or contractors, a Time-And-Materials approach allows for the most agility, or the agreement can employ separate SOWs created at the start of each iteration. Another approach offered by Kent Beck is the use of "Optional Scope Contracts."
It is also important to understand that agile does not mean that no planning or requirements are done up front. The project still needs a first cut at the inventory of requirements--e.g. a Scrum backlog or a Use-case survey--that is the source from which iteration requirements are selected, refined, and built. An agile project can also develop a detailed, "pro-forma" project plan, but managers should not feel compelled to stick to the original as the team adjusts to accumulating change.

Why
Why should managers buy into this approach, when traditional project management techniques have worked on all kinds of projects, from construction to aerospace engineering? Because software development is fundamentally different from construction or engineering, and treating it like these disciplines magnifies the risk of failure, raises costs, and produces worse software.
Change is unavoidable in Software Development, more so than most any field. Alan Shalloway made the claim, at a recent Agile Denver meeting, that software development is not like building a bridge; it is more like building the first bridge... or the design phase of a bridge project. An analogy is also often drawn between construction and software development. However, many experts claim that software development is essentially all design work, and the only step that is really like construction is the compile/build cycle.
The highly successful Scrum process is based on proven new-product development processes used by Japanese companies. Indeed, the Scrum proponents and many others have claimed, accurately I believe, that software development is very like new product development. If we look at software development as roughly analogous to the design and development of a new kind of car, or a new consumer electronics gadget, it becomes clear that the nature of the process is unpredictable and should be managed accordingly. Agile management uses an empirical process management approach to produce a better product. One need look no further for evidence than the difference between American cars and Japanese, at least until very recently.
Alistair Cockburn expands on the idea of "responding to change over following a plan:"

...traditional process management—by continuous measurement, error identification, and process refinements—strove to drive variations out of processes. This approach assumes that variations are the result of errors. Today, while process problems certainly cause some errors, external environmental changes cause critical variations. Because we cannot eliminate these changes, driving down the cost of responding to them is the only viable strategy. Rather than eliminating rework, the new strategy is to reduce its cost.

[NOTE: I think he means code rework--Big Up-Front planning and design will result in more rework of other work products, assuming the effort is not wasted entirely as these products are abandoned.]

Business needs, priorities, understanding of user needs, expertise with the
technical platform, market forces, and available technologies... All of these
can and usually do change over the life of a project. Agile management rolls
with these changes and capitalizes on them to make the best software possible.
Smart project sponsors can use agile management to build better software for
less money.

Here, again, is my Reference Model: a 30,000 ft. view of software success. This post will provide an overview of the categories from the model--sort of a taxonomy of success. See my previous post for more information on how I derived this model.



Groupings
Organization and Project Management
Perhaps this should be entitled simply Organization and Management. This grouping deals with factors that are beyond the scope of any project team--organization and management at the highest levels.

Project Team
These factors deal more specifically with the project team involved directly with producing the software.

Iterative Development
This category contains factors that relate to producing software in an iterative, incremental, adaptive manner.

Productive Culture
Factors dealing with the kind of people the Organization employs and how the Organization fosters a culture that promotes productivity.

Productive Practices
Specific practices that help the Project Team develop software efficiently.

Software Engineering (for Large Projects)
Factors necessary for projects with a large number of developers and/or critical consequences of failure.

Factors
Manage for Agility
This factor encompasses the critical role that Management--or the Client--plays in Iterative Development. Leadership must be willing to launch a project without detailed plans or specs, and trust the team and the process. Further, project clients must realize that the agile approach is a Good Thing, allowing the team to respond nimbly to a changing world, and producing more relevant software in less time.

Deliver Value Quickly & Often

Another aspect of Iterative Development, this factor focuses on the uultimate goal of software development: working software. Teams must focus on producing working software from the very first iteration, and keeping implementation as relevant to the needs as possible by avoiding unnecessary interim work products and long time lags.

Continuously Learn & Optimize

The final component of Iterative Development is the concept of continuous improvement. Iterations afford the team with the opportunity to exercise all lifecycle activities in short bursts. This means they can reflect, learn, and optimize their process and practices with each cycle.

Empower the Project Team

Also solely in the Management arena, the client of the project must provide the project team with the tools, resources, and support necessary to suceed. As much as possible, the team must be allowed to organize and direct itself however necessary to deliver the requirements.

To Be Continued...