Architected Rapid Application Development (ARAD)

I read in Computer Sweden about Architected Rapid Application Development, or ARAD for short. The article is most likely an adaptation of this article in ComputerWorld (another IDG rag), which says that

[ARAD] software uses patterns that can serve as building blocks to generate common parts of an application – a user interface or a set of business rules, for example. Architects and senior designers can build their own templates, which can then be reused by programmers to automatically generate large chunks of code.

Because the tools often generate as much as 80% of native code, developers can add business logic and complete applications faster than they can with traditional development methods, according to industry analysts and users.

Writing less code by generating more code, rather than writing less code by actually writing less code.

One thing I particularly liked in Hunt’s and Thomas’s The Pragmatic Programmer (also read last year, but forgot to list it), is their discussion about generated code, and about which code is the code, and which is merely generated.

First of all, Hunt’s and Thomas’s guideline is to never use code generators that produce code you can’t understand.

In the article, Compuware’s OptimalJ is mentioned. I have seen hideous OptimalJ generated code. Now, Compuware’s tool is intended to generate code, which you then can add code to, “by hand,” and then have the tool read back again. So you can draw boxes and arrows, generate code, add a little yourself, read it back and the boxes and arrows, as well as your hand-written code, is preserved. But I know of at least one project where the tool was used initially, and where the programmers suffer daily pains having to wade through methods that are hundreds of lines of code, sprinkled with placeholder comments that are supposed to help the tool distinguished generated code from the one written by mortals.

Anyway. Hunt and Thomas doesn’t reject code generators, though. Rather, they embrace automation, which includes generating code from a source – which might be code in some other language, or a database schema, or something else. But, the important thing is to know what is the source, and that you should be able to throw all generated code away, at any time, and generate it again from the source.

This raises the question of which code is generated, and which is the ”source code.”

A common scenario is having a database, and classes that represent rows in the tables of that database. Some platforms have descriptions of how tables map to code. Some platforms can generate both the database and the code from these descriptions. (Some get rid of the mapping altogheter.) So what is the source? Is it the database? Is it the mapping description? Is it the code?

Sometimes, you can just pick one (say, the mapping description) and then decide that the others (the database schema and the classes representing tables) are generated and should be possible to throw away and generate again.

At other times, you have no choice. Probably it is the database – one that several other systems depend on as well, so you can’t treat the schema as reflecting the code. The code must reflect the schema. Then try to generate the mapping description, or you’ll have to manually keep it in sync whenever the schema does change. Mapping descriptions often repeat what is already in the database – NOT NULL for one of the columns, and “Allows Null Values: No” in the mapping. Also try generating classes as well. These usually just repeat what is already in the schema and in the mapping: firstName VARCHAR (50), “First Name is a String with up to 50 characters,” public String getFirstName().

Why do you do this? To avoid repeating yourself! Why is repetition bad? Well, for every tiny change, there are three or four or ten other places to change.

If every change causes a string of semantically equivalent changes, ask yourself whether you can generate that code from the code you changed first. Or even better: can you get rid of it completely?

One thing I dislike with this trend, is that the tools seem created with the fundamental assumption that developing software is doing analysis first, then designing based on what analysis taught you, then just turning the design into code. Most of the bad software produced today wouldn’t have been as bad, or bad at all, if only they had analysed a little, designed a little, coded a little, and then deciding whether that worked or not, then starting over again.

“It’s generating the portion of the code that the programmer doesn’t have expertise in – code that the middleware or technical architect knows,” says Michael Blechar, a Gartner analyst and co-author of [a report from a study that “noted” that ARAD tools improved ROI by up to a factor 15; probably this one]. “Reliability and quality of the code is much, much higher than [it is with] hand-coding.”

Oh well. According to Gartner, ARAD is the next big thing. So we’ll probably see much more of this.

“This … is like outsourcing internally,” [Locus Systems general manager Richard] Blais says. “It’s like having Bangalore in a box – it gives us that much of a competitive advantage.”

Those code-generating Bangaloreans again.

The above was posted to my personal weblog on January 26, 2005. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)