John Reynolds's Blog

Why JMatter matters - a wake-up call for programmers

I am always interested in Eitan's activities, but jMatter really struck a chord when I read a bit about its background on the jMatter mailing list:

A small Austin software firm was "approached maybe a year ago by someone who wanted to develop a custom software application to aid him in his work."

"The customer was initially turned down."

"The problem was that the estimated amount of work to design and implement and deliver the solution approximated three man-months of software development. The customer's budget was nowhere near that."

"This customer recently contacted them again, coincidentally at a time where they became aware of the jMatter framework. I ended up contracting to do the job using jMatter. I built the entire application myself in approximately eight days. There were 2-3 follow-up incidents where small change requests or bug fixes were implemented (maybe 2-3 hrs each)."

"Today, this customer is using this custom solution to aid him in his work and apparently it has already saved him a considerable amount of time and effort"

What's not familiar is the outcome of Eitan's tale: The small budget customer gets a solution that he needs at a cost that he can afford. This outcome is what intrigues me about jMatter... Eitan was able to take a project that should have taken three man-months to complete, and he successfully implemented in 8 days (more or less).

This is a big deal if you are an independent software consultant... the number of potential clients on limited budgets far exceeds those with fat bank accounts, and the competition for the "well healed" clients is brutal. If you can find tools that make it profitable for you to service small accounts, you might do quite well for yourself...

But even if you aren't an independent or working for a small firm, tales like Eitan's ought to be a wakeup call: The "Custom Software" business is changing... Some clients have been paying far too much for the custom software that we've been writing for them, and they're probably about to figure that out.

Let's take a look at Eitan's numbers...

This example is hardly a scientific survey, but using these figures one could make the case that over 85% of the "custom" development effort that this client would have paid for (without jMatter) would have been used to implement infrastructure and functionality that really wasn't "custom" at all.

Of course jMatter is not appropriate for all custom software... nobody would suggest that... but many, many custom business applications have a great deal in common, and it is not unreasonable to suggest that a manageable set of tailored frameworks could be used to eliminate 80% of the effort necessary to write 80% of the "custom" applications that we are writing today (Yes, I made up the 80% figure... but it's probably in the ball-park).

This is why jMatter and frameworks like it should matter to all professional programmers... If custom software can be now be built for 20% of the effort that it once took, the entire cost structure of our industry is about to go bonkers.

Programmers in the US had to adjust when companies started offshoring software development to programmers who work for lower wages... Imagine the adjustment that we'll all have to make if projects that once paid our salaries for 3 months now only pay our salaries for a couple of weeks?

Please don't take this "wake-up call" the wrong way... these new developments in programmer productivity are just the latest in a long chain of improvements. Back in the 80s, I wrote business applications in assembly language... Nobody would pay me to do such a thing today.

As the tools evolved, I evolved. I think that the tools just evolved again ;-)

Comments

• H John, great post. On a related note, we also posted a detailed announcement of JMatter and interview with Eitan at InfoQ:
  http://www.infoq.com/news/jMatter.

  Posted by: fmarines on June 25, 2006 at 01:51 PM

• Looks very interesting and promising. I've just started to read through the docs but ...

  Is the app customizable?

  Posted by: mnuttall on June 26, 2006 at 08:39 AM

• this question came up on the mailing list last week. i assume you're asking whether custom views can be plugged in to the framework. yes! i just recently posted a sample project on the mailing list showing how this is done. i plan to integrate this information into the documentation this week.

  Posted by: eitan on June 26, 2006 at 09:01 AM

• That would be part of it. I probably should read and play more.

  What I have found is that most of my development work is UI related. The domain is the "easy" part. I am just trying to work through these things in my mind. The wizard tool might solve some "issues".

  Things that come to mind are fine grained security and "workflow". By workflow, I mean entities that that have attributes that are modified only under certain circumstances.

  Posted by: mnuttall on June 26, 2006 at 09:33 AM

• Btw, I'm a fan of Naked Objects. Or as they say round these parts - Necked Objects. :)

  Posted by: mnuttall on June 26, 2006 at 09:37 AM

• I'm fascinated. You always post the good stuff John, thanks.

  Posted by: ilazarte on June 26, 2006 at 10:49 AM

• 
  I think naked object frameworks like JMatter are definitely the way of the future. But as mnuttall pointed out the ability to customize them will be vital.

  
  I actually started work on my own naked object framework a few days before I found out about JMatter. So far I am pretty happy with what I have so far. The user should be able to pick and choose just how much they want to leave to the framework and how much they want to do themselves. Hopefully I should be starting a project on java.net soon.

  
  Luke
  

  Posted by: luke_sleeman on June 26, 2006 at 08:07 PM

• You will always get a large, order of magnitude, productivity increase like that when the developer is really excited about a project and has a large amount of experience and existing code to draw from in that specific area. I'm sure the framework is good, but the productivity increase is based on the experience and excitement of the developer rather than the framework.

  Posted by: gamigin on June 27, 2006 at 07:33 PM

• "I'm sure the framework is good, but the productivity increase is based on the experience and excitement of the developer rather than the framework."

  Perhaps... but I doubt that's the only factor.

  Look at the productivity increase between EJB2 and EJB3... In that case experience and excitement have played much less of a role (in increased productivity) than the fact that the EJB3 framework is just a heck of a lot better than the EJB2 framework.

  You can also see similar productivity gains for simple Web-based CRUD application with Ruby on Rails... it's just a darn good framework for that specific problem domain.

  You're absolutely right that the jury is still out on jMatter... but only time will tell if others will have experiences similar to Eitan.

  Posted by: johnreynolds on June 27, 2006 at 08:58 PM

• I've spent some time with the documents since I last posted here. They look very good and it seems to handle most of my concerns.

  I really hope I get a chance to try it out for real (and send Eitan a check :) ) and will provide back my experience. I do have a project that I want to try it on - Unfortunately I am too far along to go back.

  Based on what I have seen (and all the things I have done) I think the productivity gains are real. Actually, it is not so much a productivity gain as it is getting it done faster.
  

  Posted by: mnuttall on June 28, 2006 at 08:12 AM

• John,

  These figures of Eitans are pretty typical for NO-style applications. I did the programming on a comparative study of an application developed first using a classical approach and then using NO. This is documented in Richard Pawson's PhD thesis (chapter 7). There are some figures in there that show 7-fold reduction in classes - and I can tell you myself that the NO application was *much* more fun to code.

  
  On a related note, NOF itself is now live, handling the Irish Government's State Pensions Benefits systems, with 90 users. We're now pushing with implementing 4 further benefits (such as child benefit). I confidently expect being able to do one such benefit every 3 months, which is pretty good going by anyone's reckoning.

  
  And to indulge in a little plug if I may, I'm also working on an NO-style framework, called Essential. Not as far ahead as Eitan, but I'm busy applying the benefit of the Irish experience to all the goodness of Eclipse RCP, Java 5 and annotations.

  Posted by: dkhaywood on June 28, 2006 at 02:24 PM

• dan,
  thanks for setting the record straight on the reasons behind the productivity differences. it doesn't matter whether you even use a framework: when you get the user interface for an application *for free* (you don't have to write it), that's going to save you a little bit of time. :-)

  Posted by: eitan on June 30, 2006 at 11:57 AM

• Just too bad it feels so awfully Javaish, the frontend is beautiful but suffers from certain emulation shortcomings such as the semi-MDI interface. Will Java 6 help in this respect? Awesome idea though!

  Posted by: mrmorris on November 19, 2006 at 08:22 PM

This work is licensed under a Creative Commons License.