The UK-based J2EE framework vendor RemoteApps and its software has been put up for liquidation after its venture investors quit. RemoteApps is known for Xyrian, a pretty impressive J2EE RAD framework. This raises questions as to the market for pre-packaged frameworks/RAD tools that the market seems to be moving towards.
I'm increasingly seeing more and more movement in the industry towards frameworks/tools that raise the level of abstraction over J2EE. Companies like Altoweb, Compoze, Netspective, ObjectVenture and Wakesoft have bet their business on the need to simplify J2EE development with custom frameworks and tools. Perhaps more familiar to developers, we see the big vendors doing this with pushes like Weblogic Workshop, Oracle Business Components, IBM's service-oriented vision, etc. On the other side we see wild successes such as Struts, SiteMesh, etc.
Do developers just want to all the work themselves? It seems that the low-level frameworks seem to be most successful. At what level of abstraction does a framework become too cumbersome to be useful?
Press Release, taken from (http://www.remoteapps.com
Remote Apps Limited (in creditors' voluntary liquidation)
FOR SALE: Software assets that provide Service-Oriented Architecture for J2EE Application Developers
As a result of their venture capitalist deciding not to invest any further into technology in Europe, RemoteApps was placed in liquidation on 18 September 2002 and I am able to sell the intellectual property behind its application architecture software Xyrian. This represents an outstanding opportunity to acquire service-oriented architecture (SOA) software to satisfy the application development marketplace which, according to Gartners recent 2003 predictions, will change the face of development over the next five years.
Having already invested $5million over the last two years in developing Xyrian from a concept to a commercial product the opportunity exists to exploit the software that already operates on all the major J2EE application servers from vendors such as IBM, BEA, Oracle, Sun, etc and integrates with all major Java IDE toolsets. Plans have also been put in place to make the software available to the .NET platform to reach the Microsoft application development marketplace.
Xyrian provides rapid application development capabilities that deliver high quality applications with re-useable components around a loosely coupled architecture, allowing connection to multiple front-ends and/or web services without re-programming. Xyrian creates highly portable development architecture that enables applications to be ported across platforms without the need for code changes. Any application developed using Xyrian can be deployed across any application server and/or database.
For the users of Xyrian, the software delivers significant cost savings during the development phase of a project, reducing complexities and timescales but also saves a greater cost over the lifetime of applications by simplifying change management and maintenance. The software has been proven in commercial use for the past 12 months and has many reference clients including, Volkswagen, IPC Media, Umbro, Primark, Arsenal Football Club, etc. Other users of Xyrian included System Integrators, such as, Logica and Nettec who have used Xyrian to deliver projects to their clients. An indication of the recent demand for the product is reflected in a small on-line marketing campaign, run during June/July 2002, which resulted in over 2000 downloads and enquiries worldwide for Xyrian.
This website represents a cut-down version of RemoteApps' corporate and tech portal websites, containing key reference information regarding the technical and market positioning of Xyrian.
To request a copy of the software for evaluation, or for further details please contact Andrew McTear at McTear, Williams & Wood on +44 (0)1603 877540, fax +44(0)1603 877549, email [email protected]
From a business (not technical) standpoint it is hard to be a tools provider. You will never make as much money selling a solution to a technical problem as you will selling a solution to a business problem. Another problem with selling frameworks is that developers often feel like it would be easier/cheaper/more satisfying to build their own rather than purchase one that is going to have a per-seat licensing cost.
I, for one, am afraid of lock in to a particular vendors' idea of how things should be built. Lightweight frameworks are easier to take than heavier frameworks because they involve less lock-in risk. RAD tools almost always involve lots of lock-in risk because they have a particular view of how an application should be built, and if you need to do somethign that doesn't fit into that model then you either have to use some vicious hacks or you are just out of luck.
This is especially true for people using J2EE technologies. The point of J2EE is to minimize (elimination is impossible) the lock-in to a particular vendor. In the MS world lock-in is a given, so their RAD tools (Visual Studio, Access, FoxPro) are more accepted. That is why I believe the open source frameworks (like Struts, WebWorks, etc) have received a lot more traction than the proprietary frameworks. If you don't understand something or need to change something you can get under the hood and fix it or at least figure out what is going on.
very good point there, Dan.
I would like to add 2 points :
1) I don't think the level of abstraction has an impact on the usability of a framework. Usability is much more influenced by the quality of the the API-design. The only difference I see between high-level and low-level frameworks is the following :
* high-level-frameworks ==> niche market, high productivity gain
* low-level-frameworks ==> broader market, less productivity gain
2) A possible cause of the tough times for tool venders is that the software industry faces an incredible speed of evolution :
Every software-project-manager only sees the tip of the iceberg of the available components and technologies.
And because the market is so rapidly changing, every manager sees a complete different tip of the iceberg.
In such an environment it is very hard for a new tool or product build a solid user-base.
I was the founder and CTO of RemoteApps and thought I would just mention a few points.
Thanks Floyd for posting this. A good point of discussion.
Xyrian lacked numbers of users because it was never available to the developer audience in the way something like Struts is. Only in the last two month of trading was Xyrian available for download/trial. We had 2000 downloads in that time though.
RemoteApps failed because of the inability to recognise the developer as its customer until it was too late.
Building up a community of developers over time from 1999 as J2EE adoption grew would have given RemoteApps a better chance. Yes, we started in 1999 but you might only have heard about us in 2002! In that time open source projects took the limelight, no one knew RemoteApps even existed and RemoteApps wasn't available to satisfy the developer with instant access to try it out. You had to sign up as a partner to get your hands on the product.
Open source vs commercial software is a big discussion. Personally, I think that there is a market for commercial software even if there are open source equivalents. Excellent customer service, good documentation/education and having a damn good product helps.
Look at Caucho and Resin as an example. There is a company that built a Servlet engine many years ago and have built a good reputation, they cater for developers, offer support and have an excellent product. They manage to sell their product in a very tough market because they have built up a loyal following and you get service from them. I for one would pay $500 for it over Tomcat.
Don't take the failure of RemoteApps as a sign that the market is bad for products like Xyrian. Much depends on route to market, marketing, licensing methods, price and other business issues such as having an existing customer base to offer it to.
Personally, I think that Xyrian would make a good purchase for a J2EE server vendor looking to add something to differentiate themselves. But then I would say that.
Your statements raise a few more questions for me:
Who or what department caused the failure? Why was this not remedied early on? Why were you, as the CTO, not able to steer the undertaking into the right direction?
thanks for the info,
Bear in mind I am speaking with hindsight.
Initially the product was for sale for thousands of dollars(>50K). In 2000 this was possible it was the dot com peak. When the market slid and we needed to lower the price, on one hand you had investors that wanted a return and existing customers that had paid top dollar and on the other hand you had new customers wanting it much cheaper. Eventually, I did manage to change this and in the last 8 months the product was around $3000.
Our business plan said we would sell via partners. We had this agreed when we got investment. We gave it our best for about a year and this did not bear fruit so we then decided to offer the product online to a wider audience.
I did steer and influence the company in the right direction but I also relied on others too. We did steer ourselves in the right direction in the last 8 months and to be honest that was a great achievement for all at RemoteApps.
As with tech decisions, business decisions involve compromises based on the position you are in at the time.
I dont know much about the company (read about it for the first time here!), but it sounds like they've commited the all too common mistake of promising tech-companies: they have gone for perfection instead of actually delivering a product. I have myself started a couple of companies (two that made it, one that failed), the problem with the one that failed was that we wanted to release a "perfect" application instead of just releasing it. The fact is: no customers, no money. Think of all the frameworks and applications that are basically crap, but I bet the companies are making money!
My experience of the tech-business is that you have to try to make money as soon as possible, and that means pretty much as soon as you have something, anything to show to potential customers. The company I was involved in witch failed caught the attention of some major companies that are in the headlines every day, but we went to them a little to late to survive ourselves..
So for everyone out there building companies: Forget about perfect API:s and applications, try to make some money as soon as possible! You can always perfect your software once you have some breathingspace because you have some sort of revenue coming in!
Theres always a market of some sort for solutions that have a well-defined problem and target audience (even though it might be small in some cases).
Well, thats my take on it.
You are right with what you say about tendencies for tech-companies to go for perfection. Not sure how much we did this but we did have a version 3 level product that had been used on commercial projects from 1999. The software is surprisingly mature now.
The Arsenal Football club website is using it at the moment www.arsenal.com and this is a very busy site indeed.
You are probably right about releasing as soon as possible and marketing a product as soon as possible. The problem is really how soon? Open-source frameworks take this to the extreme as most release as soon as the code compiles ;) And it works perfectly for that model because they don't have to commit on quality at all. But for commercial products, it's much harder to decide when to promote and actually try to sell the product. I am also involved in the buildup of a company and a similar "commodity framework" product, and this discussion if quite relevent to the problems we're facing every day. Most developers and managers choose an open-source solution simply and only because it's free. People rarely see further than that. A commercial product may be much better and on the longer run cut much more development costs, but most of the time as soon as some open-source equivalent has a similar high-level feature list and there is enough hype around it, it is chosen. So to make a commercial product attractive, a functional, somewhat useful version can't be enough. It has to give a sense of stability and confort to potential customers, it has to be worth the money. It may be that RemoteApps went to far at perfecting their framework before promoting it. But it may be also that decision makers, especially in "the current economic climat", are more concerned about monthly budgeting issues than a long term technological strategy.
So, to put in another cliche, I think it should be more "release as soon as possible, but not sooner".
"RemoteApps failed because of the inability to recognise the developer as its customer until it was too late.
Building up a community of developers over time from 1999 as J2EE adoption grew would have given RemoteApps a better chance. Yes, we started in 1999 but you might only have heard about us in 2002! In that time open source projects took the limelight, no one knew RemoteApps even existed and RemoteApps wasn't available to satisfy the developer with instant access to try it out. You had to sign up as a partner to get your hands on the product."
After I read this, at least I can say, that you chose a good name for your company: RemoteApps!
Open source vs commercial software is a big discussion. Personally, I think that there is a market for commercial software even if there are open source equivalents. Excellent customer service, good documentation/education and having a damn good product helps.
Interesting point, but I don't agree with what it implies (that commercial software delivers on these points). Look at JBoss (www.jboss.org). It tries to proves that a professional open source vendor can outclass commercial ones on all the points you make. They have a damn good award winning product, their trainings are everywhere in the world and they offer support from the core developers.
If JBoss proves the model to be viable they could really invert the dynamics of the software world.
That has been one of the very good discussions on TSS! I really enjoy it.
I think we need a new commercial model for software development.
We have been paying for closed source proprietary software for too long. The problem with closed software is that we, the clients, have too little control over the direction it is going in. We can get into license lock ups and pay for 10 new features, when we need only one of them.
Open source is traditionally associated with free software, but it doesn't have to be the case. Why not pay for open source development and get the best of both worlds?
Actually I want to first suggest a commercial model and then give the rationale for it.
Lets say we have an open source project going. The developers compile the requests for new features and see that feature A is in high demand. They open a business case, set price for the feature and the interested clients can deposit a sum of money for the development of the feature. As long as the feature has not entered production, the clients can withdraw the deposited sum. For period of time, say two weeks, the developers do not disclose the accumulated sum. If the feature is really in high demand, they will get major part of the interested clients to deposit money and hopefully receive more than the set price. If the accumulated sum does not reach the set price, they publish the current status of the business case the amount of accumulated money. Thus the clients will have clear understanding of where things are staying. The really interested will deposit more, others will have the freedom to withdraw. The success criteria can be changed and so on.
Once the accumulated sum reaches or surpasses the price the feature enters production and the deposits cannot be withdrawn, success criteria cannot be changed. All the source code is of course released as open source, preferably fully open sourced license as LGPL. Thus once the feature is completed the clients have complete freedom of how to use it.
I think such a commercial model can be a good solution for small to mid-size applications and frameworks.
I agree that we already have too many MVC frameworks and OR mapping tools. I may be wrong, but in any case the clients/users should be the ones to tell, and if they tell by paying (or at least depositing) you really know that they need it.
From the other side I think that companies like Microsoft are trying to milk the same old cow way too much. Companies and people have payed them enough to build several OS-es and Office packages, but they are still trying to sell us the same thing stacked with features we do not need.
There must be a way to do federated development. It will cut down expenses and will free precious talent for other areas that need them.
Good examples that go in that direction are JBoss and Caucho's Resin.
The creators will prevail
I worked with RemoteApps (the company and the product), and I can appreciate what they were up against. As I understand the history of Xyrian, the product evolved alongside the J2EE specification and other Open Source projects. Hence the comparisons were made between RemoteApps Xyrian and either the J2EE spec or (say) Struts. For example:
- RemoteApps Data Objects ended up being compared against EJB Entity Beans, since both provide a pool of data objects.
- Xyrian's programming model was compared to Struts.
I believe the only way to avoid these conflicts would be for framework companies to:
- actively participate in the JCP, attempting to promote convergence with their product.
- embrace and extent Open Source code, giving back to the community where possible.
Of course, I'm a techie, I don't know if that'll make money ;)
Yes the product was developed originally as a result of working on development projects using Servlets and realising the gap between what Servlets gave you and what your need was vast. Bear in mind this was pre-J2EE. This gap still exists today and is something that Struts and others have started to fill.
We always endeavoured to replace functionality with standards as they appeared. RemoteApp Data Objects (RDOs) were built in 1998 and today JDO is more like what they are than Entity Beans. We had plans to replace with JDO but JDO is only really starting to be viable.
RemoteApps programming model and Struts are very similar. The MVC architecture and patterns such as Command pattern providing the similarities.
From a technical point of view it is always very difficult designing your architecture and approach to services for frameworks.
The RDOs were developed because we wanted to be able to offer content management of a database without having to create SQL statements and the like. We also wanted it to be simple and building a Java bean is pretty straightforward. If you remember we had a web app called Team view that built forms and content management dynamically from the RDO Java Beans meta data.
Team view is a great tool but only works if you have a standard data API to feed off. So if you built Team View from scratch today, what would you use as the underlying API? EJB Entitiy Beans, JDO, JDBC or some open source API. Trying all would mean you are attempting too much and everyone has different opinions on each of the other APIs.
To be honest, the hardest thing about designing a framework is that you have to make choices and some compromises. Not everyone likes your choices or understands why you made the choices.
I think more needs to be done to standardise the APIs in Java as a whole. There are too many ways of doing the same thing which increases complexity and makes it hard to produce ready made code that people can use within their chosen architecture.
This, I think, points at the problem related to saturating the market with the plumbing-related solutions. Everywhere one looks nowadays, one sees those plumbing frameworks tripping over each other -- Struts, Turbine, Jetspeed, Velocity, yadda yadda yadda. Enough already!
What we need is more concentrated efforts in the direction of solving business problems. We need frameworks that make it easier to address the business solutions. Who cares if those solutions use XML or objects or SQL, or any mix of those. Who cares if those run on WebLogic or WebSphere or JBoss etc. The underlying implementation (i.e. the plumbing) should really be a non-issue.
>At what level of abstraction does a framework become too
>cumbersome to be useful?
I would say at a very low level. The lower the level, the less useful a framework is. Take for example Swing's Action framework: yes, it appears to be seductively powerfull, but in reality it amounts to the 'six one way, half dozen the other'. It's because this framework is a low level plumbing solution. I can just as easily throw in an anonymous inner class that will on the fly accomplish the same functionality as the much more elaborate swing.javax.AbstractAction thingy.
From this we see that a lot of effort is being wasted on providing such fancy low level frameworks. Wouldn't it be better if we could harness all that talent to build solutions that would address the real business needs? Let's face it -- businesses don't really care about the plumbing. And, why should they -- plumbing is a commodity, after all.
It's high time we wake up to this fact, and stop this perpetuum mobile in which engineers take over the whole process and deliver solutions for other engineers. Yeah, it's cool, it's sexy for them to play that game, but in the process, business people and business issues get to be severly shortchanged.
You are right, there are lots of frameworks and people need to focus on solving business problems.
The bit I am most proud of in Xyrian was the content management tool. It would be up and running quickly and allow teams of people to add content to their website with a full review process. It involved hardly any programming to customise and our sales people could do it too.
However, we always had to sell to people that wanted to know what the underyling architecture was. Customers cared which servers it ran on. They cared whether we used XML or properties files. They wanted it to fit their choice of technologies.
The number of permutations of all the underlying J2EE APIs, servers, databases, browsers and the like make it very difficult to provide standard Applications that fit to peoples chosen architecture. We went to great lengths just to support the different versions of the J2EE servers available. The next customer invariably wanted a different server!
However, we always had to sell to people that wanted to
>know what the underyling architecture was. Customers cared
>which servers it ran on. They cared whether we used XML or
>properties files. They wanted it to fit their choice of
But if your solution is technology neutral, why should they care? The underlying servers shouldn't matter, right? It's as if they wanted to know which keyboards have you been using to develop your framework. The keyboards you used to develop it are irrelevant. They are spurious to the quality of your framework. Although, in all fairness, one could argue that the types and the make of a keyboard makes a difference when it comes to the quality of work, in the final analysis no one really cares. Same should be with the underlying deployment servers.
If your framework offers some sort of an object layer that delivers as expected, who cares if those objects manage to deliver the desired information/behavior thanks to employing XML, SQL, flat files, groupware, email, or who knows what else?
Sadly, I think that today's typical customer is the root of the problem, because, as you say, they all seem bent on insisting on the most irrelevant and stupid questions. They drag this whole thing to the gutter, and it is they who need to be seriously re-educated.
>The number of permutations of all the underlying J2EE
>APIs, servers, databases, browsers and the like make it
>very difficult to provide standard Applications that fit
>to peoples chosen architecture. We went to great lengths >just to support the different versions of the J2EE servers
>available. The next customer invariably wanted a different
See, that's my point. Unbelievable ignorance! These people have absolutely no idea what they are talking about. We really must put additional pressure on highly visible vendors (such as IBM, Sun, Oracle, etc.) to go out and educate the market. Otherwise, we'll be stuck in this holding pattern until everyone dies of starvation.
I agree with you that there is probably an overabundance of plumbing frameworks. However, I think this is the case for a reason. As you said, plumbing is a commodity. This is possible because one company's plumbing needs will be nearly identical to another's plumbing needs. Most servlet apps follow the "Model 2" approach, and Struts provides a framework for doing so. This takes this burden away from developers.
Business needs, compared to plumbing needs, are not nearly as universal. I have seen this first hand with several off-the-self "business solutions". Our e-commerce solution saddled us with way to much garbage. Some of the parts we didn't need. Some of the parts were difficult to use. Some made assumptions about business rules that did not jive with our rules.
We also bought an HR solution. One of its built in process wordflows did not match ours at all. I kid you not - the "consultants" for this product asked if we could change our process. Hello!!!!
What I'm trying to say is software plumbing is like house plumbing - it is a standard. You're JSP templating solution will probably be almost exactly like mine. Your OR mapping needs are probably a whole lot like mine. Your plumbing pipes are probably the same grade/size as mine. Business software varies wildly, because so do rules. I don't care how flexible the framework is, it will never be flexible enough - typically leading to developers writing their own code for part of the framework, which defeats the purpose of the framework. And you can impose the structure a plumbing framework on a project at lot more easily than you can a business framework.
It is great idea in theory, but incredibly difficult to put into practice.
Ryan - I totally agree. I'm always wary of a vendor promising a "business solution". Usually, a "solution" equates to a chunk of software that requires the vendor's consultants to provide hundred of hours of work to actually arrive at a solution - and you're lucky if you don't have to change your ways to fit the product.
We had an order management "solution" brought in on my previous project, and one of the integration nightmares with this product was that you had to choose all or nothing with it. It was very difficult to build your own UI on it, let alone customize the UI that they provided you with. And forget customizing things like the user context in the application. I think that speaks to the value of plumbing frameworks, particularly open-source ones. Typically, the frameworks are more like engines - you can customize them easily, and you can easily slap your own UI on top of them too. Generally, I see a better chance of success in integrating several plumbing frameworks together to solve a business problem than purchasing one of these "business frameworks" to solve the problem.
I don't think it's wrong at all for all of the open-source frameworks to exist and for them to continue to grow. It sounds like you're implying that the J2EE community should have a set of richer API's in place already. That might be nice, but since it hasn't happened (and some may argue it shouldn't happen), it is good that these open-source (and commercial) frameworks exist. Good developers can benefit from at least a basic understanding of multiple frameworks - it shows you how the framework designers attempt to solve the same problems, and you can learn a great deal from this.
To me, a big difference between J2EE and Microsoft's strategy is that MS eliminates the need to think in some regards - MS gives you a toolset, and you use it, you don't question it, and you start building. With J2EE, you have a wide array of choices, and you need some people that understand those choices and can determine which choice best suits your needs. And there are the obvious pros and cons to both approaches. Choice introduces complexity, but choice can yield a better result, which translates to the best solution for the business problems at hand. If you don't want to deal with choice, then you should consider .NET, as that arguably eliminates some complexity and allows you to address the business problems more quickly. But of course, you're relying on .NET to provide everything you need - if you find that a certain part of the framework puts you in a bind, you're going to have a much tougher time getting out of that bind.
Regarding the value of frameworks, I see the value in MVC webapp frameworks and data access frameworks in particular. I think the web and data tiers seem to be better candidates for frameworks, as there tends to be a lot more generic plumbing on those tiers. My personal experience on the web tier has taken me from a custom XSLT framework to Struts to WebWork + Sitemesh (with brief visits of other webapp frameworks out there), so I see a lot of value in the choice that the variety of J2EE frameworks offer.
It sounds like you're implying that the J2EE community
>should have a set of richer API's in place already.
On the contrary, I'd like to see J2EE evolve into a platform that's going to offer a much more depauperated set of APIs. In other words, I'd like to see J2EE become idiotically simplified. Something like driving a car -- we all know that today's automobile is a mind-numbingly complicated piece of machinery, yet anyone, even the most mechanically challenged and nontechnical person can drive it. Same should be with J2EE -- anyone who has some minimal set of qualifications should be able to use it 'out of the box'. There shouldn't be this need to turn it into a career. Only then will it be a real success. Right now, I'm sorry to say, it's merely a half-baked, ho-hum product (nothing to write home about).
>Good developers can benefit from at least a basic
>understanding of multiple frameworks - it shows you how
>the framework designers attempt to solve the same
>problems, and you can learn a great deal from this.
I agree with you. By examining frameworks such as Struts, Turbine, Jetspeed and such, developers can gain priceless insight into how *not* to design and develop applications (since these frameworks embody some of the worst imaginable practices related to software development).
>Regarding the value of frameworks, I see the value in MVC
>webapp frameworks and data access frameworks in particular.
Yes, but isn't it about time we stop reinventing the wheel? MVC framework has been around for what, more than 30 years now? I mean, for crying out loud, in 30 years one would hope that we should've managed to come to a standardized implementation and end this whole charade! But no, all one sees nowadays is yet another MVC framework flogging the bandwidth. How stupid do we have to be to keep buying into such repeated lame attempts?
>so I see a lot of value in the choice that the variety of
>J2EE frameworks offer.
What choice, what variety? It's all the same old tired rehashed design pattern. What are you talking about?
frameworks such as Struts, Turbine,
> Jetspeed and such, developers can
> gain priceless insight into how
> *not* to design and develop
Could you please argument your statements.
> What choice, what variety? It's all
> the same old tired rehashed design
> pattern. What are you talking about?
What are you?
I agree with you. By examining frameworks such as Struts,
>Turbine, Jetspeed and such, developers can gain priceless
>insight into how *not* to design and develop applications
>(since these frameworks embody some of the worst
>imaginable practices related to software development).
A nice provocative statement ;) You would indeed do the community a service by elaborating a bit. It is true that developers take many of those frameworks as the granted solution to their problems with very little thoughtfullness. And a little thoughtfullness never hurts. So show us some.
>Yes, but isn't it about time we stop reinventing the
>wheel? MVC framework has been around for what, more than
>30 years now? I mean, for crying out loud, in 30 years
>one would hope that we should've managed to come to a
>standardized implementation and end this whole charade!
>But no, all one sees nowadays is yet another MVC
>framework flogging the bandwidth. How stupid do we have
>to be to keep buying into such repeated lame attempts?
I'm afraid to disappoint you, but you may well see thousands of more MVC implementations in the next 30 years as well. It's a pattern and that's what patterns are for, to get reimplemented thousands of times and never in exactly the same way. Granted, the fact that the term has become marketing hype among developers is sad, but this is another problem.
However, I somewhat agree with your frustration and criticism that too many companies focus their efforts on tools and that the "choices" and "variety" are quite superficial. But there is a profound and well-known reason for that: we simply haven't solved our own "software business" problem yet. The business of software is to provide tools to other businesses with ever changing requirements and variation. To adapt and quickly deliver, we need good tools ourselves and we are still trying to get that right...
I don't think there is any problem with having multiple frameworks in J2EE, as long as there is a standard way of coding to the frameworks. Hopefully, having standard JSP tag libraries will help us in this. Then, I can call some generic <buildURL> tag that is implemented differently in each framework to interact with the navigational requirements of each framework. Then, let the vendors and the OS community compete on implementation and integration with higher-level functionality (and toolsets).
I don't think there is any problem with having multiple
>frameworks in J2EE, as long as there is a standard way of
>coding to the frameworks.
Multiple or single, I really couldn't care less, just give me quality!
By quality I mean something that's easy to use, doesn't require me to turn it into a career choice, is not taxing on my short and long term memory, shields me from the technology (underlying as well as upcoming), and delivers as promised.
The losers will tell me that such thing is not possible, but at this point, I don't want to talk to no losers. I'm getting fed up with them.
A nice provocative statement ;) You would indeed do the
>community a service by elaborating a bit. It is true that
>developers take many of those frameworks as the granted
>solution to their problems with very little
>thoughtfullness. And a little thoughtfullness never hurts.
>So show us some.
How does one start? Quite frankly, I thought that it's so obvious why today's frameworks suck that no one would need an explanation. In a way, if you can't see what's wrong with those products, and if you think that they are just fine, you're beyond help. Still, one could actually write a book on all those evil things that come with those products.
Not to belabor the point, though, I'll just quickly mention one aspect, and then you'll have some material to ask more questions about:
Take Jetspeed, for example. It's a product that promises to deliver power and simplicity to developers who must build portals. If you download this product, and start playing with it, you will soon realize that you'll need to turn it into a full blown career if you want to get anywhere. Now, how's that for a promise to simplify and empower?
To begin with, the product is so heavily fractured that, in order to make it even start in its most vanilla mode, you'd need to visit and touch up countless xml configuration files. Of course, all these files are merrily scattered accross a huge monstrous directory structure that Jetspeed comes with. A person with a very sick, very delirious mind must have thought up these schemes and decided to enforce them on the development community at large.
Did it ever occur to Jetspeed designers to provide a nice unified view of all the configuration information in one easy to locate file? Nah, that would be too easy, right? But even if they had provided for a central configuration repository, they still wouldn't get passing marks, because why do I ever have to look at those ugly xml tags? What's the reason for having to ever face them? Why couldn't they supply a simple jsp that will present the configuration data to me, allow me to modify it, and disseminate it behind the scenes (persistence)?
The reason they never bothered to make their product deliver is because it was built by the geeks for other geeks. It's basically a product for the so-called gearheads. For people who like to talk shop. Well, I, and most other typical developers, don't have the time nor any interest to talk shop. We just want to deliver results. So, if I need to build a portal, I want to do it in the easiest possible way, without having to learn and memorize much. A product that can deliver this functionality is going to eventually win. But let me assure, Jetspeed ain't gonna be it. Nor will Struts ever be it (regardless of the present popularity, which will wane). All the plumbing frameworks I've looked into so far are criminally bad, showing no respect for the developers' time and effort.
Most software developers have a tendency to start building software product even before a single line of design had been specified. That's right down criminal, and I think such people should be arrested and their license to build software permanently revoked, if ever caught doing that.
However, that's a lesser of the two evils. The biggest evil is that almost all developers who even bother with the design, start designing before a single line of the so-called "Quality Before Design" activity had been specified. If we don't specify the definition of quality before we start designing, we will be compelled to design crap. And that's what's happening in 99% of the projects today.
Ask yourself honestly: when was the last time you saw a software project being explicitely concerned about the quality a finished product is supposed to deliver? Instead of quality, people talk about functional specifications, which don't mean a thing unless tied with supporting the end-users' goals.
Alex, you seem pretty fed up with today's crop of frameworks for a number of reasons. If I understand it, one of your biggest gripes seems to be that the frameworks that are out there don't protect you from changing technologies; instead, they suck you in and force you to become dependent on a particular technology, perhaps even more so than if you wrote your app without using the framework.
I tend to agree with you on these points...the frameworks take on a life of their own and don't help solve the real problem, which is building applications. Take a look at Structs and Nodes Devleopment (SAND) from http://epinova.com
. SAND is a methodology for building technology-agnostic enterprise applications. You write the application; you never have to worry about the underlying technology. There's an open-source implementation called "SandBoss" underway at Sourceforge; there's more info on the Epinova site.
I used an architecture similar to SAND on a previous project (a trading engine), and quite frankly it kicked ass. We didn't have to worry about writing EJBs or keeping our XML schemas up-to-date or anything; it just happened, thanks to the framework we were on. We were able to concentrate on the application, not the underlying technology. It saved us many man-years of development time; the architecture works.
SAND is even better IMHO (disclaimer: I'm a SandBoss developer). Check it out, and if you think it's broken feel free to tell us. We'll fix it, because we're sick of bad frameworks too.
>SAND is even better IMHO (disclaimer: I'm a SandBoss
>developer). Check it out, and if you think it's broken
>feel free to tell us. We'll fix it, because we're sick of
>bad frameworks too.
Thanks for the pointer. I'll definitelly have a look.
As you could probably infer from my posts, my problem is not so much the technology lock-in, as it is overall lack of quality. If your product delivers quality, I'll definitelly try to acquire it.
Alex B -
I'm really enjoying your comments on this topic. I'd love to see you tear apart our web application framework:
Here's the twist: It spans client and server, so you get the server-side benefits of e.g. Struts but also rich client GUI and performance in standard web browsers.
We don't claim that it does everything, but it certainly saves a ~lot~ of development resources.
Apologies to all for the commercial plug, but I didn't see any "reply direct" option.
Alex B -
>I'm really enjoying your comments on this topic. I'd love
>to see you tear apart our web application framework:
Thanks for the link to your interesting product. I've downloaded it and spent some time configuring it, playing with it, and perusing the accompanying documentation. Here is my verdict, based on the first impressions:
SmartClient is a product that promises a lot. I must say that I got really excited as I was learning about it. From the marketing point, you have indentified the true (and a very pressing) need in today's software development arena. It is undeniably true that document-centric end user interface (meaning, HTML-based) has been dumbing down business applications in the past 6 - 7 years. Time for a drastic change had finally arrived. Here at my company, we simply can't wait for a breakthrough that will take us away from the dumb stateless request/response based HTML-centric user interfaces.
However, it saddens me to say that your product simply doesn't deliver. After building up a nice level of pleasant anticipation, SmartClient let me down in a very rough and abrasive manner. The deeper I was digging into it, the more uneasy I started feeling about the product.
In the final analysis seems like you guys just weren't able to get your act together, and to follow through on the wonderfull promise. I frankly failed to see how can your product save me time and hassle and lower the barried to entry and flatten the learning curve required for my developers to enter this arena.
Sorry to be so negative, but you've invited me to "tear apart" your product. You've got my honest opinion.
If you'd like me to elaborate on the reasons why I think SmartClient is (unfortunately) a loser product, please let me know, otherwise I'll leave it at this level of general observation.
Thanks again for the marvelous opportunity to learn about your exciting product.
Jeff - from your website: "...Insulating application developers from web-browser differences, DHTML idiosyncracies..." - this made me have a closer look. This line is a promise from you to me, that I have a lot less to do in the future.
Then I dared opening the page in Opera. Did not work (I guess it's kind of difficult to support even the main browsers for that kind of thing. Again: Different object models, different cancers)
Then I thought about a functional test: Forwarding an email never arrived. That is kind of ok. But honestly, the demo would be just half that impressive if there would actually be some http traffic going on between client and server.
Then I thought, I never liked websites disabling the browser controls like Back/Fwd. This usually indicates some flunky session state handling and I would not like to deal with this kind of product/framework.
At this point, I stopped, because this product is just not what I need. Where I work, supporting pretty much every browser and different devices is very important. Unlike MSN treating Opera like shit, we feel every browser should get the best HTML/CSS it can handle. This is one of the aspects, that defines "quality" for us.
To me it appears, that what was promised for smartclient is not kept. The quality advertised is not there. It's not that I am insulated from web-browser differences. It more seems, that when I use this product, I am insulated from different web-browsers.
So, I believe, that smartclient customers probably have a different mindset than I do as well as a different quality definition. And they get what they want: A wicked GUI for a few browsers (all my uncles use IE, but my nephew is on Opera:).
Please correct me if I'm wrong
Then I dared opening the page in Opera. Did not work (I
> guess it's kind of difficult to support even the main
> browsers for that kind of thing. Again: Different object
> models, different cancers)
Bob, I hate to be the one to tell you this, but Opera isn't a "main browser".
Internet Explorer 4+, Netscape 4+, and Mozilla derivatives conservatively represent more than 98% of all web browsers in use. And that's looking at the broader consumer Internet. In business use, Opera's share is probably under 0.1%, and I challenge you to find a system that has ~only~ Opera installed and none of these other browsers.
I'm not aware of any large organization that has standardized on Opera. You may be surprised how many big companies have standardized on Netscape 4 and continue to use it today. Philips and Boeing are two immediate examples from our experience.
Don't get me wrong, I think Opera is decent browser for viewing HTML. But they don't support the full range of W3C standards, and probably never will because their focus has shifted to minimal browsers on handheld devices.
0.1% does not a platform make. We don't support the Amiga either.
> Then I thought about a functional test: Forwarding an
> email never arrived. That is kind of ok. But honestly,
> the demo would be just half that impressive if there
> would actually be some http traffic going on between
> client and server.
Yes!!! We did our job so well that you didn't even notice. Thank you. :o)
Bob, every time you open a new folder or message in that demo, it is loaded on demand from the server, transparently, via HTTP. You didn't notice because our system doesn't need to reload the page to do this.
Actually forwarding a message would mean mail-server integration on the back end, which we do in real deployments, but the security and administrative concerns don't justify it for this demo. The purpose here is primarily to show the UI benefits in an application that everyone understands.
We have other, much better examples to show how ISC enables live binding to server-side datasources. The Instant Data Application example on the same page (www.smartclient.com/technology/testdrive.jsp) is a much better example for demonstrating a live transactional app, with transparent HTTP communication between client and server to manipulate a datasource (specifically a SQL RDBMS) of office supply items.
I know we can't please everyone. But look, we already provide more live examples--with source code--on our website than any other framework vendor I've seen. If there are better, easier solutions out there, why don't they show running examples on their websites? Point me in the right direction.
Keep it coming. I'm still looking for a valid criticism.
"...Bob, I hate to be the one to tell you this, but Opera isn't a "main browser". ..."
"...Bob, every time you open a new folder or message in that demo, it is loaded on demand from the server, transparently, via HTTP..."
Point taken. Cool. I guess I should have been more thorough.
"...I know we can't please everyone..."
Not my nephew :)
"...How do you customize the look&feel of your components btw?..."
Switchable skins. You have control down to the property level for every attribute of every UI component instance and class, but typically you'd create a comprehensive skin that consists of:
-- a stylesheet with your customized CSS styles (for things like button borders, selection highlighting, form text styles, etc)
-- a set of customized images for the various UI bits (turndowns, drag trackers, etc)
This is all documented in our evaluation SDK, in the ISC Widgets Guide, Chapter 4 (Images and Skins), pages 69-77. The SDK also includes a couple of example skins. We have modified the web demos with a dropdown to let you select different skins, but haven't pushed that change yet.
We say on our website that we combine the best aspects of client-server applications with the best aspects of web applications. Should probably add to this "the best aspects of web SITE development", which is really where concepts like skinning for rebranding/syndication are coming from.
Hope this helps,
In the final analysis seems like you guys just weren't
> able to get your act together, and to follow through on
> the wonderfull promise. I frankly failed to see how can
> your product save me time and hassle and lower the
> barried to entry and flatten the learning curve required
> for my developers to enter this arena.
> Sorry to be so negative, but you've invited me to "tear
> apart" your product. You've got my honest opinion.
> If you'd like me to elaborate on the reasons why I think
> SmartClient is (unfortunately) a loser product, please
> let me know, otherwise I'll leave it at this level of
> general observation.
Alex - Please do elaborate, either here or privately. This reply isn't up to your usual standard of detail.
Our product isn't static. It's a moving target, driven by the needs of our clients, customers, and experts like yourself. If we don't have our act together for your needs, we can get it together. Don't just tell me we suck; tell me why.
Some ways that the current rev of Isomorphic SmartClient saves time and lowers the barrier are by:
-- Providing a high-level declarative framework for a common class of data-driven applications (the IDA framework)
-- Single-sourcing data validation and user authorization rules to apply on both client and server.
My guess is your biggest gripe will be with the narrowly bound focus of the IDA framework. The current documentation gloms everything together--data binding, component layout, authorization, etc. And we don't show how to do some common things like datasource joins declaratively.
But for a common class of datasource-driven applications, the IDA is remarkably effective. Look at the source code for the IDA example on our website (click the 'XML Source') button, and please tell me if you know of any other framework that lets you work at this high a level. Yes, you sacrifice flexibility for speed. Like I said, we don't claim to meet everyone's needs today. But we have radically accelerated our customers, and we continue to generalize.
Developer productivity is just one of three areas addressed by our system (albeit the one that this audience probably values most!). We also focus on bringing back the end-user productivity and application scalability that current web app architectures have set back more than a decade. We're trying to balance these three goals as we advance with each release.
I ask for your feedback because you've had one of the clearest voices in this discussion, and your frustrations closely parallel the development issues that drive us. Your criticism is always welcome.
Bring it on.
Alex - Please do elaborate, either here or privately. This
>reply isn't up to your usual standard of detail.
Like I've mentioned earlier, I like striking iron while it's hot. The lively discussion that was raging here in the past week or so provided me with an ideal opportunity to vent some of my frustrations. However, in the last two days I sense that the interest in this subject started to dwindle, and I didn't want to flog a dead horse. But, if I assume for a moment that the interest is still there, I can get myself into the mood and keep going.
>Our product isn't static. It's a moving target, driven by >the needs of our clients, customers, and experts like
>yourself. If we don't have our act together for your
>needs, we can get it together. Don't just tell me we suck;
>tell me why.
That's the best possible attitude! Kudos on that.
OK, I'll attempt here to explain several issues I'm having with your product (keep in mind that I'm still learning it, inbetween the more pressing concerns I have to deal with in my day job routine).
Right now I'm looking at about 15 developers on my team who need to build a whole wack of web-based mission critical applications. Not only that, they'll need to maintain those, while also maintaining a huge pile of legacy code. Because it will take too long for these people to truly master the proper Model 2 approach to building web apps, I'm desperately searching for some sort of a framework that will make their jobs easier. I've even singlehandedly developed a custom framework that allows them to declare their intentions in an XML Schema document, and the framework then reads the schema and generates the entire application (the persistense, the business objects, the presentation). The problem with that framework is that it requires them to master XML Schema, which is a big hurdle. Plus, it falls short when it comes to declaring the workflow. Consequently, I wouldn't mind stumbling accross a better framework which would make my life easier. That's the reason I got intrigued and decided to take a closer look at your product.
Now, let's examine my position in this situation -- I am a software developer who needs to build solid web-based applications. Your business was put in place to specifically target customers who have a profile similar to mine. If we review the reasons why I'm considering your product, they boil to the following:
1. I would like to avoid having to learn yet another language/protocol/platform
2. I would like to avoid having to memorize elaborate, intricate details pertaining to the configuration and implementation issues
3. I would like to arrive at a standardized way of building applications
The above reasons summarize some of my main *goals*. If there is a product out there that can help me achieve these goals, we may have a match, and you may get yourself a customer.
Before I even considered your product, I had a good look at what's out there in the mainstream market. What I found didn't satisfy my criteria. In other words, I didn't feel that learning the JSP specs, or learning the alternative mainstream specs (Velocity, Turbine, etc.) was worth the effort. Now, don't get me wrong, I've had to learn them real good, but I'm talking here about the developers I'm responsible for. It was just too much trouble for them. There's gotta be a better product out there.
If I compare your product to my needs, I find it falling short in many respects. To begin with, your product does not alleviate the need to learn a new platform; your product is another platform already.
Next, your product doesn't alleviate the need to learn and memorize extremely elaborate and intricate details concerning even very simple things such as getting it up and running. The fact that a user is expected to go through all that song and dance just to be able to accomplish the simplest concievable vanilla behavior cannot be good under any circumstances.
Please indulge me, for a moment, while I explain this: myself, being your prospective customer, I have certain goals. You, being my prospective vendor, would like to acquire me as a customer and to retain me. In order to do that, you'd need to serve my needs. And my needs are expressed as my goals (listed above). If you can fulfill those, that will cause me to perceive your product as possessing *quality*, and that will compell me to purchase it.
So I, as your prospective customer, downloaded your product, and started evaluating it. Immediatelly, I've encountered major problems which hurt like a poke in the eye: the first thing I learn about your product is that I must memorize that there are a handfull of files merrily scattered all over the place, being given all kinds of difficult-to-remember names. For example:
there's a file /isomorphic/applicaitonName/applicationName.jsp
then, there's a file /isomorphic/datasources/dataSourceName.ds.xml
next, there a file /isomorpphic/apps/applicationName.app.xml
and so on. And that's just a tip of the iceberg.
To make things worse, the content of these files is very convoluted and indecipherable. I realized that I must learn how to link the bootstrap file with the Application Descriptor file and with the DataSource Descriptor file. Of course, there is also server.properties file somewhere in this freaking maze and so on. And we've only just scratched the surface.
My question to you, Jeff: what's with all this mess? Is this what you call a high quality product? Why should I, a potential paying customer, be forced to ever know about this shit? Believe me, this fiasco is enough to irrevocably drive me away from your product. No way am I going to pay big bucks to be abused and denigrated like that!
Of course, being a seasoned software developer myself, I know that your product needs all these files in order to *implement* the functionality we all crave so much. However, pay attention that I emphasized 'implement'. Me, as your end-user, should never ever be made aware of how have you guys implemented certain functionality (same as me, as a driver, need not be aware of how is the steering mechanism implemented in my car). Because I'm only interested in using that functionality, you should only expose the bare minumum needed for it to work, and leave the rest to my imagination (which would be equivalent to giving me a steering wheel as a simple means of steering left or right).
This is the grievance in general that I have with almost all software products -- too much of the internal implementation bleeds through into the user interface. Why do I, as an end-user, care that you chose to store the server configuration information inside /isomorphicConfig folder in a server.properties file? That is the internal, confidential information your architects, designers and developers made while building this product, and it should never bleed through into your interface/documentation. I know that you must store it somewhere, but I need not know where. It's just unnecessary garbage and noise that adds to the inadequacy of the product.
Same goes for the rest of the internal structure exposed in your documentation -- it is absolutelly appalling to me to see that I'm expected to memorize all those idiotic locations and file names. Especially since I know that it's totally not necessary. What's even more insulting is that I know for a fact (after leading development teams for many years) that you are forcing me to go through that mental gymnastics in order to make the life for your developers easier. That decision in particular pisses me off. I know that you could've made it so that your software product worries about the location and the names of those files, but no, you've decided to push that responsibility on me, the unsuspecting customer. Why should you place additional demands on your developers, when customers are suckers and you can therefore saddle them with this monkey business?!?
It is the above attitude that insures you'll only get very stupid customers (one can only hope here that they will be in the minority, although...) Most people, if they're paying for something, want to get some service, and not to be made work even harder than before they paid.
I, as a customer, as an end-user, have three categories of goals:
1. Personal goals
2. Professional goals
3. Corporate (or group) goals
On a personal level, I demand to be treated with respect. Your product failed to treat me with respect, assumed that I'm stupid, and tried to trick me into working very hard on its behalf. This is a big No-No, and for that alone I give your product a big F mark (F for failed).
Also on a personal level, I prefer never to be put in the situation where I feel inadequate. No one likes to feel inadequate, and a product that makes you feel that way is going to be avoided like a plague. Which is what I'm compelled to do with your product, because from the very get-go it forced me to feel very inadequate (too many things to remember, repeated attempts in different direction yield the same miserable results, and so on).
You and your team need to work real hard on addressing these issues. I'm serious when I tell you that you cannot afford to treat your potential, as well as your existing customers like dirt (unless, of course, you're Microsoft or IBM). We're all human and we have feelings that are easily hurt, and if a software product insists on treating us like we're idiots, we're definitelly not gonna like it. I can guarantee you that.
I could go on explaining how your product failed to fulfill my other personal, professional and corporate goals, but I think the above should suffice. Get your act straight on the above exposed grievances, and you'll get a long way towards meeting the market demand. And then you'll be able to finally deliver quality, for which you'll be richly rewarded.
There you have it -- a merciless analysis on why your product sucks. You've asked for it, and I complied. I sincerely hope this will help you build a better mousetrap.
Go Alex! I knew you had one more in you.
When I turn on the filters, you have actually nailed a number of common weaknesses that we're striving to fix. Full comments below...
> I am a software developer who needs to build solid web-based
> applications. Your business was put in place to specifically
> target customers who have a profile similar to mine.
Actually, our business was put in place for the same reason as yours: We are software developers who need to build solid web-based applications.
We've been doing this for 6 years, with much success, and started to seriously generalize and productize our system--which we still use for projects with our enterprise clients like Philips--about 2 years ago. This is an important distinction from companies that form for their own sake and guess at developers' needs to build a product.
> 1. I would like to avoid having to learn yet another language/protocol/platform
That is a good goal, but what if learning that language/protocol/platform means that you can ~forget~ several others? Or put a new developer on it who only has to learn one system instead of half a dozen? Is that worth something?
The highest level of programming in Isomorphic SmartClient--the Instant Data Appplication framework--provides a single simplified XML schema for declaratively creating end-to-end web applications. I think one of your earlier posts said that you were looking for this radical simplification.
> Next, your product doesn't alleviate the need to learn and memorize
> extremely elaborate and intricate details concerning even very simple
> things such as getting it up and running.
This is really a general platform issue, though we're constantly trying to make it easier.
To get the ISC client up and running, you unzip/untar the SDK and open index.html. Done.
To get the ISC server up and running, you drop it in your container's web application directory and ~maybe~ (depending on the container) change a line in the config file to reference the correct directory. Except in the rare case of platform incompatibilities...read on....
The complexity comes in your choice of server platform. The current release of the ISC server runs in a servlet container, which means installing and configuring a JDK and servlet container. And the tradeoff for all of our choices of servlet engines, app servers, and JDKs is that they are terribly inconsistent. For example, the IBM JDK 1.4 bundles an incompatible version of the Xerces XML parser, with which I believe you've found a conflict. The Sun JDK 1.4 does not. Our bad in this case, because we don't really need to depend on a specific parser, but it wouldn't have been a problem at all if there was just one standard JDK.
These burrs, which we sand down whenever we find them, are the price of an open software market. Your alternative is Microsoft, if you value consistency more than flexibility. That's an oversimplification, but the essential choice for today's enterprise software developer. Both choices have their merits; I can't decide for you. It may be heresy to say it on TSS, but we're actually working to provide the ISC server on both J2EE ~and~ .NET servers.
> You, being my prospective vendor, would like to acquire me as a customer
> and to retain me. In order to do that, you'd need to serve my needs.
We would, yes, provided you can afford to pay for what you want. Can you?
I think your goals are ideal. ~Our~ goals are to do these things better than anyone else, and to keep doing them even better than that, so we can approach that ideal. We look to customers like yourself to always hold the brass ring out a little bit further. Will we catch it? That's up to you, but we'll keep trying as long as you're willing to pay for the improvements we give you. I can't put it more plainly than that.
> So I, as your prospective customer, downloaded your product, and started
> evaluating it. Immediatelly, I've encountered major problems which hurt
> like a poke in the eye: the first thing I learn about your product is that
> I must memorize that there are a handfull of files merrily scattered all
> over the place, being given all kinds of difficult-to-remember names. For
> there's a file /isomorphic/applicaitonName/applicationName.jsp
> then, there's a file /isomorphic/datasources/dataSourceName.ds.xml
> next, there a file /isomorpphic/apps/applicationName.app.xml
> and so on. And that's just a tip of the iceberg.
Alex, this isn't the tip of the iceberg; this ~is~ the iceberg. Those three files are all you need to work with to build an ISC application.
The actual files in the SDK are:
And the HTML read-me file for the SDK clearly documents them along with the other top-level files/directories:
default server-side directory for application (.app.js) files
(configurable via server.properties). Contains the application
file for the AppTemplate starter application.
default server-side directory for datasource (.ds.js) files and
test data (configurable via server.properties). Contains the
datasource file and test data for the AppTemplate starter application.
"bootstrap" file for the AppTemplate template application
Our hope is that, if you don't read any documentation, even the read-me file, this naming will indicate that you're looking at a Template Application that you can duplicate/modify to create your own applications.
But why ~three~ directories/files instead of just one? So you can share datasources and logic across multiple applications. More on this below.
Three files to build an application, and hey, you found them all on the first look. Is it that confusing?
But you know what--you ~are~ entirely right. You shouldn't have to deal with ~any~ files at all. And in fact, this is where ISC is going. Wizard driven application builders that automatically discover the available datasources and present the fields, operations, user types, display components, etc. for point-and-click assembly. The classic problem with such RAD tools is that they're typically far too limited. We're aiming to expand them from enabling maybe 20% of real applications to something more like 80-90%, but someone will always have a new idea that requires going under the covers and working with files and code. And then we'll figure out how to canonicalize and expose that new idea in an easier way. Is that your dream?
> Me, as your end-user, should never ever be made aware of how have you guys
> implemented certain functionality
Right on! That's what we do. All of the implementation is buried in two directories that you never have to touch (though you could, if you wanted to expand the implementation with new classes of UI components, new datasource connectors, etc). I really, really wish we could put it all in one directory, but we're limited by the way today's servlet containers work.
So you've already found everything you need. Stop digging unless you ~do~ want to know about the implementation. Maybe you're stuck in this pattern from using other systems?
> Why do I, as an end-user, care that you chose to store the server configuration
> information inside /isomorphicConfig folder in a server.properties file? That is
> the internal, confidential information your architects, designers and developers
> made while building this product, and it should never bleed through into your
You don't, unless you want a choice of platform components.
If we dictate your choices of JDK, servlet containers, drivers, and datasources, you don't have to care--ISC just works "out of the box". But if you demand to use some other JDK or app server with who-knows-what standard or customized datasources, you might need to change a line or two to tell us that because--guess what--they don't all work the same.
We ~can~ decide everything for you if you want. But I don't believe that's what you really want, or you wouldn't be on TSS.
We also could, and will, provide a simple graphical configuration tool for this. But look, have you ever worked with a sysadmin in a BIG data center? "Simple" graphical configuration tools are the bane of their existence, because they're a bitch to work into automated deployment and updating scripts. So we start with a simple text file, and add the look-how-easy interface for you later.
> it is absolutelly appalling to me to see that I'm expected to memorize all those
> idiotic locations and file names
> I know that you could've made it so that your software product worries about the
> location and the names of those files
You aren't, and it does.
You seem to be stuck in the config file again, which you don't need to touch unless you ~want~ to customize locations and names.
Yes, you have three locations by default:
1) a directory in which to put your application bootstrap file
2) the apps/ directory for application logic files, which is a separate directory so you can easily share logic across multiple applications
3) the datasources/ directory for application datasource definitions, which is a separate directory so you can easily share datasources across multiple applications
These could all be the same directory by default, but we found that most customers do want to deploy multiple applications on the same server and share logic and datasources across these applications. How about you?
Like I said early on, we don't claim to do everything. And we're continuously improving.
Your points, though extreme, do have a kernel of truth. They will help us build a better mousetrap.
In the meantime we have to build on what we have, and I have to ask you: What have you found that works better? An ideal is great, but you need to get your apps developed today, yes?
Isomorphic Software - www.isomorphic.com
Your critisicm is reasonable and valid. Those are the dynamics of open-source software that is not solely based on immitation (where the architecture is already done in the "incorporated world"). Ease of use and marketability is the last thing an open-source project, especially in its infancy, worries about. Quality is also taken for granted in those projects because it is assumed that problems will eventually (and quickly at that) get fixed by the community. The design phase is indeed often missing. The architecture ends up being good or bad depending on the skills of the project's initator. Etc.
However, what you are saying doesn't really invalidate the "software pratices" based on those frameworks, it merely shows some immaturity from a real product's perspective. This is probably not the case with all such projects.
But on the other hand, would you pay 3-5000$ for RemoteApps' product which apperantly allowed even the sales people to build a portal easily? Which apprently put a lot of effort into quality and perfection before trying to seriously market the product... You could write to the liquidator and ask for a license maybe. I'm serious. You are essentially complaining about open-source software (Jetspeed, Struts) that is criminally bad and does not deliver industrial quality and ease of use. Well, you can get quality but you will need to pay for it ;) Convince your managers that free tools don't necessarily mean better development and lower costs... it's hard, believe me.
But on the other hand, would you pay 3-5000$ for
>RemoteApps' product which apperantly allowed even the
>sales people to build a portal easily?
You bet I would! You may find this hard to believe, but I would gladly pay even $50,000.00 for a quality product. I'd have no problems with that. Because, $50K is a typical developer's annual salary, and for that kind of money today you're most likely to get a very crappy, crabby crybaby of a developer.
But, you see the problem is, <Seinfeld_quote>show me the quality product! Where is the quality product? I want to see the quality product!</Seinfeld_quote>
>You could write to the liquidator and ask for a license
>maybe. I'm serious.
You may have a point there. However, I'm extremely skeptical. I would be prepared to bet large sums of money that RemoteApps' product is most likely a low quality one. I don't know, just a hunch (don't have the time now to examine this hunch).
>You are essentially complaining about open-source software
>(Jetspeed, Struts) that is criminally bad and does not
>deliver industrial quality and ease of use.
You are correct, but only partially, because I am also complaining about the closed-source software products (at least the ones I was misfortunate to use). Such products (e.g. PeopleSoft, Siebel, SAP, etc.) are also criminaly bad, irrespective of the enormous price tag attached to them.
>Well, you can get quality but you will need to pay for
Please show me the way! Show me the quality product, no matter what price tag. Like I said, almost any price tag could easily be justified by seeing the quality product replace lousy developers. I can assure you that such a product would pay for itself in a matter of months.
>Convince your managers that free tools don't necessarily
>mean better development and lower costs... it's hard,
On the contrary. My managers have sound business skills and they know that free products are most likely crap, so they are highly skeptical of them. It would be hard to convince them to abandon expensive products in favor of free ones.
>However, what you are saying doesn't really invalidate
>the "software pratices" based on those frameworks, it
>merely shows some immaturity from a real product's
Hmm, I'm not sure I agree. When we talk about "software practices", the prime directive, in my mind, is the 'separation of concerns' practice. The developers of the frameworks in vogue today chose to totally ignore this most important dictum (that is, if they're even remotely aware of that dictum, which I honestly doubt they are). That rendered their products totally negligible.
Unfortunatelly, many young, impressionable developers are downloading these famous frameworks, taking a peek to see how are they being put together, and learning the worst possible habits and practices from those glorified examples. Naturally, when I go out and try to hire fresh developers, all I get is a bunch of utterly confused wannabes, who will only manage to incur more damage with their haphazard approach to software development. That is, among other things, the fact I'm lamenting about.
Perhaps, after all this bashing of everything, you could provide us with some example of quality software, in your opinion?
Jesus H! I actually agree with Rolf!
Perhaps, after all this bashing of everything
Well, Rolf, I was only bashing the low quality software that's available today. That hardly qualifies as "bashing of everything", as you've said.
>you could provide us with some example of quality
>software, in your opinion?
I already did that, but you obviously weren't paying attention. I'll repeat it here, for the benefit of your education:
High-quality software should possess the attributes of a typical high-quality product. To me, one of the most typical high-quality products in use today is an automobile. If we look at typical cars, they are quite easy to use (one need not make a career out of it), easy to maintain (change the oil at regular predetermined intervals, same goes for brakes, mufflers, etc.), they take us from point A to point B without being in our way when using them, and so on.
My argument is that software products should be exactly like that -- easy to use (no need to make a career out of using any of them), easy to maintain (regular easy to comprehend house keeping activities), they should take us from point A to point B (meaning, should assist us in doing our work) without standing in our way.
However, if we look at typical software products, we see that they fail miserably on all those accounts. To begin with, most software requires hard and arduous training before we could even begin to use it (one almost needs to turn using that product into a career choice). Furthermore, such products require indepth expertise when it comes to the maintenance activities (they are very taxing on our short and long term memory). Also, such products are typically very annoying, always standing in our way and interrupting our workflow with most idiotic behavior. Consequently, most software products are incapable of taking us from point A to point B (and it is worth remembering here that the only reason we ever acquire any software product is so that we could get from A to B; otherwise, who would ever bother with looking into any software?)
Another high quality product that's in widespread use today is a TV set. Both cars and TVs share this characteristic that anyone can use them (no need for extra special training), anyone can maintain them, anyone can enjoy them (cars and TVs don't stand in our way when enjoying them).
But the most important fact in all this is that both cars and TVs are themselves extremely complex systems. Yet, people who use them are never ever made aware of how devilishly complex this things actually are.
Most people reply to me, when I explain what's wrong with software, that such cumbersome attributes of software products are unavoidable, given their complexity. That's a bunch of balloney, of course, because, as we've seen, a product can be very complex, and still look like a child's play when we're using it. It all boils down to proper design, and the vast majority of people who are doing software design are obviously absolutely not qualified for the jobs they are doing.
That's what I'm complaining about. I'd like people to realize that those developers are phonies, and that they don't know how to build products they've been hired to build. Then, people should learn to insist on getting only quality software, comparable to such products as cars and TV sets. This shift will force talented software developers to wisen up and study very hard the profession of software design and development. So far, we've seen that they've been in general faking it. They managed (and are still managing, mind you) to get away with murder, but I think it's high time we make them aware that such flaky behavior is not acceptable anymore. Software developers must be made responsible for the crappy products they are building (same as all other builders are made legally responsible for their products).
I find it difficult to argue with you Alex, because you are obviously an intelligent fellow and right in many things. But still you forget the main point (as so many others) that everything is relative - one must always try to keep a perspective of proportions. It boils down to "even if everything you say is right it is still not interesting if it is not compared to something else".
For example Jetspeed. What other portal system is better in your opinion? If nothing is better then Jetspeed can still be useful..
You must be careful to not end up like Ibsen. As long he critized different traits in the human caracter he was acclaimed and greatly appriciated. But when he bashed the whole human race they lost interest!
Anyhow I have to thank you for the reference to the Webmacro - Velocity fork. I read the old mailing list.. For instance here is a snippet from Jason Hunter, an other favorite of mine:
"At the end of the day, just as proprietary code migrates to become open source code, so do I see GPL code migrate to become BSD code. Only with unrestricted use licenses do people not have an incentive to reinvent
If nothing is better then Jetspeed can still be useful..
Rolf, this is reminiscent of one of the works of the famous Russian writer Fyodor Dostoevsky. In his treatise "Notes From Underground" he postulates how, if he's walking out in the fields, and it starts to rain, he will start looking for a shelter, so as not to get wet. If then he happens to run accross a chicken shack, he may squeeze himself inside and wait until the rain stops. The chicken shack will serve its purpose of protecting him from getting wet. And naturally, he will be gratefull for that.
However, despite the utility of that chicken shack, he will never agree to start calling it a Crystal Palace, just out of gratitude.
Some people seem to insist that we bow before anything that serves as a utility, and to start calling it a 'Crystal Palace'.
So, in the light of that, I can say that maybe Jetspeed has some utility, but still it's just a chicken shack. It's a lousy piece of software, even if it's raining heavily outside. I will never agree to call this piece of chicken shit a 'Crystal Palace', even if I was forced to use it as a shelter at some point.
>You must be careful to not end up like Ibsen. As long he
>critized different traits in the human caracter he was
>acclaimed and greatly appriciated. But when he bashed the
>whole human race they lost interest!
This is a wise piece of advice, and I appreciate it. I cannot help but call them as I see them, though. Almost every software product I've ever used was really, really lousy. Actually, it was beneath lousy. What I find amazing is how some other people cannot notice when such products are abusing them and treating them like dirt.
But please, don't shoot the messenger! I'm just relaying the bad news, I'm not causing them.
>For example Jetspeed. What other portal system is better
>in your opinion?
Just because there isn't anything out there that's better than Jetspeed, it still doesn't necessarily mean that Jetspeed is any good.
>"even if everything you say is right it is still not
>interesting if it is not compared to something else"
Right. But I did compare it to something else. I gave you quite an elaborate comparison with other more successfull products out there (such as a car, or a TV set). You never bothered to comment on that. I believe if we re-adjust our focus and strive to deliver products that would be designed along the lines of the TV sets, for instance, our whole industry will dramatically change. It's all the question of focus, not the matter of skills.
I have a friend whose outlook on life is very much like yours. Would love you two to meet!
I [...] am flabbergasted when my students [...] insist
> on peeling that onion, which I tell them is the most
> stupid thing they could ever do.
It should be. But it isn't. The problem is that our abstractions don't work.
When an automobile manufacturer integrates a braking system into their new car, they don't have to know about all of the engineering behind it. They determine operational parameters, form factor and so on, and expect their suppliers to come up with something that works effectively when the driver slams the brakes. Those abstractions work for them.
For thin-client Java developers, the highest-level abstraction that mostly works is the Java programming language (but even there we have to be aware of the intracacies of some of the plumbing, for instance garbage collection). The additional layers at our disposal, be they Servlets, EJBs, Struts, or RemoteApps / Xyrian, are all horrible as abstractions. They can't be treated as black boxes at all. Through architecture, scope and capabilities limitations, misconceptions and bugs they all require the developer to be aware of much of their internal operations and the layers they use underneath. While they are all enabling technologies that can save a fair amount of work once understood, they also mean more for an engineer to worry about, more to know rather than less.
In addition to natural inquisitiveness, this may be why your students want to peel the onion. Because they know subconsciously if not consciously that the best, most effective and brilliant software engineers are those who can simultaneously grasp all the layers of the onion they are being exposed to. Unfortunately, today, that is two-thirds of the onion -- and grasping all of that beyond the means of most.
This is normally suffered by high-level architects who are forced to find new jobs that require them implement some of those presentations that made them the toast of the town a couple of years ago. People that fall into this category are those that never really understood or appreciated the technical expertise required by software engineers and programmers to transformed their Visio presentations into business solutions. Today, they find it very discerning that they cannot feed those beautifully crafted "technical" presentations into some magical tool that renders a usable solution to the business.
Your examples of the car and tv are invalid in my opinion. Both of these products require the assembly of numerous complex components that an end-user would not understand nor care about. I suggest more valid comparisons would be spreadsheets, web-browsers and games to the car and tv.
If the ability to drive a car does not entitle you to call yourself a mechanic, why should the software engineering profession be any different. If it is the end product that interest you, maybe you should get off the assembly line and stand on the other side of the counter waiting for your shiny new end-user product to be delivered.
People that fall into this category are those that never
>really understood or appreciated the technical expertise
>required by software engineers and programmers to
>transformed their Visio presentations into business
You've failed to recognize one important detail -- in order to become a high-level architect, I had to successfully pass many years of intense low-level coding and implementation. I've started studying programming languages in 1982. Twenty one years later, I've worked my way up to the Chief Architect level. No one is going to give you the Chief Architect chair if you haven't proven your worth in the world of software development through many years of hard work and delivering results.
So, after spending decades building software, I fully understand and appreciate the technical expertise that goes into delivering a finished software product. I'm just not blinded by those. Meaning, I see that there are other, more important issues and different kind of expertise that must go into the product. Technical expertise (the programming knowhow) is the least important aspect of the software product. And yet, today we hold that aspect to be the most important one. Everything else gets to be subservient to that aspect. I say we, as a community, have an alarming problem with identifying the true perspective.
>Your examples of the car and tv are invalid in my opinion.
>Both of these products require the assembly of numerous
>complex components that an end-user would not understand
>nor care about.
How is that different from assembling software products? If I, as a software developer, am going to use some prefabricated software component, I have surrendered myself to the fact that I will not understand that component, nor would I care about it. I, for example, do not understand how TCP/IP works (nor do I care how it works, to be perfectly honest), and yet I'm merrily using it every day. I could turn my usage of TCP/IP into a career choice if I were foolish enough, but luckily I've decided not to bother.
>I suggest more valid comparisons would be spreadsheets,
>web-browsers and games to the car and tv.
I disagree. Spreadsheets, web browsers and games are, in general, very lousy products. If you'd recall, we were using high-quality products as our yardstick, and no known spreadsheet, for example, comes even close in the quality to a TV set.
So, if you insist that our comparisons stay within the software realm, you're out of luck, because in software the phenomenon of high-quality is still completely unknown. We must, therefore, look for our yardstick in other industries.
>If the ability to drive a car does not entitle you to call
>yourself a mechanic, why should the software engineering
>profession be any different.
Exactly! That's precisely my point (thanks for articulating it so fluently). Developing software is an activity just like any other. We need some tools, we use them, but we don't really have to understand them. I don't really understand how my cordless drill works, but that's not stopping them from using it successfully on an almost daily basis (as I'm enjoying home renovation activities).
We must overcome our fascination with software systems, and start looking at them as mere utilities.
I am teaching software development courses at three local colleges, and am flabbergasted when my students proclaim that they must understand everything in depth before they can start using it. They always insist on peeling that onion, which I tell them is the most stupid thing they could ever do. Because, where do you stop? Do you really wish to dive all the way down to understanding the quantum physics of the silicone, before you can write your first sort routine?
>If it is the end product that interest you, maybe you
>should get off the assembly line and stand on the other
>side of the counter waiting for your shiny new end-user
>product to be delivered.
What you fail to grasp is that even the assembly line workers are end-users, waiting for their shiny new products to be delivered. Then they take those shiny new components, assemble them together, and pass them on to their customers. Their customers then may take those parts to the next level, and so on. It's all intertwined like that. We need to understand the bigger picture.
I'd have to agree with Alex.
Software production methodology and process has only incrementally advanced over the last 40 years or so.
What we do today is only incremental layers over what we used to do.
assembler->C->C++ java. Languages are still for the most part about fiddly imperative statements.
O/S's have progressed even less.
If a science fiction author was to write about how computer technology looks and interacts with us in say, 50 years would it really be another 50 years of incremental changes?
I don't think so, what we really need is that horrible word 'paradigm' shift, people currently tell software almost everything about how it goes about its business, what we really need is systems where high level requests are made and low level details are deduced/reasoned.
No one is going to give you the Chief Architect chair if
>you haven't proven your worth in the world of software
>development through many years of hard work and delivering results.
I must be living in a different world. Since the economy has turned downward, I have interviewed numerous so-called chief architects that apparently had been promoted to the role because they were able to explain the difference between CMP and BMP. In other words, they had no real world experience delivering real world business solutions.
>I am teaching software development courses at three local
>colleges, and am flabbergasted when my students proclaim
>that they must understand everything in depth before they
>can start using it. They always insist on peeling that
>onion, which I tell them is the most stupid thing they
>could ever do. Because, where do you stop? Do you really
>wish to dive all the way down to understanding the quantum
>physics of the silicone, before you can write your first
If you want high-quality software, provide your students a high-quality education. You complain about low-quality software yet you want your students to accept whatever junk you happen to offer them without questions.
>I disagree. Spreadsheets, web browsers and games are, in
>general, very lousy products. If you'd recall, we were
>using high-quality products as our yardstick, and no known
>spreadsheet, for example, comes even close in the quality
>to a TV set.
>So, if you insist that our comparisons stay within the
>software realm, you're out of luck, because in software the
>phenomenon of high-quality is still completely unknown. We
>must, therefore, look for our yardstick in other industries.
Software is used in almost any product that you can name, including your cars and televisions. Maybe you should restrict your argument to specific categories of software or declare all products junk. The primary difference between your television and a spreadsheet is you don't have to put garbage in the TV to get garbage out :)
I apologize if you have seen this before, but follow this link as a reminder of what a software artist is capable of, it will give your kids something to aspire to - a role model, a Father Figure, so to speak.
That reminds me, you can actually download an O/S 370 emulator for your desktop, so if you really want to code up some JCL like the real programmers used to...
First off, Alex you are my new found hero.
> When an automobile manufacturer integrates a braking
> system into their new car, they don't have to know about
> all of the engineering behind it. They determine
> operational parameters, form factor and so on, and
> expect their suppliers to come up with something that
> works effectively when the driver slams the brakes.
> Those abstractions work for them.
Ahhh but your example is very different from a framework. It is the exact opposite actually. As you describe the car manufacturor designs an API, and asks the brake manufacturor to please build brakes which meet their specification, or in our lingo API. As long as the brake manufacturor builds to that API, there should be seamless integration into the vehicle and the cehicale manufacturor can treat the car as a "black box". In our lingo, we call this encapsulation.
When you use a framework, the opposite holds true. The framework provider gives YOU the API and makes YOU inegrate into it. This is a very different ball of wax.
Its funny. It reminds me of an engineer I had working for me. He had torn apart a 3rd party control we had purchased which would simply put, display data in a grid. I asked him on day why the hell he had spent all this time tearing it apart. He said he didnt trust "black boxes". Its called encapsulation and its good. Use it. If you cant trust it, then why did you purchase it?
> Through architecture, scope and
> capabilities limitations, misconceptions
> and bugs they all require the developer
> to be aware of much of their internal
> operations and the layers they use underneath.
> While they are all enabling technologies that
> can save a fair amount of work once understood,
> they also mean more for an engineer to worry
> about, more to know rather than less.
Let's stick with the car example then. If the car manufacturor gets the brakes they ordered, and the brake system is so fundamentally flawed it requires that the car manufacturor reverse engineer the brakes to assure they can be integrated and are safe, the car manufacturor will find a new supplier of brakes! This is the quality issue Alex is trying to get through peoples heads here. Saying "well the bits are so bad I had to tear them apart" is publically admitting you made a poor choice in the tool.
As Alex said, as an engineering team manager, I would gladly pay tens of thousands of dollars for something that would save my developers work. Unfortunately, my experience has been that 90% of these frameworks are of such low quality that they cause my developers MORE work.
Somewhere over the last 5 years we have forgotten that the DELIVERY of software is as important as its 'elegance' and its 'frameworks'.
Take football (american) as an example. You get four chances to move a ball 10 yards. You may design the most beautiful, elegant, amazing play, but if you dont make it 10 yards with that play, no one cares. You're a bum. Make that same elegant play, and hit 10 yards, and you go down as brilliant. In the end, elegance and design patterns and frameworks are not the discriminator in the union, but rather productivity is. Its time for us to teach the new developers coming up in our organization that tinkering is for late night homework on your own time. On my time its about getting good software out to market on time.
I must be living in a different world. Since the economy
>has turned downward, I have interviewed numerous so-called
>chief architects that apparently had been promoted to the
>role because they were able to explain the difference
>between CMP and BMP. In other words, they had no real
>world experience delivering real world business solutions.
I don't see what's wrong with a candidate who's able to explain the difference between CMP and BMP?
Now, if that's the *only* thing that the candidate knows, then yes, I can see there being a problem. I'd still say it would be next to impossible to see a chief architect who has less than at least 10 years of solid full time experience in software development.
I remember when I was a CTO in a startup company during the heady days of dot com; even then I would never consider hiring someone for an architect role without seeing a solid track record of 10 - 15 years of software development. Maybe some Mickey Mouse wannabes used to promote any phony bullshitter into an architect, but I'm sure they lived to regret it.
>If you want high-quality software, provide your students a
>high-quality education. You complain about low-quality
>software yet you want your students to accept whatever
>junk you happen to offer them without questions.
That's exactly what I'm doing -- I'm offering them a high-quality education, which they flatly refuse because they want to drag everything down to lowest level bits and bytes. It's like teaching someone to drive a car, and they flatly refuse your teaching approach unless you first explain in excrutiating details how does a car work, down to its smallest part.
What 99% of the people I teach fail to grasp is that software development is all about concepts, not about implementation. That's unfortunate, because these people then go on to get jobs and then contribute to ransacking this beautiful and promising discipline. That pisses me off, to say the least, and I will continue bashing such irresponsible people.
>Software is used in almost any product that you can name,
>including your cars and televisions. Maybe you should
>restrict your argument to specific categories of software
>or declare all products junk.
It saddens me to see that you apparently can't understand a thing I'm talking about. So what if cars and TVs contain imbedded software? How does that affect me, the consumer?
I have been using cars for more than 20 years now. Ever since the late seventies, I've been driving them, and my experience hasn't changed one bit since they started putting imbedded software in the cars. The point is, I couldn't distinguish a car with software from a car without any software in it (whether it's an old Chevy from the 50s, or the latest model, both cars have gas pedal to the right, brake pedal to the left, a steering wheel, and so on). The same goes for TVs etc. If that's the case, why should we even mention the software inside those products?
What we're talking about here is the consumer experience when using software. When I'm using a car, I have no software experience, and consequently that software imbedded in the car is completely immaterial from the user's perspective. However, when I'm using Struts, for example, I'm having a 100% software-centric experience, and because that particular experience is driving me nuts, I am forced to conclude that something is seriously, alarmingly wrong with most of the software products today.
If you don't share my frustration with today's software products, you're either: a) a masochist, b) an overly enthusiastic hobbyist, or c) sensitive as a log.
to know you can't really do much home rennovation with one. When it comes down to doing serious work, you have to plug in.
I do know (or have a relatively good idea) how TCP/IP works. If necessary, I could build it from scratch (poorly, over a long time.) I consider myself a very junior programmer, but I think understanding both the fundamentals and the "big picture" are important to successful design.
Earlier I posted a rant about Struts, but I don't really real qualify to judge it, because I don't really understand it completely. I know the basic architecture, I know how to use it, but I also know that many other people find it useful (even though it baffles me why.) I could build it from scratch, and in fact, I would prefer to use my own home-brew method because it corresponds more to the way I think, only I realize my solution isn't nearly robust or complete enough, and (here's the clincher) -- as widely used and well documented. Yes, I'm frustrated with Struts, I realize it's a chicken coop, but even though I can imagine a crystal palace, I can only build a chicken coop myself.
In most of your arguments about quality of software, you continually refer to examples of hardware...
Why do you have the same expeaction of software as you do of hardware?
In most of your arguments about quality of software, you
>continually refer to examples of hardware...
>Why do you have the same expeaction of software as you do
First of, I think we've established that the only reason we're referring to the examples of hardware is because there are no high-quality software products on the market. If there were, I'd gladly discuss them. If you can point me to one, I'd be more than happy to discuss it.
Secondly, I don't have the same expectations of software as of hardware. Where on earth did you get such an idea? I merely have the expectation of quality. Is that such a strange concept? If I'm paying for something, I want quality. In the same manner, if someone's gonna pay me, I'll do my best to deliver quality to the paying customer.
I could understand if I was discussing this with people from the former Soviet Union, where the concept of quality had purposefully been denigrated (by Lenin, Stalin et al) during the most of the twentieth century. These people have every right to be confused now with the idea of quality. But here, we're discussing quality with people who have been practising market economy for generations, and market is driven primarily by quality (price/performance factor). So, what is it that still confuses you about the idea of quality? Why is it such an alien concept to most of you?
First of, I think we've established that the only reason > we're referring to the examples of hardware is because
> there are no high-quality software products on the
> market. If there were, I'd gladly discuss them. If you
> can point me to one, I'd be more than happy to discuss
Would this include products which you have created? Don't take this as an attack, rather I am very interested in what you are saying but am dismayed at the complete lack of any decent software (according to you.) As a software developer it is hard to accept someone saying "all software is of low quality" without having some sort of reference of what a high quality piece of software is.
Secondly, what exactly is "high quality" software? Is a piece of software not high quality because it has one or more bugs in it, even if it gets the job done? If you use your hardware analogy then couldn't you say that there is a lot of low quality hardware as well, and in fact the majority of the products which we use are of relatively low quality considering how often we have to repair and maintain these items?
Personally I consider the quite a bit of the software I use on a regular basis to be pretty darn good (not perfect, but usable, a lot like the car I drive). Just considering the fact that we can have this discussion without respect to borders or boundries indicates that there is probably some pretty decent software at work and hardware at work.
"... If you can point me to one, I'd be more than happy to discuss it. ..."
Well, you can always argue against any software, because there is no such thing as quality per se. If you want to define quality, the closest you can get is maybe "... making the software what the customer wants it to be like."
This might include factors like:
- It needs to do this and this transaction
- It needs to report nightly reports
So, here we have the business requirements. On top of this, some general software quality factors are added:
- Needs to be performant
- Needs to be easily extensible
- Needs to scale
- Needs to be localized
- Needs to be easily deployed
Each of those quality targets usually has some (usually negative) impact on other quality targets. Therefore, no software product on the market will fulfill _all_ possible quality factors. Therefore it is always possible and easy to say a product is shitty like you did with Jetspeed.
In the end, I'd argue that without the knowledge of requirements/quality targets set for a product, your approach of "point me to one and I discuss/destroy it" is unfair.
Well, you can always argue against any software, because
>there is no such thing as quality per se. If you want to
>define quality, the closest you can get is maybe "...
>making the software what the customer wants it to be
This is where you and I fundamentally differ. To begin with, it's a widely known and documented fact that the customer in most cases doesn't know what the product he/she is asking for must be like. It's very similar to going to see the doctor. You're not going to tell the doctor what is it you'd like him to perform on you (unless, of course, you're a complete arrogant idiot ). You go and see the doctor because you're concerned about your wellness. The doctor has the expertise to diagnose you correctly and to prescribe the subsequent treatment.
Same is with software needs -- we don't really know what is it that we need. We're more concerned about the general wellness of our business, and we have reasons to believe that seeing a software specialist may give us better chance of achieving that wellness.
Now, on to the quality:
Quality is not something subjective, or whimsical. It is very easy to perceive and detect quality, because it is easy to measure its presence. And it basically has to do with meeting the stated goals.
For example, if my goal is to send an electronic message to the desired recipient, then a quality product should enable me to do that without expecting me to know anything about its internal workings. In the early days of interconnectivity, you couldn't send an electronic message unless you were privy to some cryptic arcane language that only the high priesthood of computerdom had privileged access to. Today, even my grandma can send me an email.
If we measure the early email utilities with the latest ones using the 'goal' yardstick (a goal in this context is sending a message without making a career out of doing it), then it's easy to see that the newest products win hands down over the older ones.
Same applies to any other product: how successfull is it in supporting the end-users' goals? It's fairly easy to measure that, and it's sufficient to form a verdict on a product.
So, no mumbo-jumbo here. No nebulous "making the software what the customer wants it to be like." The customer has certain goals, and if we can build/deliver a product that helps the customer reach those goals in a reasonable fashion, we have delivered quality. Voila!
>In the end, I'd argue that without the knowledge of
>requirements/quality targets set for a product, your
>approach of "point me to one and I discuss/destroy it" is
Well, see above. Is it unfair to demand quality? You decide. I'd say it is not. I have some goals to reach, and I'm considering using software products to help me achieve that. I pay good money (or, I invest a lot of my precious time in searching for it, downloading it, installing, learning, etc.), and if it turns out that my goals are unreachable when using that product, I declare it a shitty low quality product. Why is that unfair?
For example, I've spent some time evaluating Jetspeed. Why? Because I wanted a tool that will help me build portals faster and more reliable than doing it by hand. What I found in Jetspeed, however, is a confused, disorganized product that's not clear on who its customers are, what is it supposed to do, which goals is it supposed to help achieve, what activities is it supposed to support. Consequently, I give it thumbs down.
Ok, my 0.0002c:
TVs and cars do exist in this form for decades, they have reached their "perfect" human interface. I bet there were some interface problems in the beginning. Software has changed dramatically every 10 years or so. And until the "perfect" sotware interface or API appears, this will go on. We can even think software industry itself doesn't want this "final" solution, and instead make lots of money selling new sotware, books and consulting, around this ever-evolving market.
Software could be best compared to a form of art, since it depends so much on our own criativity. You take and idea, and by pure thought and hand work, build something that works, made of thousands and thousands of tiny parts that relate to each other, so much that if ONE of these parts gets out of place, the whole thing stops working.
Flexibility, power and simplicity in one box, thats the dream of all tool makers. But each one is orthogonal to the other 2. In order to increase one, you must decrease another. And technology will always set limits to how far we can go with this problem. Like cars (again): every one knows that eletrical cars will eventually be superior in almost all aspects to the internal combustion one. But technology is holding it back (ok, some petrol industries may be too, as some conspiration theories go).
Another thing: who you think would better maintain his/her car: someone without any knowledge of mechanics, or someone with that kind of knowledge? I am not arguing that we must all start breaking things just to see how they work, but rather, to have at least an idea of how things work would help us, mainly when things start NOT working... IMHO. If someday you car suddenly stops in the middle of nowhere, remember these words :-)
Ok, my analogy now: I compare the sofware industry nowadays to the early days of cars... There would be the "master" mechanics, but then, there were tons of "learned-from-scratch-by-their-own" mechanics all around... Just like many developers now. Anyone can buy a VB book, and call himself a programmer. And since end-users don't know anything about what's under the hood...
Final thing: I disagree with the the statement about the customer not knowing what they expect of a product. Only if they don't even know what they are buying. But if the customer wants a car, they sure know what to expect. When you go to the doctor, you expect him to look at you, use some instruments when applicable, tell you what's going on, and give a prescription, or else take you to another doc who will be able to do it better. So yes, you know what to expect when you go to the doctor. The customer is not that blind, even reagarding software. Ok, maybe they were years ago. But now, everyone works with a computer in front of him/her, everyone has an idea of what software should be like.
It's all about evolution, and software industry is still in its infancy. Ok, a bit older than that: it's just a teenager, full of energy and excitement, but with no idea of what he'll be when he grows up...
(forgive my english, it's not my mother tongue)
OK, OK, enough is enough. There are no subject small enough or insignifant enough so that TSS will not discuss it forever.. I know it is hopeless to ask for a perspective of proportions.. There are enough important issues to be solved.. The critical type of personality that Alex represents can never do anything creative, no matter how intelligent or welleducated he/she is.
I guess we will have to wait for a Henry Ford of the software production. Someone who will come and say: software must be done this way, simple and direct, and then everyting will fall into place. A "sofware assembly line" of sorts.
There's a natural progression from automating the production of mechanical systems to automating the production of software systems. I spent 10 years designing parametric CAD/CAM software - a product called Pro/ENGNEER, which enabled engineers to model large complex mechanical systems like a jet engine - in 3D. The approach was unique in that when you used the tool, you could make a change anywhere during the design/modeling process, and everything would update, including all the 3D geometry, plus all the things like drawings, machine toolpath instructions, etc... This improved productivity dramatically, and changed the way people design things today. It was the spreadsheet concept applied to modeling mechanical systems.
In 1998, I decided to apply the core modeling technology - called parametric modeling, to modeling software itself. We picked the J2EE domain, and created a tool caled The Factory. People use it to create web apps and portlets. The idea is the same - model potentialy large and complex software systems, such that if you change key parameters, the software knows how to update automatically. It is the cncept of design automation applied to software.
If you look at today's modern products such as digital cameras, there's almost as much software in them as hardware. Ultimately, there is no line differentiating mechanical and software systems. They are just systems. We have abstracted the technlogy called parametric modeling so that it can be applied to any kind of system.
The product, The Factory, runs in JBuilder and Eclipse, and on the J2EE app servers. Developers can extend the product for modeling software in any domain , or they can use the set of Builders - analogous to formulas in a spreadsheet - to build parameterized web apps and portlets. The company I am at is called Bowstreet.
I have a great interest in the subject of design automation as it applies to software. I spent 10 years building modeling software for the mechanical industry, and it's true - we're only in the early stages of applying these powerful technologies to the software world.
You just said it:
"So, no mumbo-jumbo here. No nebulous "making the software what the customer wants it to be like." The customer has certain goals, and if we can build/deliver a product that helps the customer reach those goals in a reasonable fashion, we have delivered quality. Voila! "
With this you just repeated, what I said quality is: Something what the customer wants. Pretty simple:
Goals = Quality wanted
You reach the goals = you made a quality software.
Now, you are saying there is no quality software. This means no software ever did what it was supposed to do. An email has never been sent. Internet Banking does not exist. Google is an illusion. There is no spoon :)
Let me conclude MHO: I'm sure there are products, which implement their requirements/goals in a bad way. But I think, most of the products do not. Saying that all of them are bad is just because your requirements/goals differ from those of the product. It is still a good product. It just doesn't fit what you need.
I have followed this thread with great interest and enjoyed your part when you brought examples and details to bear to support your opinions. You obviously have a great deal of experience and have thought about the subject copiously.
The one characteristic of your posts that bothers me is that you are never wrong. I failed to observe one instance where you admitted to learning something from from your fellow participants in this forum. Furthermore you conspicuously ignore chances to agree with posters who express sentiments and opinions similar to your own, but instead always focus on your difference of opinion.
Possibly you never change your mind, possibly you view admitting such as a weakness. But consider this, when you admit that someone's argument causes you to reconsider or at the least re-phrase your position, you add weight and legitimacy to all your opinions and positions. People see that your mind is not closed and that you can increase your understanding and they apply that in such a way that their trust in you and your ideas is greatly enhanced.
Sorry for the lecture.
I can not help to notice that so many in TSS is taken in by impractical theorists. I said earlier in this thread that one must try to keep a perspective of proportions, "it must be compared to something else". OK, lets compare Alexs posts to some real experts like Juergen Hoeller or Rod Johnson and you see immediately how hollow he is. This love of "Computer Science" and the downgrading of practical intelligence and actual talent is what lead the J2EE community astray in the first place. It will be fun to wait for his framework.. I for one do not think that he can get together a decent application even if his life depended on it.
"Those who can do, the others teach"
"Those who can do, the others teach"
So true. So, so true. I work at an investment bank in SF, and, with all the out of work java developers in the bay area, we've had quite a few "Architects" come through interviewing. I always ask them this question:
"What pisses you off about Java?"
Usually, they are speachless. Occasionally I will get a "Well, the APIs are too complex." Rarely do I hear "Well, the primitive/Object distinction sucks. And what the hell is going on with Arrays?" or some other such reply that indicates that they have *worked* day-to-day with the language and environment. You'll get some guy pimping struts as if there aren't any problems with it (and, hey, I like it, but there are parts that are garbage as of 1.1beta3). You'll get some guy ready to jump out of his pants and start drawing UML and spouting GOF/ExtremeP/AspectOriented/ServiceOriented/DBC nonsense, but rarely have I seen a guy who I say "whoa, I wan't *this* guy leading my team." I'm a crappy, midlevel programmer, but, in my experience, I do a lot less damage than some of our "Architect" friends... (Well, at least most of the time. ;-)
Is it normal to be this jaded by 26?
P.S. Is it me, or does anyone else sense a similarity between the J2EE "gurus" and the English Department post-modernists?
"P.S. Is it me, or does anyone else sense a similarity between the J2EE "gurus" and the English Department post-modernists?"
Ha ha, good point. I often wondered the same thing myself! My favorite is:
"Organize inter-service transfers according to use cases from known domain objects into a coarse-grained Composite"
"Is it normal to be this jaded by 26?"
Good for you that you can at least have influence on the interviewing process for architects. Usually you get into a company and there _is_ already an "architect".
I worked in such an environment. I came into a company supposed to do the "ultimate" and "the last" epayment solution and there was this "architect" who IMHO had no clue about J2EE (he did not even know how to start WebLogic), buuuut: He was very good in fooling people, good with words, already was in the company for a year and had some "architect" years back in some quite wellknown companies. In this scenario, it was me (young, no history, long hair) against him (old, Phd, well established) - both with strong opinions. Neither of us would give in and I had no way to work around him. What I did? I quit. And it felt very good.
My lesson learnt: "Love it, change it, or leave it"
So, jaded with 26? I don't know, temporarily maybe. Forever? No. And there is always beer:)
Thanks for the lecture. Your points are well taken.
>The one characteristic of your posts that bothers me is
>that you are never wrong. I failed to observe one instance
>where you admitted to learning something from from your
>fellow participants in this forum.
You are right, my posts in this thread have been very impatient. In my own defense, I must rush here to say that the impetus behind my impatience lies in the fact that there is so much to say on the subject, that I feel compelled to absolutely storm this forum while I sense I have a captive audience (I have a nagging feeling that my captive audience will soon start to dwindle, as people's attention span is typically very fickle). That's why I never have the time to dwell on many of the incredibly valuable comments.
My experience teaches me that for some reason it's extremely difficult to get people to sit up and listen about the problems I'm exposing here (believe me, I've tried many times before using various forums and venues, and have most of the time been booed off the stage and/or tarred). Furthermore, I'm just about the only software developer I know of who will bring up these issues for discussion. I've never heard anyone else ever mention these problems.
Because of that, I feel entitled to drive this conversation (being the sole originator). I may appear unbelievably arrogant, but I'm merely striking the iron while it's hot. I may try to apologize for that, but I know that it would be futile.
But it goes without saying that I'm mostly wrong in everything I say and do. That's a given. Still, I feel that it's very important to engage in considering my grievances, no matter how wrong they may be. I believe we, as a community, will better ourselves if we keep the grievances I've exposed here in our minds at all times. It will definitely help us deliver better products. So I view this discussion as strictly educational. It's not really about who's right or wrong.
>Furthermore you conspicuously ignore chances to agree with
>posters who express sentiments and opinions similar to
>your own, but instead always focus on your difference of
You're correct again. There are two reasons why I act like that in this forum:
1. I feel that it would be corny to dwell on the posts where some people praise me. I thank them silently in my heart, but publicly I'm blushing.
2. I don't have a hell of a lot of free time on my hands (which may explain the substandard quality of my posts, which are always a rush job; I never have the time to edit anything I post here, it's always a knee-jerk reaction). So if I have to choose between patting myself on the back or addressing the outstanding issues, I tend to choose the latter. Keep in mind that it's a single guy (me) against numerous other people. The balance is very skewed, to say the least.
>Possibly you never change your mind, possibly you view
>admitting such as a weakness.
Not at all! I'm very open to discussing anything (and i'm very susceptible to the forces of strong arguments). But in this case I feel we need to seriously consider the issue of quality, and that's why Im rushing to bring that to everyone's attention.
>But consider this, when you admit that someone's argument
>causes you to reconsider or at the least re-phrase your
>position, you add weight and legitimacy to all your
>opinions and positions. People see that your mind is not
>closed and that you can increase your understanding and
>they apply that in such a way that their trust in you and
>your ideas is greatly enhanced.
You're absolutely correct. In this particular case, however, I'm not interested in getting people to trust me or my ideas. These are not my ideas, these are just facts found in the world around us. It's almost like trying to convince someone that there is such a thing as force of gravity. I don't want you to trust me or believe me, I want you to see for yourself. It has nothing to do with me, or my ideas, or my personal agendas.
>Sorry for the lecture.
No need to feel sorry, man. Keep it coming!
You did not give any examples. A car is not software. Everyone has learned how to drive a car, and a car's user-interface is fairly standardized. To turn an old analogy on it's head, a software framework that is as accident prone as driving an automobile would be unacceptable. There are far too many accidents with cars that are a result of the unnecessary difficulty in driving cars. Already, we are using software systems in cars to reduce this complexity (engine diagnostics, fuel injection, anti-lock breaking systems, etc.)
But that is beside the point. If you increase the complexity just a little bit, people are forced to make a career out of driving. No one suggests that driving a semi-truck or flying an airplane is not a skill that you shouldn't dedicate your career to. Complex software systems are the same way. Sure, anybody can learn HTML in a weekend, but if you want to build a distributed, secure software system, you are probably going to have to make a career of it, and probably specialize.
Not that I'm any kind of fan of what we have today. I still can't see any value-added in struts. I'm still not sure if it is because of lack of good documentation, but I'm increasingly suspicious it is because I can't see anything it solves. I fail to see the problem domain for it. Is it supposed to make MVC accessible for people who do not know what a servlet is? Action forms don't seem to abstract anything at all for someone who is already familiar with the HTTP Request/Response pattern, and has already used, for example, CGI. I gave up on Jetspeed too, for the same reasons... too much work to deploy. I'm certainly glad that EJBs are being put in their place. For most applications (especially web apps) they are overkill. What is really needed is a temporary persistence mechanism that 1) relieves stress from the database tier (caching), 2) can encapsulate the date in a form the business tier understands (o/r mapping), and 3) can maintain transactional integrity
Right now, you either end up using EJBs (and watch your entire system crawl), or try to implement it it with plain old java objects either manually or with an o/r tool (and watch your database bottleneck), or try to bind everything you can to the session (and watch your app server run out of memory.) This is the real problem domain, and the frameworks existing are targeting the edge cases (ui and persistence) when what we really need is something that aims for the middle
You may have a point there. However, I'm extremely skeptical. I would be prepared to bet large sums of money that RemoteApps' product is most likely a low quality one. I don't know, just a hunch (don't have the time now to examine this hunch).
You should be more positive. We did a good job at building the framework. Yes the first version was ropey back in 1998 but then again so were all the servlet engines we were running on at the time. The second version was much better, alot of rewriting. The third and final version was really rather slick, more rewriting again. 4 years of work, so you would imaging that in that time we improved enough to produce a pretty good product. Alot of what you see in open source we built commercially well ahead and there are several things not available in open source that we were proud of two.
Anyway, unless you are going to buy it, please refrain from slandering and discuss more objectively, especially as you have zero experience of it.
You should be more positive.
I should? Really? Why? Give me a valid reason why.
Let's examine the possible scenarios:
a) Xyrian is an excellent product. And yet, it sank. It's been put up for liquidation. A year ago, I went through a similar debacle where we had to put up our product for liquidation. Bad news is that no one wants to touch a product in such condition, not even with a ten foot pole. What businesses are discovering after the dot com fiasco is that a product is only as good as the team behind it. Dissolve the team, and the product is worth less than the paper its specs are printed on. So, no reasons to be positive given this scenario.
b) Xyrian is no better than other sucky frameworks out there (Struts, Velocity, Jetspeed, Turbine, etc. etc.) If that's the case, on what grounds should I be more positive?
So, no matter how you put it, there is a reason to be concerned.
>Anyway, unless you are going to buy it, please refrain
>from slandering and discuss more objectively, especially
>as you have zero experience of it.
Do I smell 'litigation' here?
I was merely generalizing when I said that I am skeptical about Xyrian. As you may know, every generalization is by definition inconclusive, so no slender is ever implied.
But the thing that's really bothersome to me is how many of the 'plumbing frameworks' guys are so litigeous. Legal issues seem much dearer to their hearts than software architecting and designing. No wonder these products are being released in such sorry shape.
I remember back in the summer of 2000, when I started looking into the WebMacro MVC framework. As soon as I've decided to standardize on that framework (being dissatisfied with the JSP specs), a political infighting broke out on the WebMacro's mailing list, and to my utmost shock some guys started speaking legalese. Before you knew it, a faction was formed which took the source code and ran away and morphed it into the product named Velocity. It was sickening to watch, and taught me an important lesson how those open source communities can be just a pathetic excuse for power-hungry small minded people to play their dirty little tricks.
So, by insisting on your 'slander' comment, you've managed to convince me about the true nature of the product you've built. Rest assured that not only will I never mention your product again, it will not even cross my mind again.
I am sorry to hear you were in a similar position I wouldn't want anyone to go through it.
I meant you should be more positive about the efforts people are making. Whether one product sucks or not at least people are trying.
Yes, I know that the team is the most important thing behind a product. We unfortunately weren't in a position to sell the software at the time of closing as it was out of the managements hands. So we lost our team.
At the moment I don't own the software and would benefit no more that a few weeks pay if it does sell. The investors own it.
As for litigation. I didn't mean that, I merely used the word slander and asked you to talk objectively about the topic of frameworks which you haven't done, yet.
As a user of frameworks and someone that is not happy with what they do currently, why dont you say what you would like them to do? This might help the current people writing frameworks. Not me, as it happens.
What did you like most about WebMacro? What is wrong with Struts?
What type of projects have you used a framework with?
Let's not degrade any good discussions we might have like so many other threads on the server side.
>I meant you should be more positive about the efforts
>people are making. Whether one product sucks or not at
>least people are trying.
But what I want to do is help them invest their efforts in the right direction, so that they stop treading water and spinning the wheels, and finally start moving. Obviously if you've been trying for decades and find yourself in the same place where you've started, common sense is telling you that you're doing something wrong, and that you should change something in your demeanor, right? You'd be foolish to say "well, at least I'm trying!"
>As a user of frameworks and someone that is not happy with
>what they do currently, why dont you say what you would
>like them to do? This might help the current people
A framework is a product that's characterized by the following ability:
old code can call new code.
Traditionally, things have always been the other way around -- old code was sitting passively in the library of routines, and the new code was calling it when the opportune time arises.
Most people I teach and mentor have serious problems with this reversal of tables. How can an old code call the new, never before seen code? The reason these people are confused is because they seem incapable of grasping one fundamental concept: late binding (i.e. runtime binding). And the reason they can't grasp late binding is because they can't understand that the only way to create a flexible system is to define a very rigid bias. To them, that's paradoxical, and they just can't stomach it ('what do you mean, the only way to be flexible is to be rigid?')
So you see, it takes a special kind of person to be able to work in the framework realm. High level, abstract conceptual thinking is paramount. Most people I've met in software today lack this basic ability.
As to what would I like frameworks to do, it's simple: frameworks should encapsulate their services. If a framework is capable of doing something, it should publicize its capability, and then shut up about it. I don't need to know *how* is the framework doing it. Why should I care to know that a framework is using 18 xml files, scattered over 15 directories, to maintain its configuration state? And by the way, what's with this pathological obsession with XML? It's just a piece of information, for crying out loud! For all I care, the framework could put all of that configuration info in a single table in a database, or in an Excel spreadsheet, or in a flat file. Why should that concern me in the least? I know that, somehow, the framework must, behind the scenes, implement the persistence when it comes to its configuration state. All I need is the ability to review and edit that state. And for that, I'd be perfectly happy if the framework offers me a humble form where I can review and edit that stuff. The form doesn't even have to be browser based.
If a framework announces that it can help me declare the workflow for my application, it should deliver just that. Allow me to declare and maintain my workflow, then implement it behind the scenes. Don't bother informing me about the implementation details. Yes, I trust that you've used some sophisticated XML parser behind the scenes to enable you to parse your fancy xml files, how wonderful! But can't you realize that such thing is totally irrelevant to me, as a user? I really don't need to be aware of all that crap.
The above had, of course, merely scratched the surface, but you may get my drift. Just build me something that's not going to expect me to become an expert in using it, and I'll start using it. But so far, I've never seen a software product that's anywhere near to being polite like that.
>What did you like most about WebMacro?
Its non-intrusiveness on the presentation side. At that time (summer of 2000), JSP was a very ugly, intrusive technology. WebMacro promised to minimize the amount of explicit logic coded on the web page, and that was a value proposition we couldn't afford to ignore, having web page designers working in parallel with application developers.
>What is wrong with Struts?
One could almost write a book on this subject. Suffice it to say here: Struts is a very impolite product. 'Nuff said!
>What type of projects have you used a framework with?
Medium to large size mission critical e-biz stuff. Also, building presentation frameworks (a framework that can display an output from any application that complies to its bias).
I have also built my own framework that generates end-to-end application code from the business declarations encoded in the XML schema document(s).
Your description of the power of frameworks and of the proper use of abstraction being the idea that unchanged 'old code' should be able to call 'new code' is wonderful. Kudos.
I find it simply amazing that for all the discussions we have about 'Design Patterns' it appears very few of these 'architects' have actually read Gamma et. al. If they had, they would see patterns like Command and Factory as well as others delivery on this neeed. (Of course Gamma always gets the credit, no one remembers the the other four guys<wink>)
I notice looking up at the TMC banner running on this site is the slogan 'We Build Architects'. No TMC, you teach architecture. Only years of apprenticeship and hands on excperience builds an architect, not 5 days in a class room.
(Of course Gamma always gets the credit, no one >>remembers the the other four guys<wink>)
You mean the other three guys ? You might want to review the book yourself :-)
Yeah I realized that about 3.2 seconds after I hit the submit button. But TSS.com doesnt allow you to edit a post. What is that abotu inflexible software? <wink>
Alex - there's also the reality that designing quality software that's not only easy to use but also simplifies business problems is actually very hard to do. It's possible, it's just hard, and it sounds like you're not satisfied with any of the attempts that have been made. Your previous comments seem to indicate that you're quite the expert when it comes to designing great software - why not write the great framework that we're all missing? I think other people are trying to do this - in fact, some of them are the the ones writing open-source frameworks, but apparently they're doing a lousy job of it.
For what it's worth, I found Struts to be fairly awkward, and then I found WebWork to be pretty clean and easy to use. I'd almost use the word "good" to describe it, but I don't want to get flamed for being an idiot.
The concept of MVC has been around for awhile, but attempts to apply it to servlets have only been around as long as servlets (4-5 years). It may be a bit early to decry everything out there as garbage and worthless. It took the railroad industry half a century to get the technology and the business processes working so that real money could actually be made (and it went through a bubble/recession in the 1870's, just like the dotcom's).
Alex - there's also the reality that designing quality
>software that's not only easy to use but also simplifies
>business problems is actually very hard to do. It's
>possible, it's just hard, and it sounds like you're not
>satisfied with any of the attempts that have been made.
You're correct. Software or no software, designing quality products is not easy. Still, people do it. Why? Because: a) they take pleasure in doing it, and b) the market demands it.
The trouble with software is that most customers are so brainwashed that they don't recognize that they are being hosed.
I'd like to see software market waking up and demanding quality. But, as you can see from the majority of replies to my appeals here, it's going to be tough.
>Your previous comments seem to indicate that you're quite
>the expert when it comes to designing great software - why
>not write the great framework that we're all missing?
Actually, I'm writing it:-) I have finished the initial portion. I'm developing an end-to-end framework that will allow people to declare their business using XML Schema syntax, and the framework then reads the schema and generates the application code (implements the user's intentions).
The framework is polymorphic, meaning it will generate different persistence strategies depending on the users' preferences. Right now you have a choice between XML and RDBMS persistence. When it comes to the presentation tier, it is also polymorphic, generating JSPs and Swing (future plans include WML).
On the downside, there are two shortcomings that my framework suffers from:
1. It expects the end users to master the XML Schema (not a trivial task by a long shot). I plan, however, to alleviate this unfriendliness by supplementing the XML Schema with a less technical GUI tool. The users will be able to declare their business model using a GUI front end (of course, the tool will translate the intentions to XML Schema in the background, but the end-users need not ever be aware of that.)
2. It sucks when it comes to declaring the application workflow. If anyone out there knows of a good declarative workflow framework, please let me know, as I would like to incorporate it into my framework.
But in a nutshell, the intention of my framework is to replace a lot of the hand coding with automatic code generation. All one needs to do in order to get a full blown end-to-end business application is to declare his/her intentions to the framework. All the plumbing, validation, persistence, presentation and some of the business logic will be generated by the framework.
Once generated, the java source files will be available for further manual enhancement. That is unavoidable (meaning, the need for manual touch ups), but the bulk of the effort will be automated. I think there is a value proposition in offering such a framework.
>It may be a bit early to decry everything out there as
>garbage and worthless.
I say it's never to early to get alerted. Rust never sleeps.
>It took the railroad industry half
>a century to get the technology and the business processes
>working so that real money could actually be made (and it
>went through a bubble/recession in the 1870's, just like
We're in agreement. Thanks for putting it so eloquently in writing.
Well, good luck in doing all this. I hope it does not just become another reinvented wheel.
Regarding workflow apps, werkflow (http://werkflow.werken.com
/) - I like a lot.
Take a look at www.bpmi.org for business process modelling defined by XML and an open standard.
| I'd like to see J2EE become idiotically simplified.
| Something like driving a car
The trouble with these over-simplified examples is that they ignore the complexity of using software to solve a any problem. Software is used because of its flexibility and because of its ability to adapt to change - the "Soft" in software is a good hint.
Now, a car may be quite complex; but you have to remember that the problem it solves is quite basic and also very well understood. The external interfaces to a car hasnt really changed in a century and the problem of A-to-B transportation hasnt changed in millenia.
On the other hand, the world of business is changing rapidly - the business problems of 1 yr ago are not the same as today's. This is obvious - as by definition, a problem is something that doesnt yet have a solution.
As soon as software solves one business problem, the business needs will have changed such that there is a need to solve a new problem.
What I am trying to say is that if it were somehow possible to build a idiot-level business-level platform, it would have been done by now. Looking around, the absence of such platforms is evidence that its not possible.
What I am trying to say is that if it were somehow
>possible to build a idiot-level business-level platform,
>it would have been done by now. Looking around, the
>absence of such platforms is evidence that its not
I was reading the above and I simply couldn't believe my own eyes -- it is very rare that one comes accross such an example of totally backwards thinking. What you're implying could be illustrated as follows: suppose for a moment that we live in the 19th century, and that I start complaining how there should be some sort of a technological invention that would allow us to communicate vocally over long distances (I'm implying the possibility of a telephone). You retort that if it were somehow possible to build such a device, it would have been built by now. To quote your previous statement: 'Looking around, the absence of such [device] is evidence that it's not possible.'
See what you're saying here? You're claiming that further inventions are a sheer impossibility now. In other words, anything that could be invented had already been invented. Hmm, talk about a crab attitude...
So let me ask you this: where do you think all those inventions, such as telephone, space travel, computers etc. came from? Are you still infantile enough to believe that Santa Claus brought them to us?
>As soon as software solves one business problem, the
>business needs will have changed such that there is a need
>to solve a new problem.
Eureka! How's that different from any other problem solving activity? Of course the needs keep changing. Not only in business but also in engineering, construction, manufacturing, etc. So, I really don't see your point.
>Now, a car may be quite complex; but you have to remember
>that the problem it solves is quite basic and also very
How is that different from an MVC framework, for example? MVC may be quite complex, but the problem it solves is quite basic and also very well understood. Same is true for any other software related problem domain.
>The external interfaces to a car hasnt really changed in a
>century and the problem of A-to-B transportation hasnt
>changed in millenia.
Had it ever occured to you that the reason the external interfaces to a car haven't changes is because somebody did a good job defining them in a first place? I can guarantee you that if they did a poor job, those interfaces would be changing like crazy. The only reason software interfaces and APIs are changing like there is no tomorrow is because people are doing criminally bad job defining them.
I would normally not reply to this sort of crap. Dont get me wrong - I respect your arguments but your clearly insulting tone, I dont care for at all. I would much rather have a intelligent discussion than trade insults. The choice is yours.
Of course further development is possible! Only a complete tit would think otherwise! However, my point was not that there would be no further development, my point was that we are chasing a MOVING TARGET!
Technology actually changes the way we do business and what we do business in (as if it doesnt change enough anyway). For a good example of this, you only have to look at an investment bank - the trading that is done today - the complexity of the products, the volumes traded, etc - is largely a result of the technology that is used.
So, on the one hand, I would agree with you: A higher level of abstraction would be excellent - and it would allow the development of business to accelerate - but my point is that there will always be a gap as business would evolve too quickly for technology to keep up with it.
| Had it ever occured to you that the reason the external
| interfaces to a car haven't changes is because somebody did
| a good job defining them in a first place
Yes it had. However, try and define a good interface to a complex financial product. You had better be quick, because in a few years, it will have become so vanilla that it probably wont be traded anymore (or at least, no-one will be making any money on it). Business changes so fast, that its nigh impossible to define a good platform for it.
Thats why I think examples like cars, houses, telephones etc are bad examples when comparing to business & software - they are examples of things that dont change much.
As a Microsoft zealot, I can say that the only thing I envy the Java world is the Jakarta foundation. I was complaining over the lack of focus on Enterprise Applications, nor the quality on the software. Jakarta software is excellent IMO - the organisation is unmatched in professionality.
And the name gives a fitting association to the beautiful Gamelan music.
Very interesting subject. TSS is a good audience, yet the solution to business problems is not in the developers court. As a developer, I do what I do best and code is my satisfaction whether the business model fails or not. This is the simple reason why we have more "plumbing solutions" rather than business solutions and it will never end. Open source tends to allow the developer vent his/her creativity that the workplace would otherwise restrict. Tools that dont allow the developer creativity when providing solutions to business needs, show no respect to their talent and effort. It bites back.
yet the solution to business problems is not in the
The above, I'm firmly convinced, is a falacy. By definition, developers are providing *solutions*. Consequently, the solution to business problems is exclusively in their court.
>As a developer, I do what I do best and code is my
>satisfaction whether the business model fails or not.
Wow, this is right down scary! It's equivalent to a surgeon claiming: "As a surgeon, I do what I do best and operating on patients is my satisfaction whether the patient's life fails or not." You, as a developer, have a moral obligation to see that the product you're developing does not fail (same as the surgeon has a moral obligation to see that the patient not only survives the surgery, but actually gets healthier).
>This is the simple reason why we have more "plumbing
>solutions" rather than business solutions and it will
Scary! With such an attitude, no wonder the entire software industry is in a major crisis. I guess we need people of entirely different caliber and orientation to get us out of this hell hole.
>Tools that dont allow the developer creativity when
>providing solutions to business needs, show no respect to
>their talent and effort. It bites back.
Is that a general threat that you cared to pose here on behalf of your fellow 'developers'?
At this point, I must say I'm speechless. Imagine surgeons (or, even carpenters for that matter) complaining about the rigidity of their tools, which don't allow them to express their 'creativity'. A surgical knife shows no respect to the surgeon's talent and effort? Why don't we try and get real for a moment here?
Alex, I want to answer that. You certainly are not a developer or else you moved on to something different already. I, as a developer, am not the surgeon that uses the tool, on the contrary, I am the tool maker. And there's lots of tools out there. Why is it scary for you to know that I enjoy my code and I do my best to deliver good code? And should my tool be good, I do have to understand what it's used for, so I'm not that lost into digging the hole. And if my fancy dictates that I should use my spare time as I wish, why would anybody care! I wrote my own PIM better than anyone I've come across and only my wife has seen it. The open source will go on. Can't touch that.
The kind of solutions that are implied here, require a lot more than developer skills. To specify a framework that truly meets a business domain, one must have enough full-time business experience that will disqualify the person to be a developer. If somehow you have them both work together, you might get somewhere. But it will never happen outside the incorporated world. Those that really know what a CRM or CMS system should be, are out there playing golf while I'm writing a new MVC. Frankly, the latter sport is more satisfying to me. On occasion, you have those guys that play golf read TSS or the like and discover the need. Their answer is new papers filed in Delaware.<br><br>
You can't blame developers. They do what they do best.<br><br>
After reading the article and Dan Winfields response, one might conclude that the failure of the project was not the quality of the tool but the golf players mishandling of it..<br><br>
You just can't blame developers for not meeting real business needs in their spare time.
This is a statement from a true hacker. He don't care about the customer - he chooses the solution that is more interesting - in his own eyes. There is no more dangerous person to a company IMO. The big companies will always survive, but it can be the death for a smaller family business.
If you study the job advertisements today you will notice a trend, the recruiters in many cases not only asking for some special language or platform, but also for experience of the problem to be solved. For instance, this week I have been contacted by three different agents looking for somebody with CRM experience for a project in Copenhagen.
They were discarding people with SAP + CRM because they wanted SAP + CRM + experience of ABAB for mobile devices! And probable got what they wanted too.
When I speak of Struts, I do not mean the Framework, but the bird that put its head in the sand. (Well I know that it doesn't really do that but you understand the gist of my speculation).
th end user of your car,
it's the user of the application and he needs the more simplified application possible which can do of course the job
but the developper is who design the car and who build it
and after whi repair it if there are problems
so he is always from head to foot
plunged in the complexity of all the stuff "behind the screen"
but of course ,
it's not a reason
not to try to make our job easier
but if we want J2EE make certain jobs ,
it needs sophisticated API
When I was young I presumed that sex was the most powerful driving force in human beings. But, as I grew older I perceived that I had been wrong, the "besserwisser" force was actually much stronger. This opinion stood me for a long time.
However, after have studing the issue for many years and consulted with various gurus I now have finally decided that "the planning fenomena" is the strongest driving force in human beings, the drive or urge or whatever you call it to sit behind your desktop and contruct large systems!
So there you have it. Quite simple really.
"So there you have it. Quite simple really."
Quite philosophic. Wise men always say, that the truth is simplicity. But then, wise men usually don't talk much. Simplicity is hard to explain. Like wisdom. Whatever it is.
Rolf: "When I was young I presumed that sex was the most powerful driving force in human beings. But, as I grew older ..."
I know I'm always disagreeing with you, but you were correct when you were young, and you should have stuck with that first instinct ;-)
: Easily share live data across a cluster!
Dude. Following Rolf's habit, the most powerful force in the world should be bugs in Microsoft software.
And how is it going with BEA's Weblogic Portal?
(Sorry, but couldn't resist)
...but we're nohow there yet, as your own post shows. There are a bewildering variety of contenders out there, each of which falls short in some ways; and as soon as you express your willingness to circumvent whichever one of them has just let you down, and "just code it" on the fly, then you have spalled off another candidate--except even less general and less reusable.
True enough that businesspeople will never willingly care about plumbing, but the day has not yet arrived when WE don't have to.
"From this we see that a lot of effort is being wasted on providing such fancy low level frameworks. Wouldn't it be better if we could harness all that talent to build solutions that would address the real business needs?"
Claim: With J2EE you does not lock up yourself to a vendor.
"JB Entitiy Beans, JDO, JDBC or some open source API. Trying all would mean you are attempting too much and everyone has different opinions on each of the other APIs"
"The number of permutations of all the underlying J2EE APIs, servers, databases, browsers and the like make it very difficult.."
"The next customer invariably wanted a different server"
And the Enterprice applications and business solutions?
The claim is valid. J2EE does not mean vendor lock-in, as a standard, by definition, it does the opposite.
J2EE gives the developer choices. After a choice is made, the developer has to live with that choice, right? It's the same with any framework, technology, etc.
Once you go for a pizza, red wine is not an option but it was YOU who made the decision to eat pizza in the first place.
I have to admit, I am having a lot of fun reading your posts...
I have to admit, I am having a lot of fun reading your
I totally agree, I find Rolf very amusing to. He is a bit like "The Mr Bean of TSS" by now...
Dan Winfield in his early post said that "RemoteApps failed because of the inability to recognise the developer as its customer until it was too late".
I would argue actually that for any technical framework (the plumbing), the real customer are the developers implementing business solutions. It is to them frameworks should first be sold.
More importantly though, when users are themselves developers, I find that the best model for satisfying them is ultimately open source. No matter how much quality service a proprietary software comes with, the ability to tweak the code is what really ensures user (developer) satisfaction. If the software does not completely satisfy their need, they can amend it accordingly.
Moreover, the fact is that nowadays most developers (at least in the J2EE community) make use of open source tools and framework, and get used to having source code and access to a community of other users/developers. Switching back to proprietary software when having tasted the benefits of open source is hard.
All this to say that in the end, it's a tough sale to sell proprietary technical frameworks. All components of the technical infrastructure layer is affected in some way by free and open source software: OS, databases, development tools etc. Technical frameworks are even more easily affected by the FS/OSS trend because all their users are developers, which is not the case for OS and databases.
In the long term, I think the best revenue model for most technical infrastructure software should be based on services. I have no idea how good was Xyrian, but if it was, then it's a pity they never had any investor like Hadar Pedhazur who's been key in convincing Digital Creations (now Zope Corp.) to make their technology open source so he can invest in them (see http://www.opticality.com/Press/Opticality/IDC20068.htm
I use open source now and RemoteApps used open source too.
I believe that the best thing about open source is the freedom of use rights granted with the license and not the source.
I have rarely looked at the source on the software I use and whilst I have met people that do read the source, I have met very few that actually change it other than for bugs.
I do contribute fixes or code to a project but I would never want to run a different version to everybody unless I really had to and even then I would want it to be a short term thing.
I am using JDOGenie for my current project and I don't need the source. Any problems and they fix it almost immediately and release. This is the type of attention to service that makes a commercial product sell against open source. If they didn't fix the problems then I would look for another commercial supplier and only then look for an open source equivalent.
This doesn't apply to every open source project, for example log4j and ant (RemoteApps designed the logo BTW). These are libraries that work extremely well first time and in their current versions seem to do 99% of what you need.
I think frameworks is a complex area that is not very well defined. Some simply offer MVC, some offer database mapping, some offer templating. Comparing and deciding on which to use is very difficult with many contrasting decisions to be made.
Our investors took alot of persuading about offering it for download. Perhaps a more progressive investor like Hadar might have made the difference.
However, what remains is a framework that is ready for someone else to pick up and do what they want with. Sell it to their existing customers, offer it as open source, give it away free with an app server, use it themselves on internal systems. It is up to the new owners.
Ps. www.hemtech.co.za for JDOGenie
It is more about having the ability to view and change the source than the number of times you will need to change it. Even if it does not happen so often that you need to change the source, the day such need arise you will feel the pain of not being able to do so, most notably when it's about adding features (and what software can survive with the same features forever?)
Agreed, bug fixing is the most common type of need/contribution. But that does not mean adding features and making improvements should not be allowed: that's what keep a software in line with its users, especially when those are developers. Accross lots of users/developers, you can bet that such need for change beyond simple debugging will arise, and free/open source licensing will make the difference for those. Once such benefits have been experienced, going back to propretary software is hard, especially when it's about frameworks.
In my experience I had to make extensions to Struts in order to fill certain requirements gap (i18n, validation, etc). If I wouldn't have been able to do so, I would have been very frustrated, and less compelled to use Struts in the future. It's just sad that my company had too much concerns with legal issues (only reflecting the lack of experience with open source), otherwise those improvements would have been part of the Jakarta Commons project.
I use quite a few open source tools, but I have so far never bothered to look at the source code. If I ever wanted to tailor the open source tool to my needs, I would rather write my own adapter classes over the tool, rather than modify the tool's source code itself.
The whole purpose of Design patterns is to be able to tailor a tool or API to our needs by providing suitable wrappers over it, and not by modifying the underlying tool or API itself.
Also as an OO developer, I find it rather disturbing that open source allows a look at the implementation of the interfaces.
When I use JDK or a JDBC API, I worry only about the interfaces available, and not how these are implemented.
Knowledge of how the tool functions, could influence the manner in which we would then design our applications, which is undesirable.
I can subscribe to your argument of avoiding white-box design. However my point is more about adding features that you need, features which often have to interact with other features already present. And that would require access to the source code, even deep in the layers of design.
Doing so with any software that is outside your circle of influence brings an additional issue that needs to be taken into account. Changing the inside of the software creates an overhead maintenance: keeping your code in line with future releases. Either you are prepared to pay this cost, or you choose not to upgrate to future releases, or you may contain as much as possible your changes by using wrappers or adapters like you say, but with the risk of adding complexity.
However, imagine you were the sole owner of the software and therefore can influence its design and evolution: would you still use wrappers and adapters? Not necessarily, because it may make more sense to develop your features within the API itself. I think it is important to be aware how much your choices are affected by the fact that you do not influence the evolution of the software you want to modify.
So what? you may say. Well, here is my point: if you use free and open source software like you are using proprietary software, then you are limiting your choices. You are forgetting that it is possible for you to influence its course by participating in its community and development. If nobody take advantage of this possibility, then indeed free and open source software is just like proprietary software, and there would be no point in sharing the source code, except for debugging.
Anybody who is considering using free and open source software should first realize what it means to have the source code. If you think it is someone else's code, then modifying it my seem undesirable because the choices you end up with are sub-optimal (compared to being the sole owner of the code). If you however think that you can share the ownership and help build the software, then you are opening up new ways for you to take advantage of having the source code. The former attitude is the easiest to make: you don't have to bother with someone else's opinion, but on the other side you don't take full advantage of the benefits of free and open source software. The second attitude is less common because it requires greater altruism and, at first, gives no certitude about the outcome. I would argue that we are so subdued with proprietary software that we often forget about this second attitude.
To come back to your argument: if you only consider having the source code as a way to understand how an API works, then like you say it is a concern, because you may end up doing white-box design which may break your application some day. But that's not the reason why free and open source software exists in the first place, you must be aware of that.
I appreciate your ideas regarding the benefits of free and open software. I am more concerned about the division of responsibility. For example, just because we assume that Apache could use a good feature, does it mean that we implemented it ourselves, or recommend Jakarta.org to implement this rather in their next releases, and we worry about the task on hand in the projects we are working on.
So my question is not "Who really changes the source",
but "Who should (be allowed to) change the source".
I can understand being the owner of a piece of software and so wanting to be able to modify it;
but that is the whole reason we have had plugins,add-ins and other extensibility features to extend a tool.
I always believed that the popularity of Emacs is not because of the available source code, but its' extensilibity features via Lisp like macros.
Many other tools I have used like Nedit, Jext, Eclipse and Visual Studio provide similar features. I personally find these extensibility features more easier than modifying source code.
I have always ensured that I never directly invoke the API or a tool, I would rather write my own proxies, just to be able to replace the tool in the future, if the need arises, without having to worry about modifications to the main application code.
I am carrying my bias as an application developer, which means I rarely buy software myself, my company buys and I use it. My company might go in for commercial or free software, but I am not particulary concerned, because I am worrying about the applications I am developing.
"the real customers are the developers implementing business solutions. It is to them frameworks should first be sold"
As a representant for these customers I would like to explain why we could not have bought this product, even if we had been aware of its existence.
There are four criteria that is necessary for us to buy any "plumbing" software:
1) It has to cost less that $1000.
2) It has to have NO runtime fee
3) It has to be certain that the company will stay in business at least 2+ years or so.
4) It has to be 100 times more stable and bug free that normal software.(because it is engineer to engineer software)
If you can fulfill all these conditions, please go ahead.
Having read several server side discussions that you have been a part of I have to say that these statements are your best.
Having spent several months after the RemoteApps closure thinking about what to do next you have hit on some interesting points that might make a successful plumbing product.
> 1) It has to cost less that $1000.
Especially if it competes with open source.
> 2) It has to have NO runtime fee
Freedom of use is a winner, IMHO. Pricing up projects and planning future costs is often a nightmare with server licenses. No runtime fees is a great way to go. Alot of the JDO products have no runtime fees, great stuff.
> 3) It has to be certain that the company will stay in business at least 2+ years or so.
Stability is important. In the case of RemoteApps our business had already been going since 1995 as a consultancy and we registered the name RemoteApps in 1997 when we first started writing Servlets. This isn't always necesarry if you can swap out the software should there be a problem, unique solutions like frameworks do have a higher risk.
>4) It has to be 100 times more stable and bug free that normal software.(because it is engineer to engineer software)
This should go with all software. If people at least tried to do this then we would be going in the right direction. I rate this very highly when choosing products.
I have some other points.
5) The product should be easy to install and evaluate in a matter of one or two hours.
Its amazing how difficult frameworks or some products are to understand when you first see them. At RemoteApps we were very aware of this when we put our product for download.
6) The software supplier should publish bugs and known issues openly to their users.
Nothing more annoying that not seeing the full picture. I don't mind bugs if they are fixed quickly and I dont waste time discovering what others already know. Honesty is an important part of the relationship. Open source wins on this in most cases.
7) Good tutorials and how tos for common tasks or uses for the software.
Invariably, most of the first things you want to do with the software is the same as the next person. Like when I download a new J2EE server and then spend 3 hours working out how to deploy an EAR file because the documentation isn't clear!
8) Excellent support systems, run by people that help you solve your problems if you have any. JDOGenie is a great example of this.
9) Suggestions for product improvements are taken seriously and if relevant included in the product.
At RemoteApps we didn't always operate like this, in fact we were only beginning to head this way but these are points that make a difference for software companies. Few get there mind you for any type of product!