Creating solutions to non-existent problems

People love Excel. People hate Excel.

People want a solution which is not Excel. Let's face it, there is very little color aside from green. It is a pain to format cells. It gets boring. We had hoped to move on by using Powerpoint for everything, but we can't expect a painter to do the job of an engineer. So what do we do?

We ask for a custom applications to be built. AHA! We will escape the doldrums of empty cells. We will have buttons, and color, and, and...well what do you have?

If your business process is to manipulate large swaths of data, data that can be altered by a large group of people seldom at the same time, perhaps Excel isn't so bad.

"Time to get to the point," you say? It is simply this: If there is a problem with a business process, creating custom applications is not going to help. If you are tied down by the randomness of excel manipulations and want to have some structure to your process, you can't then demand the ability to use Excel. Excel solves certain types of issues. If it is inadequate, that's fine. It often is. But the alternative is not to complicate the randomness of Excel with the restrictions of a custom application. Applications are built according to processes and workflows, something that is inherently missing from Excel.

In those cases where custom Excel addons are created or custom workbook templates are created, the business process is well defined before development begins. Specs change, features grow, but the over reaching arc should remain consistent.

Most users do not understand this. But if the converse were true well, you wouldn't have any users. A simple example would be selling someone an application in development that would cure cancer, but when you actually delivered the product it ended up making ice cream. It is the same project, but through lack of thoroughness and direction, the outcome varied vastly from the initial proposal.

Since user have little idea of the process of software development it is hard for them to see their little changes as having big impacts. Even in non-coupled, highly modularized code this is an issue if now the separate components are logically contradictory.