For a while, I was wondering whether I was the only one with this problem, but then I saw this tutorial on JBehave, which so perfectly illustrates the problem I saw myself doing. Now, I don’t mean to pick on JBehave, or the author of this tutorial. Furthermore, this is not a particularly extreme example of the problem. Rather, the point of this posting is to show that even expert developers run into this trap.

Here is the test from the JBehave tutorial:

@Test
public void shouldProvideNotesToBePlayedInOrder() {
    TabParser parser = mock(TabParser.class);
    String asciiTab = "e|--------A3-B6-";
 
    List<Note> notes = asList(A(3), B(6));
    stub(parser.parse(asciiTab)).toReturn(notes);
 
    Tab tab = new Tab(asciiTab, parser);
 
    List<Note> actualNotes = tab.notesToBePlayed();
 
    ensureThat(notes, equalTo(actualNotes));
}

In other words, the tab’s notes to be played should be equal to the parsed notes.

Here’s the implementation:

public class Tab {
 
    private final List<Note> notes;
 
    public Tab(String asciiTab,
               TabParser parser) {
        notes = parser.parse(asciiTab);
    }
 
    public List<Note> notesToBePlayed() {
        return notes;
    }
}

Whoops! We just introduced a layer in the design that does nothing. As a matter of fact, removing the Tab class from the whole example leaves us with a design that’s easier to understand.

Mocks can be great when you really, really need them. And I’m extremely impressed by the power of mockito. But used inappropriately, mocking can trick you into creating accidental complexity and extra layers of code that does nothing.

Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests:

checkRollScoredAsCategoryGives(1, 2, 3, 4, 5, "straight", 15);
checkRollScoredAsCategoryGives(1, 2, 3, 4, 4, "straight", 0);
checkRollScoredAsCategoryGives(3, 3, 3, 4, 4, "full house", 17);
checkRollScoredAsCategoryGives(1, 2, 3, 4, 4, "full house", 0);
checkRollScoredAsCategoryGives(4, 4, 4, 4, 4, "full house", 0);

This is possible with JUnit, but a little trick. You have to construct a test suite manually and add special subclasses of TestCase to it:

 
 
public static Test suite() {
    TestSuite suite = new TestSuite(
          YahtzeeScoreTest.class.getName());
    suite.addTest(checkRollScoredAsCategoryGives(
            1, 2, 3, 4, 5, "small straight", 15));
    suite.addTest(checkRollScoredAsCategoryGives(
            1, 2, 3, 4, 4, "small straight", 0));
    suite.addTest(checkRollScoredAsCategoryGives(
            3, 3, 3, 4, 4, "full house", 17));
    suite.addTest(checkRollScoredAsCategoryGives(
            1, 2, 3, 4, 4, "full house", 0));
    suite.addTest(checkRollScoredAsCategoryGives(
            4, 4, 4, 4, 4, "full house", 0));
    return suite;
}
 
private static Test checkRollScoredAsCategoryGives(
        int die1, int die2, int die3, int die4, int die5,
        final String category, final int expectedResult) {
    final int[] dice = new int[] { die1, die2, die3, die4, die5 };
    return new TestCase("Rolling for " + category) {
        @Override
        public void runTest() throws Throwable {
            YahtzeeScoreboard board = new YahtzeeScoreboard();
            board.scoreRoll(category, dice);
            assertEquals(expectedResult, board.getTotalScore());
        }
    };
}

The code creates an anonymous inner subclass of TestCase that instead of calling all methods annotated with @Test just executes our specific test. These tests are collected in a normal JUnit TestSuite.

The test is plain JUnit and will run in Maven or your favorite IDE, just as any other tests. The fact that the suite is named after the test class will let Eclipse know where to go when you double click on the test from the test runner.

This trick can be very useful for tests of logic that calculates a results or validates input.

• If you’re using a computer, use a presentation remote. This is a cheap and easy way to make your presentation style look a little more professional.
• If you’re using visuals, try and place yourself to the left of the visuals from the point of view of the audience. In the western culture, people scan scenes from left to right. By standing to the left, they will look at you first.
• If your using visuals, place a laptop (or a monitor) between you and the audience with your slides on them. Turning to look at the slides over your shoulder seems uncertain, looking down at the monitor seems thoughtful.
• Before you start speaking, take a few good breaths. Don’t rush. And whatever you say first, “ummm…” and “yes….” should not be it.
• When you’re done speaking say “thank you for your attention”. This will trigger the primate clapping response. An uncertain ending leaves the audience wondering when they should applaud.
• Find the friendly faces. Every audience contains those few people that smile when you look at them. Use them whenever you’re uncertain an need a kick of positive energy.

There are many hard and time consuming skills required to give good presentations. The list above is full of no brainers. These things you can do with no practice and no preparations.

• 5. Your iterations do not produce anything that could be put into production
• 4. You’re not testing your work
• 3. You tasks are called “code the UI for the foo”, “update the bar component” and “test the work done in the previous iteration”
• 2. Your iterations are called “specification”, “testing”, and “preproduction”
• 1. And the top sign that you might not be working on an agile project: You might not be working on an agile project if your iterations are three months long

Happy Holidays, Merry Christmas and Happy Monkey, everybody.

Your code is worth nothing if it can’t be tested. Change your code to make it more testable.

In my last project, we used a pipes and filter architecture, with messages being passed forward through a chain of services. Most services refined the messages or broke them up in smaller services and passed them on to the next service. When they refined the message, they often stored new messages to the data layer as a side effect. To test the results, we read the generated objects back from the data layer. I had code like this:

Before

@Test
public void fileShouldCreateTransactionObject() {
    Reader simulatedFile = new StringReader(createFileContents());
    FileRequest file = new FileRequest(filename, simulatedFile);
 
    TransactionRepository repo = new TestTransactionRepository();
 
    FileService fileService = new FileService();
    TransactionService transService = new TransactionService();
    fileService.setNextStep(transService);
    fileService.setTransactionRepo(repo);
 
    fileService.process(simulatedFile);
 
    Collection<Transaction> transactions = repo.findAll();
    assertEquals(1, transactions.size());
    Transaction transaction = transactions.iterator().next(); // Bleh!
 
    // Here is the real code I wanted
    assertEquals("foo", transaction.getTransactionType()); // Whatever
}

The solution was to change the design away from the pipes-and-filters design. Instead, the process() method returns the newly created Transaction object:

After

@Test
public void fileShouldCreateRequestObject() {
    Reader simulatedFile = new StringReader(createFileContents());
    FileRequest file = new FileRequest(filename, simulatedFile);
 
    FileService fileService = new FileService();
    Transaction transaction = fileService.transform(simulatedFile);
 
    // Here is the real code I wanted
    assertEquals("foo", transaction.getTransactionType()); // Whatever
}

This new design totally violated our architecture, but it’s clearer, it keeps the infrastructure away from the code, and it’s much less brittle. Our test transaction repository used to be vulnerable to being polluted with test data from a previous run. As we no longer use this sort of infrastructure objects, we don’t have to worry about interaction between tests.

If you don’t know how to test your architecture, the problem is not with the testing, but with the architecture.

Until next time: Happy testing.

First out: Using the data storage. I upgraded our API for billing customers. I had a few compilation errors in my code, as the API had changed somewhat. After fixing these errors, I was left with a test that broke mysteriously with a MethodNotFoundException. I located the test and found that it was close to unreadable. After examining it further, I found that it was trying to do was simple, but hidden in technical code.

I had the following test (the design is real, the details have been changed to protect the guilty):

@Test
public void shouldBillExtraForErrors() {
   BillingService billingService = someService.getBillingService();
   MethodCallLoggingInterceptor interceptor =
        MethodCallLoggingInterceptor.for(billingService);
   someService.setBillingService((BillingService)interceptor);
 
   Request requestWithError = createCustomerRequestWithError(CUSTOMER_ID);
   someService.process(requestWithError);
 
   Method method = BillingService.class.getMethod("sendBillingEvent", ....);
   MethodCall[] callsToBilling = interceptor.getMethodCallsFor(method);
 
   assertEquals(2, callsToBilling);
   assertEquals(CUSTOMER_ID, callsToBilling[0].getParams()[0]);
   assertEquals(BillingCode.RECEIVED_REQUEST, callsToBilling[0].getParams()[3]);
   assertEquals(CUSTOMER_ID, callsToBilling[1].getParams()[0]);
   assertEquals(BillingCode.INVALID_REQUEST, callsToBilling[1].getParams()[3]);
}

When the parameters to sendBillingEvent changed and the test started throwing MethodNotFoundException I changed it to the following:

@Test
public void shouldBillExtraForErrors() {
   Request requestWithError = createCustomerRequestWithError(CUSTOMER_ID);
   someService.process(requestWithError);
 
   BillingFinder finder = BillingFinder.forCustomer(CUSTOMER_ID);
   finder.setBillingCode(BillingCode.RECEIVED_REQUEST);
   assertEquals(1, billingRepository.count(finder));
   finder.setBillingCode(BillingCode. INVALID_REQUEST);
   assertEquals(1, billingRepository.count(finder));
}

The lessons:

• Ask about the outcome, not about the method calls that get you there
• Avoid reflection in tests. It’s bound to be brittle
• Mocks and similar methods are overrated

(In tip #2, I will show how I preserve the data store metaphor without giving up execution speed)

Cars in Egypt, especially Cairo honk all the time. Day and night. If we woke up at 4 am in the hotel room, there would be cars honking outside. The honk to wake up pedestrians or other cars, taxis honk to attract the attention of potential customers, and often, it seems like they honk just for the fun of it.

Security

There’s a ton of policemen in Cairo, easily recognizable by their white uniforms. Most are in their early twenties. All have mustaches. Any ATM, bank or hotel will have stationed at least two policemen, usually with guns and a metal detector. Major tourist attractions will have much more (we saw a lot of policemen on the street, pluss five cars on standby by Midan Hussein). There will usually be assault shields (manned by black-uniformed police). Five-star hotels will have bomb dogs. Busy intersections have police officers directing the traffic.

And it does make you feel safer, I think. I was never afraid of being pickpocketed or mugged in Cairo. But I am not sure about the metal detectors. Nobody asks to to empty you pockets and try again when you beep. They just kinda glance up at you and resume their… watchfulness.

Curbs

The curbs to the sidewalks in Egypt are about 20 centimeters tall. I imagine this is the only reason taxi drivers don’t use sidewalks as shortcuts when the traffic is bad. The result if there are a lot of side streets is that pedestrians will constantly have to step on and off the sidewalk. Since people are lazy, most places, they walk in the street instead.

Abandoned buildings

All over Egypt, but especially on the Giza-side of the Nile, there are a huge number of what looks like buildings where they abandoned the construction before they were done. In many cases, this doesn’t stop people from living there. But the phenomenon is not limited to Giza. Alexandria, and even Dahab has a lot of these buildings. We tried asking a few locals what was up with these, but we didn’t manage to make anyone understand the question. I imagine this is the way it’s always been in Egypt.

Pedestrians

The thickness of pedestrians on streets like Sharia Talaat Harb, Corniche el-Nil (during Eid) og Sharia 26th of July was extreme. And pedestrians in Egypt are very aggressive. With the slow moving traffic of the inner city streets, they weave in and out between the honking cars without considering pedestrian crossings. Usually cars swerve organically around the flood of pedestrians if there is enough room.

There were also things I expected would be very different, but really didn’t live up to my fantasies:

Prayers

The minarets call out for prayer five times every day. You can hear the prayer calls anywhere in Cairo, and probably most other places in Egypt, too. However, I expected more people to stop up or more things to slow down during these times. In general, it seems like it’s just a backdrop for most egyptians most of the time.

Women’s clothing

Most women in Cairo, even in the central parts, seem to be wearing head scarfs. Beside this, however, most young women wear almost the same kind of clothes as in the west. We noticed a lot of tight-fitting clothing, for example. But most women cover up most of their skin.

Finally, there were a few minor surprises:

Cats

There are almost as many cats in Egypt as there are police officers. When we were sitting in the small outdoors lounge in our hotel, we saw five different cats within the same hour. In the breakfast balcony on our Dahab hotel, there were about ten. The cats don’t seem to belong to anyone, but people don’t mistreat them, either. They are usually tame, and will come up to you for bits of food or pets.

There are also many dogs that are … strays? no…. wild? .. no… independent, maybe. Most of these seem to be pretty healthy and wholesome, and they seem to like to stick around people.

Taxis

Taxis proved very useful for both long and short trips in Egypt. Usually, if you’re a westerner and you walk along a street, taxis will honk at you, slow down and say “taxi?” If you need a taxi, you just pop you head in the window and state you destination: “Midan Ramsees”. We have found it most useful to negotiate the fare before we get in. And whatever you do: You should always state the price first. So he nods and I say: “ten?” If the driver doesn’t agree, just say “maalesh” (never mind) and walk away. If your initial price was right, this often will have the driver change his price.

Signs of danger

• ‘Just’: bad word, as in “can’t we just develop the greatest application ever”, “can’t we just replace the database with JavaSpaces”, “can’t we just expose the functionality to the world as a web service”.
• ‘Should’: bad word, as in “it shouldn’t take more than a few days to do that, should it,” “integrating two systems should be easy.” Listen for use of this word from people who … should know better.

Signs of thought

• ‘Awkward’: good word as in “It’s awkward to talk to your boss (who has way more experience than you do) about teaching her agile programming.”
• ‘Why’: good word, as in “why do you need to pass two parameters to this function?”, “why are we developing a login screen”, or “why did my change cause troubles for my colleague?”

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” – Alan Perlis

This article contains some things I have learned that has made me into a better developer than I was before I learned them. There are nine tips. These are not necessarily the only, or the best things I have learned, but I like the number nine.

Becoming a better developer is a complex path. What I have found to be the most important attitude is to be versatile. Digging yourself down in one kind of activity, one “phase” of a project, one technology is a sure way to stagnate. I try to balance technical knowledge with “softer” skills. Developing software is about communicating, thinking, and programming. In order to be effective, you have to master all of these areas.

1. Accept Failure (but only settle for perfection)

“Knowing the path is not the same as walking the path” – Tao te Ching

Sometimes, you know you could do better. But time, skill or luck may have it otherwise. The most important thing to learn to be good at anything is that you will fail. But failure is okay. Life goes on. By accepting failure, you should also realize that you can always improve. Be sure that you understand why you fail and how to improve. It is better to fail fast than to kinda success very slowly – failing allows for feedback – feedback allows for improvement.

A tip to help improve: Ask a friend “what would it take to get a 10/10?”

2. Be brief

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery

“No code is better than no code.” – Unattributed

When you communicate, whether through code, documents, or emails, the more the information, the harder it is for the recipient to find what he need to know. Remove everything that is not needed: Comments that explain what the code does, sentence that don’t add to your email, code that is no longer needed, default values in code.

Besides, if you write the code, somebody will have to maintain the code as well.

A tip to help improve: “What sentence can I remove?”

3. Develop in-depth knowledge of your field

Understand which parts of your code are needed and which parts are not. What is the difference in behaviour between catching an exception in the main block, like this:

public class Foo {
    public static void main(String[] args) {
        try {
            doSomething();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

… and letting the main method throw the exception, like this?

public class Foo {
    public static void main(String[] args) throws Exception {
        doSomething();
    }
}

Exceptions are interesting creatures in Java-code. Understanding what causes exceptions and what you can do about it is very important. For those in a hurry, I give you Johannes’ first rule of exceptions:

“There’s usually nothing you can do about it” – Johannes Brodwall

Lastly, there are some basic skills that every developer should master: How to use source control, how to write unit tests and how to use continuous integration. If you don’t know how to do the first two of these, you’re not doing your job!

All tools also have default values for configuration. Recently, people have started talking about “convention over configuration” as a design principle. This basically means: Use smart defaults. Remember that configuration is also code, and that no code is better than no code.

A tip to help you improve: When you make something configurable in your program, consider adding a smart default value.

4. Don’t overspecialize

“Specialization is for insects – Robert Heinlein

There are many ways of overspecializing. Learning only one programming language is one of them.

Languages are the tools we use to think. Different languages will make you think differently. If you’re bilingual, you will probably notice that when you speak a different language, you have a different personality. I, for example, master both English and Norwegian well. (I am speaking in English now, right?) And I am much wittier when I speak Norwegian.

The same thing holds for computer languages. The language you use shapes the way you think. You will benefit enormously from learning a language that is radically different from what you use daily.

Choose a language that uses dynamic typing and that contain lambda expressions, or code blocks.

This code implements a very complex concept. See if you can understand what it does.

function getById(parentId) {
  var rs = ....;
  var parent = transformFromRs(rs);
  parent.kids = lazyLoad(
    function() {
      return kidsByParent(parentId);
    });
  return parent;
}

“A programmer should be able to find a bug, market an application, refactor a spike, lead a team, architect an application, hack a kernel, schedule a project, build a database, route a network, give a reference, implement UserStories, analyze UserStories, work in a team, work alone, use patterns, innovate, write documentation, have a RealLife, create a cool website, email efficiently, resign gracefully, AdmitIgnorance, and keep on learning. Specialization is for recruiters” — with large apology to RAH and his estate, Peter Merel

5. See the bigger box

“The easiest way to build something simpler is to not build things you don’t need. 64% of our software is barely used” – Alan Shalloway

Your problem always exists in a context. If you understand the context, you might realise that there is another, much simpler solution to your problem.

A hypothetical example: Your task is to implement a mechanism for prioritizing jobs. This is to make sure that our real important jobs complete within a minute. (The “why”) Maybe you find out that by optimizing an algorithm, everything runs fast enough, and you don’t have to prioritize. Or maybe you just buy a faster machine and you end up not even having to optimize.

Even when you cannot thing of a way to simplify, understanding why can help you create a better system, or understand your role in the organization. Why are we implementing the payment function? To make our users pay for the online ticket system. Why do we create an online ticket system? Because our relationships with xxx gives us a unique chance to offer a better service.

Look up from your computer, look around. Why is the world around you doing what it is?

6. There is only one rule of design

Get the right coupling between the parts. Two things are coupled if change to one requires change to the other. If this change seems inappropriate or clumsy, that means that the parts are too closely coupled. Overly close coupling is cause by: Duplication, faulty abstractions, inappropriate intimacy, poorly design system boundaries.

When you remove coupling, be sure you remove it, not that you just hide it. Using string (for example XML) as a communication format instead of rich objects can often hide the coupling without removing it.

Design is about coupling. The rest are details.

A tip to help you improve: “When I change this decision, what else in my system will need to change? Why? How can I avoid that?”

7. Understand the difference between haste and productivity

“Don’t just do something, stand there!” – Unattributed

The most common problem I see when something goes wrong is that people panic. Take a deep breath. Don’t panic. This is especially true for those who feel responsible, but have nothing they can do to help, like project managers.

Productivity is a matter of managing and completing tasks. Productivity guru Dave Allen outlines a method in “Getting things done” a method that I find helpful:

1. First, make sure that all that you have to do to complete your goal is written down and organized, so you can see what you have to do. For work email, I use the “flag” functionality in Outlook. For private emails, I use the gmail inbox. You goal is to get everything done. To empty your inbox. Use lists, failing tests cases, reminders, sticky notes as well, but be sure that you know the totality of your work. Whatever you do: Don’t waste brainpower remembering what you need to do.
2. When you get an item, decide whether to Do it now (if it takes less than 2 minutes, do it right away), Delegate it (but remember to follow up!), Defer it to a specific date, Do it later or Drop it

Two tips to help you improve: Make sure everything is written down and nothing falls between the cracks, and master the art of the two-minute email to keep your backlog short.

8. Implement for today

The most common root cause of problems that I see is insufficient myopia. People see too far ahead and think too far ahead. This leads to code that: Tries to optimize things that turn out not to be important, tries to generalize things that will never vary, tries to expose interfaces that will never be reused (with web services! whee!) or try to handle situations error situations in clever ways.

The problem is that code that tries to solve a more complicated problem is usually more verbose, which means that it is less robust. And functionality that has never been tested properly (for example: error handling routines) never work.

At the same time, don’t be restricted by what is there today. Delete code that is no longer needed, comments that make no sense. Learn how to discover whether code is dead or not.

9. Leave proud

You cannot always solve the problem you’re working on in a perfect way, but you should leave your code, your document or whatever you’re working on in such a state that you could be satisfied never touching it again.

Don’t leave needless boilerplate comments, name your classes, methods and variables well. Indent your code properly. Fix typos.

You could be hit by a truck tonight. What will those who come after you think of your legacy?

Finally: A word in parting:

“It is better to be clearly wrong than obscurely right” – Ken Orr [1]

1. SOA DAO tier

Distributing a program at the DAO level is someting that comes back to haunt us every few years. The DAO level is a particularly bad place to try and divide and conquer: It is a very wide interface, as it will depend on your whole domain model. While projects are in active development, the domain model will have a lot of forces on it to change. Projects are better off resolving with these forces, but having a contractual interface will make this harder. The second reason the DAO is a bad candidate for distribution is that the database already does this! In many situations, putting a DAO in a separate physical tier gives no benefit over using the database directly.

Using the database directly is supposed to be bad. SOA does not take away any of the reasons why this is bad.

Appropriate use: A SOA DAO tier is appropriate if you would want users outside your organization to have direct access to your database, but the only thing preventing you is the firewall and authorization concerns. In this case, be aware that there are forces to change domain model exposed by the DAO. These forces should be dealt with responsibly. But if you wanted to give people access to your database, you already knew this, right?
Antidote: Use SOA to integrate with other applications, not with other tiers of the same application.

2. Visual programming

Visual programming has been a recurring bad idea for over 20 years. SOA has resurrected it, but only in zombie form. The ugly truth is that the examples people use to demonstrate “the power” of BPMN are examples that turn out to be pretty simple in good Java-code, too! When you get to try and solve the hard and interesting problems, the workflows are no longer very understandable. And they will depend on code which will be harder to write, because the logic (in a programming language) is detached from it context (the workflow). Personally, I think it was the same kind of detachment that made EJBs fail.

Visual programming is a powerful image, even though it is fundamentally flawed. I am sure we will see it come back to haunt us many times again.

3. Component Specialization

“You work with that bit, and I’ll just sit over here and work with this bit“. These are the saddest words I hear on a software project. The strategy of dividing a system into components and having the developers specialize in each of their component would be a good idea if integration was easy and if component design was easy. However, the non-technical challenges of integration (“What? The ‘email’ field is the senders email, not the receipients email? But I don’t have that information here!“) will not go away by using SOA. And splitting a system into components has always been difficult to do well. The only solution I have found is the let the interface be maleable long enough that we can correct the inevitable initial mistakes. SOA projects that define a component structure and divide the team according to this structure are on the fast-track to wrapper-land.

The antidote is strangely enough related to a strong point of SOA: Organize your problems by perceivable functionality to the users (that is, services). These services cut through your application, from UI to database. A developer should be able to understand the flow through all the layers.

4. Interface with the World Early

“We develop with Web Services, so other systems can connect to us without more work.” If you haven’t designed a protocol with external use in mind (and that costs a lot more!), your interface is likely to be bad for your new users, whether it is written in Web Services, CORBA, or RPC. By opening your system for integration with other systems, you freeze the interface, which also has a huge cost, especially with an immature interface. The reason databases are the choke point for change in many organizations is because it has a potentially unknown number of systems integrating with it. SOA does not solve this issue.

If you need an interface that the world can use, you should expect this to cost time and planning. SOA gives a few tools to help you along the way, but opening yourself to the world is still something you want to consider very carefully before you do. And it will always be. Don’t expose yourself to the world unless you get paid for it. (Is that the porn star principle?)

5. The cost of technology integration

“.NET is good for user interfaces, EJBs are good for business logic [sic!]. Why don’t we use them both and just integrate via Web Services?” There are many reasons why developing a system with a large set of technologies is a bad thing. Most of them have nothing to do with technical integration.

By all means, if you have large, heterogenous systems that need to be integrated, SOA technologies will probably help you. But don’t design your system as several large, heterogenous systems yourself!

6. DIY protocol

“We have rewritten our CORBA service to only take strings as input and output, so now it is SOA“. I think I will leave that one as an exercise to the reader.

In truth, SOA has helped preventing people from creating their own protocols. There is still work to be done, though.

Conclusion

SOA doesn’t fix the underlying problems with visual programming, exposing your domain model to the world, the costs of published interfaces, or the cost of developing a system with several dissimilar technologies. It makes some of these problems more managable, but when you are designing a single system (or Service), these things are still very expensive and problematic. The focus on SOA seems to have made a lot of people forget that it will always be cheaper to develop one system than to develop several systems and glue them together. Use these technologies when there is a real, business problem to be solved by them. In most cases, my guiding principle continues to be “Don’t use it unless you really need it.”