Is coding same as writing scripts?

Did you solve the problem before you wrote the first line?

The term coding has become greatly adulterated by AGILE shops and processes. In true Software Engineering you solve the problem before you write the first line of code. The process of “coding,” be it a compiled or scripted language, is little more than translating the solution into the language and tools assigned to the project.

In the AGILE world you are just hacking on the fly. It’s the cooking equivalent of throwing spaghetti noodles at the wall to see if one sticks. You have no idea what “the problem” is. All you have is this tiny user story selected for a sprint. The user story may have absolutely nothing to do with “the problem.” It got added to the slop bucket of user stories and either got selected for a sprint or chosen by a developer fishing in the backlog.

The difference is you have done root cause analysis. You aren’t running around trying to put bandages on symptoms, you are actually fighting the disease.

I read a book early in my career. I don’t remember the title. I remember one essay very clearly. At least I remember the gist of it.

XYZ corporation was making a physical product that had become wildly successful. Customer service had a system for tracking claims from customers. They typically had only five operators working the phones. As success increased they had doubled to ten operators because claims were coming in faster. The operators could not keep up and the customer service system could not handle any more users.

XYZ corporation contacted several consulting firms to get an estimate for a new customer service system that could handle up to 500 operators. The reputation of the company was starting to suffer because nobody could get through on the phone lines. (We didn’t have the Internet then.)

One lone consultant, the token small business brought in to satisfy government quota, went out to the factory to talk with the QA test head. All of the other firms were salivating and cranking out million dollar estimates. In talking with the QA department he found out they were only doing a 5% random sample of products. The company was loathe to do more because the product was expensive and testing tended to destroy it.

One lone consultant then went to upper management and pitched them the story that his root cause analysis determined the failure rate was simply too high. They didn’t need a new customer service system, they needed a higher quality product. Management didn’t like this “solution.” The head of customer service wanted a new system yesterday but all of the estimates were at least six months before delivery.

One lone consultant urged management to move to a 20% random sample. Increasing to 10% for the QA tests that could destroy the product and implementing a different set of tests that would prove out the product for the other 10%. That 10% could then be fixed prior to sale. He convinced them to implement this for a month before signing a contract for a new system.

Guess what. Quality went up and call volume dropped. Management held off for another month on the new million dollar customer service system and call volume dropped again. This time it dropped to below previous “normal” rates. Sales increased because now the product wasn’t failing spectacularly in the field.

Management then increased the QA department size and started applying that subset of tests to all items manufactured. In a couple of months they moved some of the customer service people to QA because they had nothing to do in QA.

Management will always tell you what they wish to believe the problem is. It is a consultant’s job to identify the actual problem.

In an AGILE universe, they would have gotten a customer service system which was constantly being updated and modified to handle the influx of calls due to a low quality product. In a Software Engineering universe they fixed the problem with the product and the symptom (overrun customer service) went away.

You can’t solve a real problem by just throwing code at it. Coding is the next to final step after you have solved the problem. Many problems can be solved without writing a single line of code