The situation warrants an analytical approach to the decision. The bottom line will be “Does the CASE tool provide a value to the business?” Often, management will want developers to adopt a methodology or tool because they have heard good things about it, regardless of how well it fits into the current processes and culture of the organization.

If your employer has asked you to look into CASE tools, as ChrisF points out, you should oblige (this is a workplace issue, not programming). Some factors that would affect the adoption of a CASE tool include:

• For which of your processes are there CASE tools available,
• An estimation of how many person-hours would be needed to adopt the new tool(s),
• How would the process(es) change with the adoption of the new tool(s),
• or What kind of positive (or negative) impact would be measurable from adopting the new tool(s)

Think of this as an opportunity to upgrade your development environment and processes. It may be that your current processes are a perfect match for your organization’s culture, but you owe it to your employer and your team to do the appropriate research.

Yes you should start researching CASE tools.

1. Because you need evidence to back up your assertion that they won’t help. You never know, you might find that they will help.
2. Because your employer told you to.

I won’t repeat the points laid out by David Kaczynski in his excellent answer as they are exactly the steps you should follow.

It seems like a big paradigm shift indeed from Agile to CASE/MDA oriented development with code generation. Not necessarily from a project management point of view (a CASE approach won’t conflict with the concepts of iterations, user stories, quick feedback or continuous improvement) but definitely so from a “software craftsmanship” perspective – it means less control over the code produced, generated code that will probably be unreadable, rigid, harder to test, constantly in need of sync with the model, and so on.

From what you describe, what your employer needs is easily understandable :

• Better documentation in order to avoid knowledge loss if a developer was to leave the team.
• A faster development process.

As a software professional, you definitely can (and should) tell him about your doubts on the CASE approach’s ability to match these expectations. It is also your duty to start looking at CASE tools if he demands so. Just trying out one of them doesn’t mean 1/ that the results will be satisfying (I’m especially thinking about the potentially big code generation overhead which kind of conflicts with the need to develop faster) and 2/ that you can’t find a compromise where some features of the CASE tool (diagrams, documentation generation) will be used while preserving the existing agile context.

Here’s an interesting article about CASE tools in an Agile environment and their possible benefits/drawbacks : http://www.agilemodeling.com/essays/simpleTools.htm

My employer (Not a Developer) thinks that CASE tools will help us improve our development process and documentation.”

If I were going to act as a consultant for your employer, I would be obligated to attempt to dissuade them from this kind of thing. First of all, it’s a major management error to have people who are not involved with the work choose tools for developers. This almost never goes well. It’s at least twice as bad when the people making the choice do not have a strong technical background. And if they don’t have any experience with the tools they are pushing, this is likely to be a total debacle.

The most likely reason that this kind of thing is being suggested by non-technical management is because someone is trying to sell them something. One major company that sells these kinds of things has revenues that are falling like a lead zeppelin in rarefied air. The salespeople (a.k.a re-sellers, consultants) that haven’t moved on to something else are rabidly trying to find new marks, er… customers. One of the main reasons these companies are struggling is that there is not much demand for these kinds of tools anymore. By ‘these kinds of tools’, I mean tools that promise to ‘eliminate writing code’. There’s nothing wrong with code, depending on the language. Written code has far more powerful abstractions than what these tools offer.

One of the main reasons that this is such a poor way to manage development is that it will severely reduce the pool of people you available to pull from to staff your team. For one, they need to learn these uncommon tools, and secondly, most experienced developers don’t want to work with these things. Often the pitch around these kinds of tools is that you don’t really need good developers because these tools do most of the heavy lifting. This is completely false. It’s the opposite. They do all the things that are trivial and often make doing the non-trivial parts harder. They also never really eliminate the need to write code.

Specifically with CASE tools, I’ve worked at three different places that owned these packages. In every single one, it went like this:

1. The model was painstakingly designed in the tool. It took much longer than normal and no usable deliverables were produced until very late in the effort.
2. The model needed to be augmented with business logic. The model was wrong and had to be tweaked manually during the late project phases because the effort was so overdue.
3. Re-syncing the model and the code was so cost-prohibitive the CASE tool was shelved, never to be used again.

In a nutshell, it was a 100% total failure and waste of money in each case. When I’ve spoken to other people who have used CASE tools in other organizations, the story is always about the same. I haven’t used all of these tools and it’s possible that some people have made good use of them but I’m fairly certain that most teams that have used them stopped using them long ago.

One of the benefits you would get out of investigating / implementing CASE tools is that you will have acquired a more marketable skill set for future employment. I think that many of your concerns are noteworthy, but, as pointed out by David Kaczynski, this is not a programming question so much as it is a employer / employee relationship question. Another benefit of CASE tools is that once learned, your company will be in a position to take on a wider range of projects of greater complexity. It may very well be that a contract your employer is looking to get requires, or places preference toward the use of CASE tools.

You are mixing the problem and the solution and your boss is trying to help, with more or less success. To challenge your boss you must have clear what is your role in the organization. If he is the CEO and you are the CTO the decision is yours and the CEO should just point on what business aspects are affected by the lack of documentation. Your obligation will be then to solve the business problem, with a CASE tool or any other solution you come out with.

Regarding the specific suggestion of using CASE tools, I think you must choose it properly so that you achieve your goal without overloading your team with extra work. If documentation is what you want to improve you may have enough with a tool that is able to generate diagrams from the code, not necessarily to generate the code from the graphical diagram. An example of such a tool is Codelogic. I used some years ago to make sure that our designs where clean and clear to be understood and it was quite easy to use. If as you express money is another concern you can probably look in the open source (I cannot help here but would be interested on the result of any research).

The alternative to CASE tools can also help. Measuring things like cyclomatic or other complexity measures will keep your design well structured and developers focused on the code. Better comments on your code, Javacode-like, can also help to improve documentation.

Honestly, I think if you consider that CASE tools don’t help your boss must know it. If he is a good boss he will value your opinion. I have never liked an employee who just does what he is told without critical analysis. But of course, as David suggests, any discussion should be hold on strong and objective arguments.

I’d try to make your employer realize that he/she has gotten things backwards. If there is room for investment for the software team, you should identify what your bottlenecks or quality problems are. IF it turns out that you have most room for improvement in documentation and development process areas, you should identify what changes has biggest ROI with regards to improving these areas. That might or might not turn out to be starting to use CASE tools.

Help Your Boss, Help Yourself

You can react or act on this request.

Remember all the “Move Mount Fuji” questions? If you were in an interview for a job you really wanted, you would not tell the interviewer how stupid the question was, but would keep asking questions and expressing your best ideas about solving it. In some cultures, you would not ever say no to a boss who actually asked you to move Mount Fuji, but would find a way for you to both save face.

Reframing the Question

If you were to reframe the question into something like,

“Can I buy or otherwise acquire a suite of tools that automate as many
of the low productivity tasks related to software as possible?”

this assignment becomes much more palatable. Help your boss (and yourself) by giving him an option with clear tracability to CASE, and one or two Agile / open source / cloud based options.

CASE Revisited

In the ’90s, CASE tools might take the form of a suite of tools from Rational that probably included Requisite Pro, Rational Rose, Clear Case, Rational Robot (a test runner), Purify, Pure Coverage, and Quantify, and several other tools that were integrated together. If you were a MAD shop (Medical, Avionics, Defense) you might use updated versions of these tools to produce extensive and traceable documentation and artifacts that are often required by customers in those markets.

Contact IBM and get a salesman out to give a quote for five licences (or just one floating license). Add in some training too. Sharing this quote with your manager may end the talk about CASE tools. But don’t get me wrong. I like Rational, their chief scientists, and their products, but have mainly accessed them through university site licenses because their price was too high for the companies where I have worked. If you are approved, at least from my experience, they will treat your right with good support, quality training (usually at a top resort with great food).

Tools for Sale

You still have a great opportunity to go tool shopping. Agile developers need tools too. You could buy a suite that gives you documentation support for online story cards, use cases, use case and other UML diagram types. Atlassian has what I think is a nice suite of tools – Jira for task and bug tracking, Green Hopper for what they describe as Agile project management, Confluence for an intranet wiki, Crucible for online code review, and Bamboo for a continuous integration server. There are software as a service licenses for these and other tool suites targeted to your needs if you are Agile.

IDE integration is another avenue of getting a year 2012 CASE equivalent. If you are a Microsoft development house, Visual Team Studio has tools that are of similar scope to what Rational created. They have some round-trip software engineering, generation of unit test stubs from classes, integration with source control systems, and a bunch of tools for team collaboration.

Open Source Tools

On the open source side, Eclipse and its many plug-ins try to integrate a bunch of open source tools. I am not sure if Eclipse Modeling Framework is mature or if there are other tools that give effective round-trip software engineer, but last time I looked, it didn’t seem very easy to achieve. The Qt Creator environment integrates with source control, and has some capabilities to help with spot checking from code coverage of changes while you are in the editor.

Iterative Incremental Tool Adoption

An iterative / incremental approach to tool selection can also be very effective. Open source projects often support single or multiple environments. Your tool choices may be influenced by the stacks that you use. There is never a good time to completely shut down development, so adding and training the team in a few smaller tools per quarter may be better than a big bang approach that changes everything at once.

Cloud Tool Solutions

Many of the solutions listed may require servers and relatively complex setup. There are a lot of options coming into the market that are cloud based and provide software as a service hosted by a provider for a monthly fee. This may make sense for your team, either short or long term. Some may have a hosted solution you can use for a quick start, with the option to buy licenses later on.

None of these suggestions is an inexpensive and easy road to instant productivity improvement, but if you may find some of the tools indispensible once you give them a try.

One thing I’d add to the excellent answers here is that you might benefit from understanding how you want to “improve your development process”.

The overwhelming trend over the last 20 years has been to optimize software development for time to market. “Agile”, “lean”, DevOps, TDD, BDD – they are all about getting quality software out the door as quickly as possible.

CASE tools are not about time to market. They focus on traceability, design consistency, model completeness etc. These are all valuable aspects – especially in banking systems – but they are at the expense of time to market.

So, maybe ask your boss exactly what he’s trying to optimize.

From experience, working with CASE tools rapidly becomes more difficult than working with code – especially when working with problem domains that are more than averagely complex. The project stops being a “banking” project, and instead becomes a “insert-name-of-CASE-tool-here” project.