Automation in Software Development
I am a semiretired programmer. I spent over 25 years in the trenches, moving electrons around or teaching university students computers and programming.
For that entire time, I have been told repeatedly that I was about to become obsolete because a new programming language was designed so non-programmers could write their own applications, or automation was going to make humans redundant.
It started before my time with COBOL and SQL.
COBOL stands for Common Business Oriented Language. It was released in 1959 to allow business people to write their own code.
SQL stands for Structured Query Language. It was released in 1986. I was writing SQL Professionally by the mid-1990s. Again, SQL was supposed to allow analysts to talk to databases without needing a specialized programmer.
It turns out that programming takes skills that a lot of people have, but not necessarily every analyst and business person. The same thing has occurred with newer programming languages, you need programmers. The best results are achieved when the analysts and business people work closely with developers to leverage their individual skills.
Let’s look at automation, but first I’ll take a detour to point out the possibilities and limits of automation.
Most major programming projects fail, if you measure success by the project producing an application with most or all of the requested features, while being delivered close to on time and close to on budget. As many as a third of all large programming projects are so compromised that they are completely abandoned.
The usual cause of failure is not the quality of the code; it is lack of planning and management. Lack of planning could include insufficient resources of time, money, and staff, or lack of a clear idea of the final product. Lack of management could include not communicating well within the team and/or with the sponsors and end users during development, inadequate testing during development, and/or not enforcing coding standards.
If planning and management are good, what is to keep automation from writing the program?
The answer is “design”. Automation doesn’t work from business requirements, at least not yet. Someone needs to come up with a detailed design that even a robot can follow.
I develop business applications that are based on a database. I develop a design for the database tables and the user interface, and then all we need is the “plumbing” between the data and the interface. Automation can certainly help at this point.
Before beginning a project, I always warn the client that we are venturing into uncharted territory. I don’t know the business in details yet, and the client doesn’t understand the opportunities and hazards of a software development project.
As soon as the project starts delivering something for the client to evaluate, there will be requests for changes. Modern development practices expect and welcome these changes. Additionally, the developers may spot possibilities for enhancement, and the users may think of things that were missed during the earlier phases of the project.
Automated development environments must have a detailed and accurate description of the final project before you start, while modern development practices require being flexible during development. This isn’t as much of a problem as it seems. If requirements change, the design can be changed, and the new code can be quickly generated and modified, if code customization is required.
The detailed design must be in a form that a computer program, the automated code generator, can read. This is often an XML (eXtensible Markup Language) file. Data in this file is a mix of database metadata and instructions from the designer. Code generators usually come with automated reading of the database, and an editor for the other design choices. The files tend to be long, and manual editing is not recommended.
So, how well does automation work if all the other factors are covered? I would say very well. My largest project contained about 1.2 million lines of code, and was very well received by my client. Probably only about 6% of the code was manually written. The rest was generated by “Iron Speed Designer”. The company is defunct, but I still use the product to maintain a few applications. The application writes perfectly normal C# or VB.net code, so it is no problem to maintain it manually.
At this point you might ask how much time and money automation saved. The largest project contained about 1.2 million lines of code, took four months to deliver the first production module, and 14 months to finish deployment and requested changes. The cost was less than $300,000, so the program cost less than $0.25 per line of code. Comparable manually coded projects cost $2.00 to $10.00 per line of code, and take much longer.
My (Conrad Muller's) work on this page is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.