Re: why>?
- From: dbahooker@xxxxxxxxxxx
- Date: 13 Jun 2006 13:31:19 -0700
IT isn't the solution to anything
the solution is to start taking Excel development seriously.
the solution is to apply SDLC into the 'excel development process'.
All you guys sit around and build the same spread*** week in and week
out.
there is no version control; there is no project management.
I thiink that it's a load of ***.
And I think that Excel developers should be held to the same standards
as 'real developers'.
Delivering a solution where you email 20mb spreadsheets around?
that gets a big fat resounding F in my book.
As it is; every spread*** solution i've ever seen gets a failing F.
And i've worked on million dollar spreadsheets before.
I don't agree that it is the users screwing up data.
it is the program. Excel is incapable of true validation.
If you want to display the data with 2 different levels of precision;
then you're storing 97 million copies of similiar formulas; and it is
impossible to validate.
It is impossible to accurately force users to enter data into the right
cells; and ensure that it is the correct datatypes.
Excel vba is a disease. It is not possibly--- in any way--- to protect
against Excel viruses.
the root of the problem is that emailing 20mb spreadsheets around is
not an efficient way to work. it is a security risk; it is a
performance risk.
it is just plain idiotic.
If Excel had real reporting capabilities-- like if it could export to
SNP format (Microsoft Snapshot; currently available inside C++ and MS
Access).. then excel might be taken seriously.
that is only 1/100th of my problem with Excel.
I _DO_ get it. but I dis-agree with your horse-*** development
methods.
Excel is a disease and you are all lepers.
I disagree that it is as simple as 'disabling macros'
first off; if i disable macros; i can enter whatever datatypes in
whichever cells i want (under your model where you have to write a
formula for each datatype).
the practical solution to this is to use MS access.
it has real validation; access files aren't emailed around.
and even if you shut off macros; validation still works.
there are table level and field level validations.
there are TRIGGERS where you can enforce VERY VERY complex logic.
excel just doesn't have a single feature of value.
Harlan Grove wrote:
aaron.kempf@xxxxxxxxx wrote...
...
just because Excel shares a single characteristic with scripting
languages?
It shares many, especially wide-spread perception of usability. You
seem to be one of the few who just doesn't get it.
it doesn't give it an excuse
For screwing up your data? Your users screwed up your data. It's not
the software's fault. It's the programmer's fault, or in you case, the
whiny idiot who forgot to check his data for consistency before trying
to load it into his database. It *IS* possible to enforce real data
validation in Excel, but it takes programming. If you don't want to (or
can't) do the programming, don't use Excel for this.
just because you shoot up heroin; it doesn't make it ok for me to smoke
cocaine. Right?
More failed analogies.
If A shoots heroin, and B smokes crack, and C comes from the same
neighborhood, wise to treat C at first like another adict. Not
charitable, but this is an analogy, and charity has no place in
programming.
If you have any reason to suspect bad data from Excel sources or have
ever had any, then you have no excuse for not checking the data. But
practicality has nothing to do with your ranting. No, much better use
of your time to whine about features Excel lacks. At least when you're
ranting in the ngs that's time you're not screwing up your clients'
systems.
i think that it's complete and utter bull*** that Excel doesn't have
real validation; you claim that there are 2 routes
a) excels' built in validation
b) vba
You're misstating what I said. First, we agree it's a shame Excel lacks
real validation. However, you waste time whining about it, while I
spend time trying to figure out how to provide it through programming.
There are 2 interrelated ways to provide validation in Excel. First,
add *formulas* to check user entries for validity, and use those
formulas to display diagnostic messages. Second, use VBA to check the
validation formulas and prevent printing when there are any invalid
entries. Allow saving but only after displaying a modeless dialog
describing the problem for the user, and display the same dialog upon
reopening workbooks with invalid data.
since we all know that Excel vba is the most dangerous thing in the...
world; you should assume I'm not a big enough dip*** to email around
spreadsheets with macros in them.
If you won't use VBA, then you shouldn't be trying to use Excel for
multiple user data entry systems. Very bad idea. But even so, it's
still possible using only formulas to ensure that if there's *any*
invalid entries then *all* formulas evaluate to errors. When it's
absolutely crystal clear that users get Garbage Out, there's much less
Garbage In. It's workbooks that give partial results of seemingly
complete results when there are invalid entries that are the biggest
problem with spreadsheets. One of the fundamental rules of multiple
user spread*** design is give users NOTHING unless they provide ONLY
valid entries.
And who said anything about e-mail? Maybe e-mail is the only means you
have for distributing spreadsheets.
if nothing else; there are false positives and sometimes get stripped...
from various antivirus programs.
Depends on a company's security program. If they never allow macros,
then there's not much point to using Excel vs much cheaper
alternatives. But most Excel users work for companies that still allow
macros, and most of them have IT departments that can figure out how to
set AV software so it doesn't strip out VBA modules.
Disallowing VBA macros is at most a partial solution. As long as
Windows users have a command processor on their systems, batch files
could wreak as much havoc. And with NT-ish CMD.EXE, it's not possible
to pipe commands into the command processor, so malicious commands
could come from any source capable of generating plain text stdin.
it is ridiculous to email around spreadsheets; do you have any idea how
easy it would be for me to make a XLS that caused you unspeakable data
loss?
If I were stupid enough to open it without macros disabled? You do
realize that it's possible to open XLS files with macros disabled?
That said, do you know how easy it'd be for me to screw up your system?
All it'd take is the single command [if anyone else is reading this, DO
NOT TRY THIS unless you want to reinstall your system's software from
the OEM disks]
reg DELETE HKCU\Software /va /f
Put that in a shortcut called README that first loaded an innocuous
text file in Notepad.
Fubarring systems is easy, and it doesn't require anything more than
the OS tools Microsoft so helpfully provides with Windows alone. Would
you like me to show you how to script DEBUG to run to the physical disk
formatting routine in BIOS?
and your on-off; 'im a spread*** developer but i cringe at the idea...
of being known as a real software developer' attitude makes me sick.
You don't get it. Sensible people (so not you) would describe people by
what they *mostly* do. I spend maybe the equivalent of a work week per
year maintaining or enhancing a handful of programs. I could stop doing
so if I wanted to, shifting the task out of my department into IT. My
job description wouldn't change. So, no, I don't describe myself as a
'software developer'. You're the one that needs to define me and most
Excel users as such in order to provide some sort of foundation for
your spurious claims.
you fucktards should be held to the same levels of excellence that real
software developers need to adhere to.
Level of excellence? Such as the level of Microsoft excellence that led
them to recomment recently that Word users run Word in safe mode?
When it comes to spreadsheets, the unfortunately common level of
excellence is 'do the results look right?' That's not going to change
because the reason so many people use spreadsheets is to get answers
(often wrong ones) quickly. You just don't get it that for most
business users, the only software they have for calculation is the
Calculator applet, formulas in Word tables and Excel. Given those
alternatives, Excel looks pretty good.
it is stupid that companies hire 'accountants' and 'financial analysts'...
in order to write spreadsheets.
Ain't it a shame Aaron has absolutely no clue what these people do?
Imagine how much more efficient investment banks would be if they
replaced all their accountants and financial analysts with programmers
and DBAs!
does crystal reports bitch if 2 people open the same report at the same...
time?
No, and neither does Excel bitch if multiple users open read-only files
(the only way users should have access to XLS reports from shared
directories) at the same time. Excel may whine about saving changes
when the user tries to close the file, but that could be addressed by
adding a BeforeClose event handler including the statement
Me.Saved = True
your tools are for babies; and it makes me sick that there is a single
excel dork that is paid $1; anywhere in the world.
You've certainly proven your, er, Excel skills (or do you prefer
SKILLZ?) aren't worth $0.02, so it's a good thing no company is wasting
its money paying you to do anything with Excel.
You can't get information out of excel; you cant get information into...
Excel.
It's clear YOU don't know how to do so.
.
- Follow-Ups:
- Re: why>?
- From: Harlan Grove
- Re: why>?
- References:
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- From: aaron.kempf@xxxxxxxxx
- Re: why>?
- From: Harlan Grove
- Re: why>?
- Prev by Date: Re: Disable macros
- Next by Date: Re: User defined functions without programming.
- Previous by thread: Re: why>?
- Next by thread: Re: why>?
- Index(es):
Loading