While “development automation” is not a commonly used and recognized term of the software dev. industry, I have heard it many times in my life.

Business people normally use it to refer to “anything that can speed up the development process and allow the company to bypass most, if not all, of the software development process, jumping from a simple business-level wish list to a ready-for-the-market product (writing as little code as possible and hiring as little programmers as possible)”. In other terms: “any technology/methodology that can reduce software development to the most complicated thing the average business guy can understand: Lego (TM)”. 😉

Given this definition, there are three technologies/methodologies that fit into it:

1. RAD (Rapid Application Development)
2. Code generation
3. MDA/MDD (Model-Driven Architecture/Developement)

These techniques can be used only if/when it is possible to make a few strong assumptions about the nature of the project at hand.

For example, Ruby-on-Rails and Django can do a lot of code generation (“software development automation”) because they take for granted that what the programmer wants to produce is a web application mainly involved in exposing a database (a model) to the end user through a business-logic layer (a controller) and a web page (a view).

If you can make such strong assumptions, you can automate a lot. Have a look at these tools to get a feeling:

http://en.wikipedia.org/wiki/DaDaBIK

http://www.dadabik.org/

http://www.andromda.org/docs/index.html

And, of course, have a look at the powerful code-generation tools used by RoR and Django.

BTW: A special case of “code generation” is build automation. That is: the kind of build-time tricks you can do with Maven, Ant, Rake, Scon, Rake, etc.

In the general software development arena, these tools have seen very little success because (normally) you cannot do such assumptions about the nature of the project at hand. When you are developing something new or something that is strongly custom-tailored usually you need to work with the finest “logical granularity” allowed by your tools, that is the same granularity allowed by your programming language. Anything else would be just to rough for the task at hand.

1. Ask the guy that used the term. Don’t ask someone else; they might not have the same background as your boss.

2. Here are some examples of what I would consider development automation:

   • Automatic update of dependencies, e.g. using NuGet
   • Automatic build process
   • Automatic checking of style rules, e.g. using FxCop
   • Automatic execution of unit tests with every build
   • Automatic update of code-generated proxies, e.g. WCF clients
   • Automatic creation of deployment packages
   • Automatic configuration of target environments
   • Automatic deployment to development or QA environments, e.g. install a fresh build every night at 3:00 am
   • Automatic computation of metrics, such as Code Coverage
   • Automatic smoke tests, e.g. using Watir
   • Automatic generation of release notes, or at least of the bug list that goes in the “Fixed in this build” section