All I hear about all the time is how valuable testers are. At the Better Software Conference, everyone was thinking and talking about Testing. Whether it was Automated Unit Testing or Customer Acceptance Testing, everyone was thinking about Testing. Well, I completely disagree.

Testing is useless and there's nothing of value gained from it.

First of all, you've all hired the best and brightest developers there are in your field. Most companies talk about hiring the "Top 1%" but you really did it. Their code always turns out flawless the first time around, congrats.

The entire CaseySoftware site has recently undergone a rennovation. If you notice any oddities, bugs, or annoyances, please let me know. Yes, I am aware of the formatting oddities.

As you might have noticed this morning, the launch date was not met. Although this is never a good thing, I thought I would use it as our own retrospective.

Some pluses:

First, the overall site design was great. I'm very happy with the narrow(er) three column layout. The core of it came from Open Source Web Design. The designer has had it mostly complete and just waiting for this conversion since the end of May. Having everything with the same look and feel is already simplifying things.

For those of you not keeping up with my current events and noticing the silence on this blog, I am out of the office this week attending and preparing to speak at the Better Software Conference.

So far it has been an excellent experience and I've managed to meet and talk with some great people ranging from Jean Tabaka from RallyDev, Alistair Cockburn, and Robert Galen. I will be writing up day by day coverage starting this evening.

I've been working on a project for one my biggest customers now for many months. The system is huge, has automated a huge amount of work previously done by hand, and quite a bit on its own depending on specific business rules. One of the things it does is pull together various bits and pieces of information and puts it together into a single item for further processing.

The difficulty has been that there are so many rules, so many different conditions, and a variety of other things that affect the output, it gets to be quite difficult to test and preview the items. On Tuesday, I had an idea... AJAX.

There are two primary pieces of data that form the core of everything else. One is automatically generated from data coming into the system. The other is user-configurable on a case by case basis but has some default values.

Therefore, I built a simple preview screen, both for the default values and the complete object. It simply pulls all the pieces of the object and displays them similarly to the final output.

It doesn't do anything complicated at all, but what it does do makes the users feel good. It shows the Customer what they can expect to see if they continue on with the values they've selected and most importantly it allows them to see the their changes reflected in realtime. The power of this has been amazing.

After only being deployed for an hour, an interface previously called "clunky" has been called "beautiful" and "elegant". All of this from a bit of simple AJAX that took 3 hours to write, test, and deploy. Where's the downside?

For those of you just joining us, CaseySoftware has specialized in integrating Open Source applications. As a result, we've been working with some of the best systems in terms of Project Management, Customer Relationship Management Systems, Content Management Systems, Issue Tracking Systems, and a variety of other systems. [We're biased towards dotProject, SugarCRM, and Mantis, but other people may choose other things.] One of the interesting aspects which we have come across over and over again is that most of our customers want all of these applications rolled together into a single User Interface. I believe that one of the core problems of all these ERP (Enterprise Resource Planning) solutions is the fact that they assume that all users want all the functionality and all UI. A given type of user does completely different things with the same piece of data than another type of user and therefore should have an interface and set of tools customized to their own needs.

First, let's completely get rid of the idea of a single User Interface. That's not what we're really looking for anyway. Your salespeople care about, monitor, and cultivate the sales pipeline. They are intimately involved with every step in the process. Your company's CFO cares about the sales pipeline also, but they probably don't care about the individual interactions that happen with each and every customer. Your Project Managers care about the sales pipeline too, but they're looking at it from a Resource Management point of view. There is no reason in the world these people must use the same interface.... but they do need access to the same data.

Next, let's remember that there are dozens of stovepipe systems out there each holding vital data that we simply can't replace. Without exception, every company or organization I have ever worked with has had a multitude of these systems. Some of them are marvelous in terms of design, functionality, and forethought. Others have been sinking ships from day one. Without the budget and time to replace each of these systems, we must gather this information in order to provide a complete picture of the situation.

Finally, what are our real goals? I believe the goal - especially with laws like Sarbanes-Oxley - is to provide a complete status of the organization in order to give the public, shareholders, auditors, corporate boards, etc a sense of safety and assurance. The more information which can be compiled and presented in meaningful ways can identify problems earlier and with more detail. The value of this law aside, it makes everyone get the warm and fuzzies.

So let's break some rules:

We need to trash two ideas. First, the idea that we're going to get all the users into a single system is absurd. The massive requirements, customizations, etc will require more time and money than most organizations have. If the time and money are available, it doesn't solve the problem now, it solves it at some arbitrary point in the future. Second, we already know that different users need different pieces of the same data presented in different ways.

Therefore, I propose that existing systems should be kept in place but data synchronizations should occur between them. This will leave users in systems they already know and love, but can provide all the information to the relevant people... now we just need to figure out how to do it.

Over the past 5-10 years, nearly every organization - private or public, small or large, commercial or non-profit - has developed their own little systems. Some are quite simple and are nothing more than an Excel spreadsheet with a few embedded financial calculations. Some are quite advanced and consist of ERP-like full blown desktop applications which can handle a multitude of different aspects, users, and reporting procedures. Regardless of the underlying technologies, some are quite good and others are simply bad, but we - as software and systems developers - have to acknowledge the three underlying aspects of these systems:

a) they encapsulate the business rules of real users,
b) the tools are already familiar to the users, and
c) the users are already invested in the system

Whenever you are working with or deploying a new system which could replace any functionality of the previous system, you must consider these aspects. Failure to do so will damage your efforts... no matter how "bad" the old system is.

First, previous systems encapsulate the business rules of real users. This is a huge aspect that the requirements will almost never capture. Simply asking "how does your current system work?" will not get to the underlying rules. This is where you need to drag specific scenarios out of the users, determine what is meaningful data, and determine what the existing system would do with those inputs. If the user says, "when I put 1000 in this field, it should show 10000 in this other field", don't just make it do that! Figure out why the system does what it does.

At this point, the rules of "Add 9000 to field X to get field Y" and "Multiply X by 10 to get Y" are both equally valid. We need more example data to determine the actual rule. If we commit to either one at this point, we're going to look foolish when the customer says "The system should give me 81 when I put in 90! The old system never made mistakes like this!" [As an aside, this makes the actual rule (X/10)^2. While this is a contrived example, you probably see my point.]

If you're thinking "Wow, then I could write Unit Tests!", then you're on the right course.

Next, users know how to use the existing system. The users know what particular set of key commands they need to perform to take them from one screen to the next or from the general forms to the own. I was once working on replacing a DOS-based application that moved so slowly that a proficient user would key in a set of commands to get to their screens and wait for the system to respond. The point is that they knew the system so well that much of the UI became obsolete and was never even seen. Making something pretty is nice, but misses the point that anything that doesn't speed along user in what they're trying to accomplish is wasted. AJAX is one of the latest examples of this. People want to use it for everything, but as I've noted before, if it doesn't assist the user, don't do it. Gmail is a system which breaks down many of the old patterns, but it does so in a way which serves to assist the user.

Avoid breaking old patterns if you can, but if you must, make the new pattern better, faster, smoother by the users' standards, not your own.

Finally, the users are already invested in the system. Whether you like it or not, the users have used the system for N years before your new one. This is why we call them "users". This means that unless the system looks and acts just like the old one you will face resistance because they've already been trained and users don't like to change. How do you combat something like this? Get the users involved early in the process and get them invested. When they give you feedback on screens, on functionality, on colors, consider taking it. It doesn't take much to either make the change or determine why it can't be integrated. Even if it's not possible, being able to say "I'd love to do that, but Department X needs that functionality for their workflow." This opens the discussion for comparisons of workflows because maybe things are quite as similar as you believed.

In addition, each group of users can have their requirements and concerns addressed much earlier in the process. Just because the requirements say one thing, doesn't mean they reflect reality. An actual user may be doing things in a faster more efficient way that makes sense to them OR in a way that is slower but yeilds better results in their situation.

These three aspects of stovepipe systems must be considered. The next time you're working to replace one of these systems, take these aspects into account early in the process. Successfully covering all three will allow the new system to have support from the users because it will take into account their requirements, their usage patterns, and ease the psychological transition.