Why You'll Always Need a Programmer

I've been writing software on various platforms for a little longer than a decade now and I have noticed a reoccurring trend. Customers are asking for and software vendors are trying to develop a way to allow business analysts to implement business logic in their applications.

The idea is that the business analyst knows the business inside and out. Therefore, if the business analyst had a way to implement the business logic, then there would be no need to have both the business analyst and the programmer (and the ensuing communication overhead).

I, however, am not concerned. In my experience, I have come to the conclusion that not only is the implementation of business a programming task, but it is a programming task that requires a strong development background.

What I mean is, you can write DSLs, query builders, and the like until you're blue in the face (presuming that you would eventually turn blue in the face writing DSLs and query builders), and the technically savvy business analyst will be able to learn to use these tools; however, without the foundation of good programming practices, this business analyst will produce vast amounts of technical debt which will, in the long run (if not the short run), cost the company much more than the programmer would have in the first place.

The Problem

Over the last several decades, programmers have developed practices and patterns that allow us to write applications that are easily upgradeable, scalable, maintainable, and even readable. We have built on this body of knowledge and we have tested it. Sure, there are some disagreements here and there, but for the most part, as we develop professionally we are forming a special way of looking at the world and solving problems which is relatively unique to programmers.

Similarly, business analysts have been doing the same thing. They look at the world and approach problems in their own special way. I believe they are two sides of the same coin. Both are responsible for understanding, documenting, and implementing business rules. One side communicates these rules to humans and the other to machines.

Enabling a business analyst to communicate directly to machines seems like a money saving flexibility that can't go wrong. It can go wrong — terribly wrong, and it can do so before you realize there's a problem. I believe that the business analyst would take as long to learn about the programming practices required to make solid architectural decisions as it would take the programmer to learn to be a business analyst.

If the business analyst is able to implement solutions, it is almost certain that there will be errors that a programmer would have caught. When the needs change, the analyst may even be able to address these changes, but this will lead not only to more errors, but also to an increased complexity that a programmer would have avoided.

Thus, the more work that goes into the solution over time, the more difficult it will be to maintain. Dealing with maintenance issues will lead to unintended consequences which will be corrected with more patches resulting in what programmers would liken to spaghetti code.

Eventually, the design entropy will lead to such a disaster that the vendor will need to be called in. Vendor engineers for large software companies can cost more than 300 dollars an hour.

Case Study - Business Process Automation

I have been working with a BPM engine for several years now. It's really great at what it does. It provides an asynchronous state engine, a visual workflow designer, and data persistence. The only real problem with this application is the way it is marketed to customers.

The company that produces the application claims that business processes can be automated without the need of a programming staff. They tout the visual designer as business analyst friendly. I agree that it is BA friendly . . . to read. Generating workflows is a vastly different story.

I have implemented this software for my own clients, for a very large government organization, and indeed for the software vendor itself. In every case, I have shown that even at a very low complexity, these implementations still required a knowledgeable programmer.

Case Study - Data Validation

I have a friend who works with a dynamic data collection application which implements data validation on the server side in SQL stored procedures and in javascript code snippets on the client side. The person who develops most of the data validation for one of his customers is an entry level programmer.

All of the validation works and everything is well and good until something changes. Even minor somethings can result in very intense development, debugging, and testing cycles. The people who developed these applications are very smart and clever people, but their lack of programming background has resulted in code which is almost impossible to maintain.

A more solid understanding of programming principles would have prevented probably 90% of the code repetition in these business rules. One small change wouldn't require a code change to every single business rule. Isolating bugs and errors could be accomplished through tests of small units of code rather than very large blocks of difficult to follow code.

The Solution

You will always need a programmer. If you are trying to develop a software based solution to save your company money, an architect with a solid programming foundation will produce a much more robust and more easily maintainable solution. The solution will last longer and will scale easier than anything your business analyst can come up with alone.

A good BA / software engineer team will produce benefits to your company that you, your BA, and your engineer could never have invented individually. The initial cost may be higher, but consider this.

Most of the time, your company will have to foot a hefty bill to train the BA. There will be evaluations, proof of concepts, and tests. More often than not, the determination will be that a BA just doesn't have the experience required. At that point, you will either have to hire a programmer and go through the same process or you will have to contract with the vendor or one of its partners.

The worse scenario is that your BA can implement a solution and that it works. When the application changes, you generate need for more application changes. These changes generate more changes. These changes compound and you're faced with a very costly overhaul of the entire system.

It is far better to start with a BA and a programmer. Send them both to the appropriate training. Have them both work together to produce adequate project documentation. Foster an environment where they are mutually productive. Not only will the whole be more than the sum of its parts, you'll save a great deal of expense and heartache.