Not anyone! Not many people get close to the level where they'd need to open that book
I've pinched loads of their code and methodology for my apps. But then I've spent the last few years spending 60-80% of my time working in VBA.....
ah yes, blame the specs.
I didn't say blame the specs. I said it's the customer's fault. As you rightly point out, it's not as simple as incorrect specs. It's often customers not really understanding their situation.
Development teams need to do a lot more than code to specs. They need to take the client through the process of creating IT systems. However, most clients think they already know all about that when they really don't.
Quite a few, there's a huge VBA development community and loads of companies run on VBA
none that I've met...
Not anyone! Not many people get close to the level where they'd need to open that book.
I think I have browsed that book and I don't think it was very low-level. Maybe that is the problem, too many high level VBA programmers not really knowing what they are doing or the environment they are working in...
I think I have browsed that book and I don't think it was very low-level.
It's not low level, nor is it a basic book. It's probably 50% methodology and approach and 50% advanced techniques on GUIs, Dictator Apps and interacting with other SW eg databases, Windows OS, VB, DLLs, .NET, etc.
GEEK FIGHT!
That was a very odd film!
how many Excel programmers have those skills
The issue is the developers
The issue is that lots of this stuff is created by people who aren't, nor would claim to be, "programmers" or "developers". Lots of them are accountants. They understand what they want it to do, they understand the maths involved, and because it's easy to get stuck in and make it do things, and they spend most of their lives using Excel anyway, they can make excel do some fairly complex things that will answer the questions they start with. But they won't care (or know) anything about development methodologies, testing or whatever, they'll just design a apreadsheet to do what they want to do. Then start using it.
I am one of those accountants, btw
GEEK FIGHT!
producing production quality systems is also a task often beyond geeks (and nerds)
But they won't care (or know) anything about development methodologies, testing or whatever, they'll just design a apreadsheet to do what they want to do. Then start using it.
Nothing wrong with that per se, it's when the organisation starts to rely on those spreadsheets and they end up filling the role of a properly designed IT system.


