Skip to main content
Add further information
Source Link

I worked for an organization that had spreadsheets all over the place, largely because the IT resources were hopelessly overstretched. They would have moved this to an application if it was possible - it simply wasn't possible.

One of the things I did after I left that organization was created a tool for generating C#/SQL Server table maintenance programs from Excel spreadsheets. It assumes the column header is the column name for purposes of table construction and field labeling. However, this is a crude instrument. It ended up getting used for things having nothing to do with Excel.

The issues we had ran into several categories:

  • Validation: When the validation rules are complicated, people have to keep the procedures in their head. It's possible to design the spreadsheet with 'if' statements all over the place, as long as people understand how these work.

  • Sharing: as pointed out elsewhere, if one person has a network share spreadsheet open for read/write other users can only read. We were not at the point where we could open a spreadsheet in a collaboration mode. That was another thing the IT people couldn't handle at the time.

  • Schema consistency: In the situation I was in we had a spreadsheet for each state: the format was common but the state by state data traveled in separate files. If someone made a creative use of a column then everyone had to agree on this use, which was not always assured.

The spreadsheets were always on a network share and the server was backed up every night, so none of this was an issue. There was also the distinct possibility of one of them being accidentally emailed to a destination where it didn't belong. While the likelihood of real harm was slight in this case, the organization was one where 'leading by example' was critical to it's credibility. That kind of mess up would have been embarrassing.

I saw an ad on Craigslist where someone needed an "Excel Guru". I passed this to a friend that was between jobs, and he found that the company had a construction contracting estimation system operating at sites all over the state. Someone here had arbitrary doctored up the system to 'make it work more in they're style'. Whatever that style was, it had caused a lot of damage. He spent several days fixing it. Hardly had he turned in his work and gotten paid they called him back to fix another one in another city. Same story: someone arbitrarily 'fixed' it to do what they wanted. This one was even worse.

Complicated systems like this need to be 'out of reach' of ad-hoc customization.

I worked for an organization that had spreadsheets all over the place, largely because the IT resources were hopelessly overstretched. They would have moved this to an application if it was possible - it simply wasn't possible.

One of the things I did after I left that organization was created a tool for generating C#/SQL Server table maintenance programs from Excel spreadsheets. It assumes the column header is the column name for purposes of table construction and field labeling. However, this is a crude instrument. It ended up getting used for things having nothing to do with Excel.

The issues we had ran into several categories:

  • Validation: When the validation rules are complicated, people have to keep the procedures in their head. It's possible to design the spreadsheet with 'if' statements all over the place, as long as people understand how these work.

  • Sharing: as pointed out elsewhere, if one person has a network share spreadsheet open for read/write other users can only read. We were not at the point where we could open a spreadsheet in a collaboration mode. That was another thing the IT people couldn't handle at the time.

  • Schema consistency: In the situation I was in we had a spreadsheet for each state: the format was common but the state by state data traveled in separate files. If someone made a creative use of a column then everyone had to agree on this use, which was not always assured.

The spreadsheets were always on a network share and the server was backed up every night, so none of this was an issue. There was also the distinct possibility of one of them being accidentally emailed to a destination where it didn't belong. While the likelihood of real harm was slight in this case, the organization was one where 'leading by example' was critical to it's credibility. That kind of mess up would have been embarrassing.

I worked for an organization that had spreadsheets all over the place, largely because the IT resources were hopelessly overstretched. They would have moved this to an application if it was possible - it simply wasn't possible.

One of the things I did after I left that organization was created a tool for generating C#/SQL Server table maintenance programs from Excel spreadsheets. It assumes the column header is the column name for purposes of table construction and field labeling. However, this is a crude instrument. It ended up getting used for things having nothing to do with Excel.

The issues we had ran into several categories:

  • Validation: When the validation rules are complicated, people have to keep the procedures in their head. It's possible to design the spreadsheet with 'if' statements all over the place, as long as people understand how these work.

  • Sharing: as pointed out elsewhere, if one person has a network share spreadsheet open for read/write other users can only read. We were not at the point where we could open a spreadsheet in a collaboration mode. That was another thing the IT people couldn't handle at the time.

  • Schema consistency: In the situation I was in we had a spreadsheet for each state: the format was common but the state by state data traveled in separate files. If someone made a creative use of a column then everyone had to agree on this use, which was not always assured.

The spreadsheets were always on a network share and the server was backed up every night, so none of this was an issue. There was also the distinct possibility of one of them being accidentally emailed to a destination where it didn't belong. While the likelihood of real harm was slight in this case, the organization was one where 'leading by example' was critical to it's credibility. That kind of mess up would have been embarrassing.

I saw an ad on Craigslist where someone needed an "Excel Guru". I passed this to a friend that was between jobs, and he found that the company had a construction contracting estimation system operating at sites all over the state. Someone here had arbitrary doctored up the system to 'make it work more in they're style'. Whatever that style was, it had caused a lot of damage. He spent several days fixing it. Hardly had he turned in his work and gotten paid they called him back to fix another one in another city. Same story: someone arbitrarily 'fixed' it to do what they wanted. This one was even worse.

Complicated systems like this need to be 'out of reach' of ad-hoc customization.

Source Link

I worked for an organization that had spreadsheets all over the place, largely because the IT resources were hopelessly overstretched. They would have moved this to an application if it was possible - it simply wasn't possible.

One of the things I did after I left that organization was created a tool for generating C#/SQL Server table maintenance programs from Excel spreadsheets. It assumes the column header is the column name for purposes of table construction and field labeling. However, this is a crude instrument. It ended up getting used for things having nothing to do with Excel.

The issues we had ran into several categories:

  • Validation: When the validation rules are complicated, people have to keep the procedures in their head. It's possible to design the spreadsheet with 'if' statements all over the place, as long as people understand how these work.

  • Sharing: as pointed out elsewhere, if one person has a network share spreadsheet open for read/write other users can only read. We were not at the point where we could open a spreadsheet in a collaboration mode. That was another thing the IT people couldn't handle at the time.

  • Schema consistency: In the situation I was in we had a spreadsheet for each state: the format was common but the state by state data traveled in separate files. If someone made a creative use of a column then everyone had to agree on this use, which was not always assured.

The spreadsheets were always on a network share and the server was backed up every night, so none of this was an issue. There was also the distinct possibility of one of them being accidentally emailed to a destination where it didn't belong. While the likelihood of real harm was slight in this case, the organization was one where 'leading by example' was critical to it's credibility. That kind of mess up would have been embarrassing.