Top signs you've missed the point of Agile

I'm currently working on an "Agile" project with a company that's trying to break from their Waterfall-based past. They're using a Scrum-like process. Even though the classic mistakes have been repeated over and over again by everyone else who's done this in other companies, and repeated over and over again within this particular company, they kept getting made regardless. It doesn't seem to matter how many people point that out to them or how often it is.

To do the same thing over and over again and expect a different result is insanity.


The snapback to Waterfall is instinctive, especially for traditional shops - especially those coming from a COBOL background. It's a very slippery, silent, and dangerous slope. It's like a recovering crack addict just getting just one hit.

Here are some of the more obvious signs you're falling off the wagon:

• Process definition and following the process is a priority over coding, testing, and delivering
• Process complexity is a frequent complaint of team members
• There's no time to make architectural improvements or do upgrades. Shortcuts are regularly accepted
• The next deadline always outranks the long-term investment
• You have tools and infrastructure that dictate your workflow and make it less efficient, that you have to alter architecture for, that you have to make allowances for
• Your developers have more meeting time than coding time (testers have more than testing time)
• Your meetings typically have more than 4 people in them
• Regularly scheduled meetings are the norm
• All of your requirements are already worked out
• Your software delivery dates and deliverables for those dates are worked out
• The software isn't considered done unless the documentation is done
• You haven't talked to your customer in over a week
• Morale is low, teams bicker, motivation is low
• The post-mortem/retrospective becomes a "bitch session"; no actual improvement ever gets made and issues continue to recur over and over again

Check out the Agile Manifesto and the Agile Principles.

For those looking to get the real advantage of Agile, you need to take on the whole thing, not just the pieces you think your company can deal with.

Practices like Model-Driven Engineering and Continuous Integration (with Test-Driven Development) are key to reducing costs, time, and increasing quality.

Top 10 Signs you've missed the point of the [Rational] Unified Process

[To be read with a drum roll and a David Letterman voice/accent:]

Here we go. Top 10 Signs you've missed the point of the Unified Process:

10. You whine about how much documentation you have to produce.

9. All the requirements, analysis, and design are done up front - but the "Construction" is done in "iterations"

8. Refactoring is not a part of the process - it's proof that you didn't get the design right early on.

7. Your project timelines slip due to scope creep.

6. You think Use-Case meetings should have every committed person on the design, development, business analysis teams, and all the end-users and other customers at them.

5. You haven't talked to the customer in over 3 weeks.

4. Testing is something you do at the end of development.

3. Integration is done at the end of the development.

2. You've left the most challenging pieces for last.

And the #1 sign you've missed the point of UP:

1. Your iterations last 3 months.

The Hitchhiker's Guide to the Java Enterprise Edition

I've been writing Enterprise Java development and architecture courseware for NextGen for over 5 years now, as well as the courses I've written for video game development, project management and other related subjects (XML, Oracle, PERL, and a few others). I've written entire curricula for JEE (JEE wiki) and Video Game development (focusing on the massively multiplayer aspects especially), and in my own mind at least have a way to get them to dovetail nicely. (Our prototype WIP MMORPG is based on a JEE backend handling NPC AI and universe coordination).

Recently I've been driving a lot and listening to a lot of audiobooks on my iPod. I went through my entire collection (which includes all 7 books of the Harry Potter series) twice. Except "The Hitchhiker's Guide to the Galaxy", which I avoided.

Now don't get me wrong - I actually love the material. I reference it many times offhand in my classes - obscure references to the number 42, comparing the immersion into JEE by a former COBOL programmer similar to the consumption of a pan-galactic gargle blaster, the usage of a Somebody Else's Problem Field as the main idiom of JEE architecture (especially the best practices surrounding MVC and the developer/administrator disconnect) etc. - to see who *really* knows where their towel is.

The problem I have with the Guide is a story of abuse and victimization. My first year of college I had a roommate - who will remain nameless but for the sake of having something to call him I shall call him Ryan Zerby - who constantly quoted the book to me the entire year. By the end of the year I was drooling as if I had been sent through the Total Perspective Vortex but also pretty much knew the entire content of the book. I therefore refused to read it under any circumstance for the rest of my life.

My friends later in life knew of my vow but also knew I would really, really enjoy the book if I had in fact read it. As my students could probably attest, I don't generally think or speak linearly. I also have a huge fondness for large multisyllabic words and inverted syllogisms. About 4 years ago, my friend Marty found a way around my vow - a loophole. He gifted me with the BBC Radio 4 version for Christmas.

When I finally gave in, I imported the entire set of CDs into my iPod and created playlists for each CD. I listened to it. At one point, I got through almost all of the third CD before I realized that I had sorted the playlist of that particular CD backwards. Ryan didn't quote me the book linearly - and the book really is a masterpiece of non-linear story telling - so I didn't know the difference for some time.

And I haven't listened to it since. Quoted it many, many times, but not listened to it. Until now. As it turns out I've been teaching a lot of COBOL programmers recently who are making the leap into JEE as it slowly replaces COBOL as the mainstay of business computing. And most of them could use a dose of non-linear thinking. Or the afore-mentioned pan-galactic gargle blaster (I often dumb this down to dropping acid, but that doesn't nearly do it justice). They're used to a sequential model of programming. JEE (formerly known as J2EE) is object-oriented, stateless, multi-tiered and multi-layered - it bounces around a lot ("like a hyper-spastic super-ball in Zero-G" according to one soon-to-be-former COBOL programmer. He forgot about the frictionless surfaces.).

The class that I had been driving to and from that had me listening to the Guide was a condensed version of one of my JEE curricula. Even condensed it's huge. They only have 3 of the 7 courses right now (they're only scheduled to get 5), trimmed down to bare essentials, and it's probably around 350 pages or so. It will probably be about 700 or so before they're done. If I condensed just that development/architect oriented curriculum in it's entirety, it would probably be around 1000 pages.

Then there is the administrator's curriculum. And the project management ([Rationa] Unified Process/Agile/eXtreme Programming oriented) courses. And then there's the supplemental HTML, JavaScript, AJAX+DOJO (Dojo Wiki), and SQL/PL-SQL (PL/SQL wiki) courses.

Almost all of these courses get continuous refinements and updates. Most are mature and receive very little (the Intro to Java hasn't changed that much as the base technologies haven't), but some receive quite a few as they're based on rapidly changing technologies (AJAX+DOJO, Java Server Faces (JSF wiki), etc.)

So in this round of changes (where I'm also changing my internal publishing practices), I've decided to bring them all together create a condensed HHGTTJEE version, which will be slightly cheaper than the original version, and of course will have on the cover the phrase (in very large and friendly letters):

Don't Panic!

[Pricing and availability is yet to be determined. We're expecting September 2008. That's somewhat realistic. For pricing, we're not quite so certain. An original swag at costs will be $3.95US plus $57,347 in shipping from Ursa Minor Beta. But that will probably change. :-)

Here's the cover page. Table of Contents will be posted shortly.
There's also a Video Game development version if demand is high enough.

Top 10 Reasons to Integrate Struts and JSF

[To be read with a drum roll and a David Letterman voice/accent:]

Here we go. The Top 10 Reasons to Integrate Struts and JSF

#10. You don't have enough letters in the acronyms in your project to make up your own alphabet.

#9. Job Security

#8. It looks good on your resume.

#7. It sounds sexy.

#6. Struts is for controlling. JSF is UI.

#5. You wanted to learn yet another set of tags.

#4. It's easier to integrate Ajax into Struts by using JSF.

#3. Because you're bored and have way too much time on your hands!

#2. You actually have a need to have a Telnet Front-End. (Or Flex, or XUL, or XAML, or WML, or ...)

And the #1 sign you've missed the point of

#1. Because J2EE doesn't have enough layers, you thought you'd add one more!

The Real Cost of IBM Rational Developer Tools

Executive Summary: IBM's RAD Tooling cost companies tens of thousands of dollars per developer per year in lost productivity above and beyond the product's cost.

We frequently get asked many questions about the state of Java Enterprise Edition developer tools in classrooms and as consultants. By far, the most often tool comparison that is requested is IBM Rational Application Developer (or RAD) (or its bigger brother, IBM Rational Software Architect, or RSA) and MyEclipse. Occasionally we get asked about the completely free Eclipse Web Tools Project. There seems to be a lot of developer frustration with the IBM tooling, including in the areas of price, performance, and features.

Please note that we are not selling any product nor do we hold stock, options, or any form of equities in any of the products mentioned. Our mission is to increase the productivity of our constituents – whether they are students or clients.



WSAD 5

Before its acquisition of Rational in December 2003, IBM introduced the WebSphere Studio Application Developer tool (WSAD) version 5.0. Earlier versions were , TTBOMK, Visual Age evolutions. I had toyed with VA and many other similar tools in the past but had judged them all “Not Ready For Prime Time.” Like most J2EE developers, I continued to us “vi” and command line tools for most of my J2EE development. Other favorites included Emacs, but basically most serious J2EE developers found that tools of that era got more in their way while producing proprietary uneditable and unfixable artifacts to tie you to one platform or another. J2EE being about open choice, most of us “just said no.”.

For reference, I was also using earlier versions of NetBeans (and Forte) for the Swing development and a few other features, but J2EE development was largely missing. Command line and text editor development was still the predominant set of tools, even if you did replace your text editor with NetBeans.

WSAD 5.0 represented a quantum leap forward. It was a heavily integrated GUI develoment environment that significantly increased productivity while producing a mostly generic set of artifacts that could be deployed to any server. While initially only supporting IBM's Websphere Application Server (WAS) out of the box, only trivial additions like a jboss-web.xml file were needed to support additional servers. The biggest productivity gains were realized by code assist (the equivalent of MS' IntelliSense technology), near-automatic key XML artifact creation and manipulation (especially the key J2EE Deployment Descriptors), automatic compilation, automatic WAR/EAR creation, and automatic publishing to a WAS server. Numerous wizards and perspectives such as the Data Tools perspective (enabling a consistent graphical tool to issue queries against the supported database servers) and the Debug perspective (enabling 3-Tier debugging!) gave serious aid to the J2EE developer. Additional frameworks like Struts were supported with advanced wizards and XML-assistance, but work still needed to be done. In Struts case, IBM was only officially supporting 1.0 and had a 1.1 beta version. Validation artifacts were not addressed. The palette drag and drop needed some further evolution. The tool was expensive – around $5,000US – but compared to the amount of productivity gained for a J2EE developer making in the ballpark of $100,000 it was well worth it. Months of messing around with XML, WAR, and EAR files were instantly vaporized.

WSAD 5.1 and XDE

Still, WSAD 5.0 was not perfect. It had many bugs, including nasty memory leaks and other quirks and misfeatures. Hot-replace of server side code was fragile at best, and frequently required expensive WAS server restarts. Republishing errors were common, sometimes requiring deployed packages to be un-deployed and re-published. WSAD 5.1 fixed most of the critical issues and was considered a very good tool by most compared to its peers. Still expensive, but still well worth the money to serious J2EE developers.

Around this time, and just before the IBM purchase, Rational introduced a WSAD (and MS Visual Studio) plugin called “XDE”. XDE was the first attempt at a Model-Driven Architecture and Development tool (MDA/MDD). The idea was very simple – take a UML diagram that describes your system's architecture and have it generate code from existing templates. Modify or tweak the code by hand where needed and the tool should be able to automatically update the UML model (this is called “Round Trip Engineering”). In a practical environment, you needed to have a UML documentation package anyways. Getting it to do most of your coding for you following well-defined templates and practices – quicker, easier, cheaper, and higher quality – was a serious boon. This plugin attempted to realize the best practice of visualizing your code as well as keeping the documentation in sync with the code – something that had always been nigh-impossible to achieve before. This tool was a great idea but in practice never lived up to its marketing promise. Great academic proof of concept, but definitely not ready for prime time. The plugin itself was also very expensive – around $5,500US just for the plugin. To use it with WSAD, total tool costs were over $10,000US, which was about 10% of a J2EE developer's salary. Still, warts and all, significant productivity gains could be realized – as much as 5-6 months or so if the developer was experienced enough with the underlying technologies and patient enough to beat the tools into submission to get them to do what he or she wanted them to do.

RAD 6

After 5.1, IBM brought the Rational development team on to WSAD development and XDE integration for version 6. The tools changed names a bit – WSAD became Rational Application Developer (RAD) and the integrated WSAD+XDE became Rational Software Architect (RSA). Version 6.0 was released in May 2005 at a hefty 1.8GB, along with re-introducing many of the bugs that had been fixed in WSAD 5.1. Several wizards were removed, deprecated, or made extremely difficult to find, including several Struts tools that had been widely promoted by IBM in the previous generation. Struts support, which continues to be widely used to this day in the financial services, airline, automotive, and defense industries (among other similar mom-and-pop industries :-) stagnated. The highest version IBM has ever supported as of this writing was Struts 1.1. The rest of the world has moved on years ago to Struts 1.2, 1.3 and 2.0. In its stead, IBM selectively and exclusively pushed the strength of its JSF (Java Server Faces) tools. JSF was an evolving standard at the time – about to be included in future JEE versions. RAD 6 required about 3.8GB of patches (over twice the size of the original release) to be stable enough to attempt to use on a daily basis. Interestingly, RAD 6 shipped with Eclipse 3.0 as its core – even though version 3.2 was about to be released about a month after RAD 6 (Eclipse versions are released consistently at the end of every June). Subsequent patches failed to include updates to newer versions of Eclipse – which was about 2 years behind the current version at RAD release time. Fighting with the tool and its bugs became the norm – not the excepOverall productivity was significantly less than previous versions – many corporations continue to rely on WSAD 5.1 to this day rather than “upgrade” to RAD 6 or RAD 7.

On the positive side, IBM dropped the pricing of RAD to around $2000/year and RSA to around $3000/year. You can still purchase the product outright like before for around the same price. Considering the biannual release schedule, it's about the same price.

RAD 7

RAD 7 was released at the beginning January 2007, at an original size of 5.5 Gb. Quickly doing the math, it looks suspiciously like RAD 6 with all the patches already applied. Overall performance didn't seem to be any better – the same sluggish feel of RAD6 with patches continued in RAD7. Support for Struts was clearly dying on the vine and saw no improvement since the previous version. Even the touted JSF support seemed to not have improved at all, despite nearly two years since the previous release and some truly exciting things happening in the JSF space – including being officially included in JEE5.

The current patch set to bring it up to 7.0.0.5 is 1.8GB. (Total size for the those doing the math: 7.3GB.) Proponents of this tool assure me that it is now in fact a stable tool. My initial findings don't concur, but I've only had minimal interaction with this recent update.

RAD 7.5 is currently in beta, with a scheduled release of around the end of 2008. That's putting a release about every 2 years.

Bloated tools and Sit and Spin

One of the more difficult things to measure is the “sit and spin” time. Times where the UI is unresponsive due to a large number of background workspace tasks (such as builds and XML validations). You can disable automatic builds and publishes on RAD (which even IBM recommends in order to gain better reaction speeds), but this largely defeats the point of the tool in the first place. Similar tools also exhibit some “sit and spin” times, but are orders of magnitude less invasive.

Interrupting your Feng Shui

J2EE developers frequently publish to their server. Very often this requires a server restart, as the server wants to hold the in-memory copy of your application in-memory – even though it's received a new copy of the application on disk. Some servers hold onto the memory copy more aggressively than others. From a developer's perspective a tight hold is detrimental because of the frequency of changes made. WAS 6 has a switch to enable a more aggressive release, but even with this switch a J2EE developer will go through about 6-10 restarts a day while in heavy development mode. WAS 6 server restart time is measured typically in minutes – around 3-5 minutes for a server with minimal applications installed, or around 20-25 minutes for a WAS installation with something like WebSphere Portal Server installed. Imaging being in the “groove” of coding – focusing – developing – and then all of a sudden you realize that a server restart is required to see the latest batch of changes. At any where from 5 to 25 minutes, your “groove” is broken. You might as well get a cup of coffee. Or a pot. Maybe check your email, the latest scores or YouTube video. Whatever it is you're doing at this point doesn't matter – your feng shui is fenged. Even when the server finishes its restart, you're going to have to get back “in the groove”, and this might take significantly longer than the server start time.

Comparably, Tomcat 6 starts in milliseconds (around 600-800 for most modern PCs). JBoss 4.x is around 18-30 seconds. Of course, installing more applications and components will increase that. My fully loaded JBoss installation with my key 6 development apps, Alfresco, Seam, and all the database connection pools and queues takes 45 seconds to start. That includes JBoss Portal server.

Eclipse

The Eclipse core that IBM donated to the Eclipse foundation is OpenSource and the basis of a good number of tools, not just RAD. Adobe's Flex development environment, CompuWare's OptimalJ, and MyEclipse are just a few. The core includes support for Java Standard Edition Development. Honestly, the Java editor and debugger with built in code-assist (again, MicroSoft calls this IntelliSense in their Visual Studio product - they've had it since VB5, we just got around to conceptually stealing the feature from them around 2002) is the reason I switched from my primary tools of vi and NetBeans (I still use NetBeans in an alt-tab fashion until plugin-in compatibility is achieved - it's much much better at Swing, OpenGL, and MicroEdition, among other things). I still have issues with Eclipse - in particular I think the SWT widget set is architecturally a horrid piece of dung that is antithetical to everything we love about Java, but those issues are worth working with.

Eclipse has been released consistently at the end of every June for the last 6 years. The last several years they've also included a simultaneous release of popular plugins like C/C++, Web Tools, Testing and Performance, UML/Modeling, Reporting, Data Tools, XML, and many more, making as complete a tool environment as RAD itself. They've been naming the simultaneous release after the moons of Jupiter – Callisto was the first in 2006, Europa was last year (2007). June 2008 will bring us Ganymede. If memory serves, there are 16 moons total for Jupiter. Obviously they plan on doing this for a long time.

Aside from being a great OpenSource project, it is a great model for iterative project management. Doing what they do inside of a tightly controlled corporation would be challenging enough – doing it with a worldwide cast of volunteers is nothing short of awe-inspiring. I think NASA and Google are going to hire the team for the next moon landing.

MyEclipse

MyEclipse brings together a number of OpenSource projects together, such as EasyStruts and AST Wizards, their own version of server control, and a few other pieces. They clean them up significantly, along with adding a consistency that's impossible to achieve by just coupling the projects together yourself. They include support for most J2EE development tasks, including Web Design, JavaScript and AJAX development and Debugging, very up-to-date Struts 1.x support, JSF Support, EJB Development, and much more. There is a half-baked attempt to port the Matisse Swing Editor from NetBeans, but it still hasn't arrived. The Professional Edition includes UML and some limited MDA/MDD support and the ability to reverse engineer Oracle databases, triggers, and PL/SQL procedures. MyEclipse Blue – due to be released this Spring (2008), is a direct attack on IBM with WSAD 5.1 holdouts who don't want to upgrade to RAD6 or RAD7. It puts a little more focus on WebSphere connectivity.

MyEclipse has been my tool of choice since I gave up on RAD6. I've been using it since version 3.8.4 – and while I found it a little wanting back then compared to WSAD 5.1, they've consistently updated the product every 6 months or so and are right on top of new features.

Noticeably different between the tools is the installation size. For two products that are very comparable in features, MyEclipse Professional ships at 250MB. There are a few MB of patches to download to get it up to the latest patch level, but they're optional and only take a few minutes to download. RAD 7.5 is 5.5+1.8GB to get to a stable usable version, or 7.3GB. Even if you add the full WAS 6.1 server and the C/C++ features that RAD has – even if you add all of your favorite moon of Jupiter (Callisto/Europa/Ganymede), MyEclipse weighs in at less than 1.5GB. Runtime memory requirements are similarly fractional – MyEclipse runs well in 256MB to 384MB of memory with the embedded Tomcat server. I'd recommend 512MB if you're going to run JBoss with all the bells and whistles (Seam, Portal Server) and an Oracle XE or MySQL instance. Of course with all things Java, more RAM is better, but it can run under these circumstances. RAD7 recommends at least 1GB. 1.5GB is minimum if you're running WebSphere Portal Server. Make it 2GB if you want OracleXE.

The real RAD-killer – aside from the fact that it actually works out of the box – is the price. Regular edition is $30 for an annual subscription, Professional is about $60, and the Blue Edition is scheduled to ship at $149.

My only real problem with MyEclipse is that they're not OpenSource. They use a lot of it, skirt the GPL/LGPL to the point of disbelief. I don't mind paying for software – but I do want the ability to improve it or customize it by writing my own plugins and then to see the improvements go back to the rest of the world. I was an OpenSource convert in 1989 – way before it was “cool”.

Eclipse and the Web Tools Project

After RAD 6, IBM also donated a piece of their server control mechanism to the Eclipse Foundation. This was coupled with other donations to become the Web Tools Project, which can be plugged into the core. The first few versions were very light on features and functionality - like most OpenSource projects - but over time it has been maturing to the point of surpassing the commercial software. (Most OpenSource projects that survive their "infant mortality" will do this - look at the Gnu Compiler Chain/Collection - it is arguable if you can even buy a better compiler than this bedrock of modern software development.)

Web Tools is on that cusp. I'm currently beta-testing Web Tools Project 3.0 under Eclipse 3.4 (Ganymede) due to be released this June, and so far I'm very impressed. I'm not likely to renew my 18+ MyEclipse licenses when they come up in May.

Web Tools 3.0 (currently M5) includes support for EJB, Web Services, JavaScript/Ajax, JPA persistence, JSF, and the Server control.

Not all of these features are in the Web Tools 1.5/2.0 plugin we used in the quantification.


Quantifying the Difference

While the difference between tools is instantly visible qualitatively to anyone who has seen the tools in operation side-by-side, a quantitative analysis is often more compelling to decision makers – especially when the difference is spelled out in the most important factors – time and money. (We'll assume that the quality of output is a function of the developer, not the tool).

For the sake of this quantification, we recorded the development of the same application on IBM's RAD 7.0.0.5, MyEclipse 6.02 with embedded Tomcat 6, and Eclipse 3.3 with Web Tools 2.0 and Tomcat 6. We also did final deployment to JBoss and WAS 6.1 inside of the MyEclipse and Eclipse+Web Tools installations. We also compared Eclipse 3.4 + Web Tools 3.0 - both of which are pre-release software - but just as an interesting comparison. We wouldn't seriously recommend anyone use pre-release software for production development. We may do a future update of this report with RAD 7.5.

RAD 7 has no support for non-EJB JPA oriented persistence such as Oracle's Toplink or Hibernate, so we substituted EJB 2.0 Entity Beans instead. This is a significant architectural change from lighter weight JPA persistence, so we also included a hand-developed Hibernate project (which significantly disadvantaged RAD from a development time perspective, but we felt it was important for architectural comparison sake – apples to apples so to speak.) IBM's SDO could have been used as a possible alternative, but we are not aware of any significantly sized J2EE shop using this tool in production.

The same developer (Calvin Vette) was used for both tools to eliminate experience inconsistencies. Mr. Vette's bio is available at the link referenced below.

[Article Truncated. Contact author for details.]

IT Is Dead

IT Is Dead. Long Live IT.
The Revolution is Coming.

IT is undergoing a radical transformation, especially in the United States. Over the last decade, we’ve seen the Internet revolution, the Dot.com bubble burst, the Object-Oriented paradigm shift, the evolving Model-Driven-Development paradigm shift and now mass outsourcing of jobs to other countries. We’ve seen development frameworks such as J2EE and .NET grow exponentially in their complexity and the services they provide and offer. We’ve seen server farms and clusters and the hosting service providers that manage them all for you off-site. We’ve seen massive development tool changes that leverage all of that nearly automatically. What does all of this mean for Information Technology as we know it? How is this going to impact our careers, our society, and our economy?

Development over the years – the Paradigms Shift

Over the years, we’ve had three major paradigm shifts in the development side of the industry. We’ve had major shifts in the infrastructure architecture as well.

The original development paradigm – the sequential paradigm – involved linear programs. This paradigm dates back at least to the early 1800s, and is still used today. The procedural paradigm was introduced commercially with the C programming language in 1970, and offered the first real reuse of code in the form of procedures. The object-oriented paradigm really hit the streets in 1987 with the introduction of C++, and delivered the promise of reuse that began with the procedural paradigm by creating self-contained objects – a combination of data and code to operate on the data – that can be extended by other developers. This is the paradigm we’re in now – Java and the .NET languages are all object oriented languages.

On the infrastructure side, we’ve seen monolithic architecture – all the work was done by a single computer, usually a mainframe – evolve into client-server, where some work was performed on a PC networked to a database server. In the early 90s, we saw the introduction of the web server and browser, which gave us a 3-tier environment – browser, web server, and database server. Adding in an application server between the web server and database server to handle business logic for both web server clients and traditional clients (such as VB Forms or Java Swing clients) led to a 4-tier environment, but 4 quickly became more so we called it the n-tier architecture. The “n” typically means 3 or more in this case. Server to server communications across the Internet – especially between companies – uses standard XML based Web Services.

Development Today

The modern Enterprise Developer uses high-level Model-Driven Architecure (MDA) tools – such as Sun’s Enterprise JCreator, IBM’s Rational Application Developer, CompuWare’s OptimalJ, the OpenSource (tm) AndroMDA or Microsoft’s Visual Studio.NET – that inherently know how to exploit high level frameworks, design patterns, and object-oriented components at the lowest level to quickly produce n-Tier applications across several servers – including vendors and suppliers servers accessed across the network. Writing database driven code is out – that’s handled done by the framework. Web pages aren’t written – they’re assembled using best-practice driven wizards. Application flow isn’t determined by code – it’s modeled in UML and generated by the tools.

That’s the state of the art today, but many shops are using older techniques – manual, hand-driven techniques that are cumbersome by today’s standards. They don’t see or can’t imagine themselves using the state of the art tools. They’re faced with rising IT costs and the option of outsourcing IT to another company or another country.

Development Tomorrow – the Next Paradigm Shift.

So if that’s the state of the art today, what’s the next paradigm shift? If you look at the time lines, we’re just about due for the next paradigm. If you look at the state of the tools today, they indicate we’re really on the verge of another breakthrough. So what is the next step?

At the level of automation that’s possible today, the next probable paradigm is self-generating code. Tools will evolve so that they need direction on what needs to be accomplished, but exploit the high-level frameworks and design patterns that have proven to solve most business needs in the past and be able to choose them. Pundits have been saying this for years but up until now it’s really been the realm of science fiction. But now the tools are close. Some might even argue they’re already there. The last missing components are data about the successful and unsuccessful implementations of various design patterns under certain situations and expert-system wizards that drive the “development” process based on that data. Right now that information is stored in the brains of a handful of senior system architects. The tools need background data on which patterns and frameworks work most effectively and under which environments. Using this data, expert systems can collect data from the “developer” about what the business process looks like, the type of data to be collected, and the services to be provided. The rest can be auto-generated, assembled, packaged, and deployed to your n-Tier architecture – the one you’ll be leasing from the hosting company.

[Article is truncated. Contact author for details.]