Posted by n_alex
on May 27, 2004 at 10:33 PM PDT
So far I've discussed some cultural conflicts, differences in vision and how the Java and Microsoft communities differ in their relation to small clients, small vendors and the Open Source community. Today I'm going to divert a bit from this track and discuss a family of architectural principles I learned at TechEd, and how I think they might help J2EE architects and software developers continue to improve their productivity.
One of the major themes at TechEd this year was how to increase productivity. The marketing slogan was "Do More With Less". Early on, I mentioned how Microsoft's Visual Studio tools give them an edge on the Java community. This isn't because Java can't have tools that are just as good as Visual Studio, but it's because the collected principles that lead to the development of those tools aren't a conscious and explicit focus of our community (at least not from what I have seen).
The principles aren't rocket science either, and once you see them you'll know that most if not all of us are aware of them all at some level, but this is not the same as the explicit, direct focus I see coming from the Microsoft development community. I liken it to our focus on eXtreme Programming or Agile Development principles, of which the Microsoft development community is just becoming aware.
These principles, perhaps better thought of as best practices, revolve around constantly and intentionally raising the level of abstraction in building software solutions, using more patterns and more frameworks for increasingly specific problem domains, grouping software into product lines and using component assemblies and code generation. It isn't any one of these principles that we need to pay more attention towe must practice them all at once, the way we practice agile development or extreme programming.
The singular end goal of these principles is to identify and develop Domain Specific Languages, high level abstract languages that help us illustrate and discover patterns in our software, in our business processes and in our development practices. Domain Specific Languages can help us write frameworks for dramatically improving our productivity when developing solutions for specific, narrowly scoped aspects of software development.
Domain Specific Languages contrast with UML in that they are highly tuned to a specific aspect of business or development, and they can more easily be used to configure underlying frameworks or generate code for specific families of software components. What I'm talking about here are tools and frameworks for writing software solutionsnot just for writing software code. They needn't necessarily be graphic-based languages. For instance, Groovlets are a perfect example of a domain-specific language for abstracting and speeding up the development of Java Servlets.
But Domain Specific Languages should help reveal patterns in the creation of software components, and those patterns should be able to be summed up into even higher level Domain Specific Languagesperhaps a graphic or symbol based language, or perhaps not. The important part is that we continue to explicitly push for more abstraction in our tools, in how we represent the code, business concepts and development processes.
In the session I attended on Domain Specific Languages, quite a bit of time was spent contrasting them with the UML. DSLs can be customized for any problem domain, they can be developed by cooperative organizations or built by single companies and made popular through use before becoming officially standardized. DSLs, because they are more finely tuned to specific problem domains can more easily be used to generate software code, whereas trying to accomplish MDA with raw UML repeats the mistakes of CASE tools. This is not to say that the UML is worthless, though. It is great for quickly expressing basic development concepts and for documenting different areas of development.
No tools are perfect for everything, and DSLs not only acknowledge but actually embrace that fact. DSLs provide ways to express, model and develop very specific problem domains, because at the end of the day, improving business productivity is what computers are for. Can you imagine if a company tried to build a single tool that could be used for working on every aspect of an automobile engine? Or for building a house? There are millions of highly specialized tools for performing every type of job which can be done, and they are all very carefully tuned for their own specific problem domain. Software development tools are no different.
I thought the presentation on this topic was great, and I'll hopefully be able to more explicitly apply these principles as I work on development tools in the future.