I am confused J. You are saying that "I could be the best programmer in the world, but I could (and do) introduce bugs into the code", which is true, and the basis of quality control, which is surely difficult in something like Excel.
If I use an accounts package to do accounting, and it has been certified and tested to certain standards, then managers using anything other than using certified accounting packages would be nuts. They are creating the code, as you have said - and therefore Excel is doing exactly as you have said, you are creating your own code (even on a spreadsheet basis) that is open to problems.
The entire point of having a really good system is that you create it and manipulate it from a top down approach, so that you can control the quality and efficiency of the system. This is not part of excel. All that excel can do, is provide basic mathematical processing. And even if they aren't programmers, what they are doing amounts to programming, and surely the processes surrounding programming therefore applies. Either it does or it doesn't.
Either managers are independant of the systems that they use, and use them only, or they have to understand how it works in order to design/implement/test their own systems.
I can't help thinking that, if this approach were taken properly, 99% of the administrative ****-ups that occur in real life wouldn't have happened.
And the comment about diagrams, well - a diagram can illustrate something that would take a great deal of time to describe. It doesn't matter what it is applied to. If the processes surrounding a business need to be modelled, a suitable diagram should suffice.
EDIT : most of the other replies, specifically the "power" of excel are, as I have said, well grounded. I have not fought against the fact that you could do a full implementation of whatever those folding guys are doing with the current distributed projects are, or SETI at home type analysis, in Excel. The practical reasons that we don't, however, such as performance and reliability, are enough to make them *not* implemented in Excel.
The replacements for Excel? I am not sure off the top of my head. Managing different types of resources requires different types of software. Its a management process in general. I am not talking about one-off calculations or scientific evaluations, such as high-level industry modelling (I guess aerodynamics of planes or some such, although I suspect you'd be nuts to implement it in Excel), the problem is that you would test hundreds of times for each and every single person, the spreadsheets they set up, the calculations they used, whether the same versions of the process/implementations were being used, compatibility etc...
Simple example : I make a spreadsheet with a series of numbers, and put a total in column E6. I then continue to develop other spreadsheets calling on E6 to produce that total. Other people do the same, calling on E6 as a total. Then later on, I decide I need to rework the original template, but I need to change E6 to be something else. How do I manage the change? How do I manage the changes needed to correct all the templates? What about the ones which I don't know about but are still essential to the business? How do I document the changes properly?
In proper software development, you would develop an API which would be published (probably online) and then subsequent calls / changes would be tracked, you would be able to see if people made calls to something deprecated or at least provide backwards compatibility, none of which you can (as far as I understand) do with Excel.
If I use an accounts package to do accounting, and it has been certified and tested to certain standards, then managers using anything other than using certified accounting packages would be nuts. They are creating the code, as you have said - and therefore Excel is doing exactly as you have said, you are creating your own code (even on a spreadsheet basis) that is open to problems.
The entire point of having a really good system is that you create it and manipulate it from a top down approach, so that you can control the quality and efficiency of the system. This is not part of excel. All that excel can do, is provide basic mathematical processing. And even if they aren't programmers, what they are doing amounts to programming, and surely the processes surrounding programming therefore applies. Either it does or it doesn't.
Either managers are independant of the systems that they use, and use them only, or they have to understand how it works in order to design/implement/test their own systems.
I can't help thinking that, if this approach were taken properly, 99% of the administrative ****-ups that occur in real life wouldn't have happened.
And the comment about diagrams, well - a diagram can illustrate something that would take a great deal of time to describe. It doesn't matter what it is applied to. If the processes surrounding a business need to be modelled, a suitable diagram should suffice.
EDIT : most of the other replies, specifically the "power" of excel are, as I have said, well grounded. I have not fought against the fact that you could do a full implementation of whatever those folding guys are doing with the current distributed projects are, or SETI at home type analysis, in Excel. The practical reasons that we don't, however, such as performance and reliability, are enough to make them *not* implemented in Excel.
The replacements for Excel? I am not sure off the top of my head. Managing different types of resources requires different types of software. Its a management process in general. I am not talking about one-off calculations or scientific evaluations, such as high-level industry modelling (I guess aerodynamics of planes or some such, although I suspect you'd be nuts to implement it in Excel), the problem is that you would test hundreds of times for each and every single person, the spreadsheets they set up, the calculations they used, whether the same versions of the process/implementations were being used, compatibility etc...
Simple example : I make a spreadsheet with a series of numbers, and put a total in column E6. I then continue to develop other spreadsheets calling on E6 to produce that total. Other people do the same, calling on E6 as a total. Then later on, I decide I need to rework the original template, but I need to change E6 to be something else. How do I manage the change? How do I manage the changes needed to correct all the templates? What about the ones which I don't know about but are still essential to the business? How do I document the changes properly?
In proper software development, you would develop an API which would be published (probably online) and then subsequent calls / changes would be tracked, you would be able to see if people made calls to something deprecated or at least provide backwards compatibility, none of which you can (as far as I understand) do with Excel.
Last edited:
