NetBeans has come a long way, and has a lot of features that can help you improve productivity, especially when you want to use Java standards. When do you use a standard, and when do you go it alone?
Today Frank Sommers and I attended NetBeans Day in San Francisco. Two things jumped out at me initially. First, the event was quite packed. It was hard to move around in the lobby between sessions. Second, Sun is clearly serious about NetBeans. Sun has invested in NetBeans and brought it a long way in the past couple of years, and the momentum is strong.
In the afternoon I watched a demo of new features for enterprise applications in NetBeans 5.5 beta, and saw that quite a bit of code generation has been built into the IDE. For example, you can generate EJB3 entity beans from database tables. You can also generate web pages that allow you to do basic CRUD (Create/Read/Update/Delete) operations on those tables. It was somewhat reminiscent of the kind of metaprogramming that's helped make Ruby on Rails popular, but with more of an IDE feel. (There's a wizard dialog that pops up to let you make choices, such as whether the CRUD web pages should be based on Struts or JSF.)
After the demo I asked one of the speakers, Ludovic Chamenois, an architect on the NetBeans project, to what extent the generated code must be maintained by hand after it is generated. He indicated that you have several options. Once you generate an entity bean, for example, you could modify it by hand to add business methods, such as methods that perform data validation. If you do that, then later when you add a field to the table to which the entity is mapped, you can't simply regenerate the entity bean using the Java to DB tool, because you'd lose the hand-added business methods. But you could use the IDE to add a field to the entity bean, and simply select from a list of unmapped fields in the table the one to which you'd like map your new field. Or, instead of adding business methods directly to the generated entity bean, you could subclass it to add hand-written enhancements. Later when you update the schema, you could simply regenerate the entity bean superclass.
We use the latter approach, maintaining a hand-written subclass of a generated class, in our own project at Artima. Which brings me to one of the feelings I got as I watched this demo. Two years ago Frank and I looked at Struts and a few other web application frameworks, and decided that none of them met our needs. Over time, we built our own simple, to-the-point web/mvc framework for our project. In those days, JSF wasn't even on our horizon. Today, we'd definitely look at JSF, but I'm not certain we'd choose to use it for the particular application we're working on. We chose Hibernate about that time as well. EJB2 just wasn't interesting to us, and EJB3 wasn't mature. But even though we like EJB3 today, it still has fewer features than Hibernate at this point, and likely a slower pace of future enhancement.
I believe we made the right decisions two years ago, and I feel there's a good chance we'd make the same choices today even though the options have broadened. But I could see clearly in the NetBeans demo something that I already knew, that by choosing not to use a standard, we give up a lot of advantages in tooling and other kinds of support. NetBeans 5.5 was very conscious of EJB3 annotations, and JSF component to managed bean mappings, and so on. NetBeans 5.5's CRUD generator for JSF and EJB3 is already finished, whereas we're still merely planning to build one for our own framework.
Our home-built framework is going to be better for our project in the long run, because it is more tailor made. Nevertheless, I can't help but feel jealous of the tooling support NetBeans and other IDEs will have for the new standards of EJB3 and JSF.
When is the right time to use a standard versus roll your own custom approach? Bernard Woditschka, Software Architect at Anecon Software Design, gave one answer to this question when talking with Frank and me in a hallway conversation today about SAP. He said SAP's attitude is that you shouldn't customize their software to fit your business processes, you should change your business processes to fit the software. Bernard said,
There's a tendency among business people to use standard software, because there's so much there that you can't write all these features by yourself.
Part of the thinking, according to Bernard, is that SAP has worked with dozens of other companies, and SAP therefore knows more about what your business processes should be than you do. Plus, because of their economies of scale, SAP can offer their de-facto standard software for a fraction of what it would cost you to create a custom system that better matches your current processes.
What do you think? When do you create a custom solution versus use a standard?
> Part of the thinking, according to Bernard, is that SAP > has worked with dozens of other companies, and SAP > therefore knows more about what your business processes > should be than you do. Plus, because of their economies of > scale, SAP can offer their de-facto standard software for > a fraction of what it would cost you to create a custom > system that better matches your current processes. > > What do you think? When do you create a custom > solution versus use a standard?
Hmmm, so, how do these companies differentiate from the crowd? Is it only about marketing?!
I disagree with this point of view, simply because it is too simplistic. You should always judge, just like you selected to make an in house framework for front end and Hibernate for DB, companies should select well the critical parts where they need to be different and either customize or build their own solutions.
PS: wise decision not to select JSF. Until now, as end user I'm very dissatisfied with what it does to URLs and the way it sometimes breaks navigation and search. Artima as no problems like these, so, congrats!
> He said SAP's attitude is > that you shouldn't customize their software to fit your > business processes, you should change your business > processes to fit the software. Bernard said,
They would say that, wouldn't they? And sometimes that's inded the best thing you can do, particularly in those areas that not strategic. The question remains how you're supposed to be better than the competition. By executing SAP prescribed processes better? That's what they would tell you. But of course that's not true and everybody knows it. To be better means to grasp new opportunities faster than the competition AND execute well. Faster than the competition also means faster than SAP.
What are those SAP people smoking? Their stuff is OK I guess but that statement about changing the business to accomodate their software is just pure BS.
I guess what he really wanted to say is that they have many components in their software that have been adapted to many existing business models (or at least abstracted the relevant features of any currently known business model) so in most cases you only need to minimally configure their software to implement your needs without having to build any new, dedicated and specialized component.
Just a guess... because otherwise it is a bit of a crazy statement. Then again crazy stuff seems to be the norm in the current software we have around.
"custom solution" versus "standard" seems like apples and oranges to me; how about "horizontal" instead of "standard"?
If what you're making cookies, and don't need them to stand out from the crowd, then you should try to find a cookie cutter that meets your needs. If, on the other hand, your cookies need to be in special shapes, or can't be "stamped out" because of their ingredients or baking requirements, then you need to "roll your own".
If you know you're going to need to make a number of cookies that are similar, but vary in shape and size, maybe you make a flexible form that you can use the in future.
Basically, SAP is saying "you should all make the same kind of cookies". That's good for them, because they only care about selling cookie making machines, and customizing them just adds to maintenance and support costs. It's not so good for the people that are actually trying to sell cookies.