Consequences of Casual Development

I did a fair amount of work with Lotus 1-2-3 back in the day, writing spreadsheets for other people. (I was paid and everything. Amazing.)

 

Tracking down errors in those spreadsheets was always a pain in the neck. Time has marched on, mercilessly. 1-2-3, Symphony, Jazz, Improv and even Quattro are just historical footnotes now. I haven't built a serious spreadsheet for anyone since 1991. I do use Excel, more as a "user" and not as a developer. I've never really dug into any of it's debugging features. For my own purposes, I use the relatively anemic Google Spreadsheet because it's good enough 90% of the time and I always have a browser window open.

 

I've often wondered (a nice word for "daydreamed") how people debug complex spreadsheets. Spreadsheet power users, while they can spell SDLC and know their way around a VLOOKUP(), do not strike me as the types who have backgrounds in TDD.

 

Apparently, I am not the only person who wonders and perhaps more people should wonder.

 

Enough of the meandering commentary...

If you are interested in software lifecycles, are following the BYOD/empowered-user movement or have simply wondered "Is it as bad everywhere else as it is here?", I suggest reading this (warning: some economy loonies in the comments) and some additional (#longread) commentary by IT people located here.

One of Microsoft's basic strategies has been to get developer tools into the hands of users and to simplify "programming" so that those users can be effective. They even invented a term for this new class of empowered users -- "power users". Excel is a result of this strategy. In addition to a rich language of functions, there is also a macro facility built on VBA. Word, Excel and Outlook are all automate-able tools for people who aren't professional programmers. Even Microsoft's Access database is more aimed at "power users" than full-fledged coders. (Plenty of people who wouldn't know how to start coding an IIS/SQLServer or LAMP web site are perfectly comfortable in Access. I'll even go out on a limb and say that Access works great for some projects. I've certainly said that before.)

 

Microsoft is continuing this strategy with it's latest "BI" initiatives. BI takes the drudgery of coding reports and puts it squarely in the hands of the users, which actual developers tend to like, while exploiting the power of modern computers. More on-target for this blog entry, it allows people to do even more with Excel. Great -- as long as we realize that this strategy is not without risk. Many users (and their managers) do not grasp why IT departments spend vast sums on QA. Perhaps those users need to lose vast sums before realizing that QA is an investment and not just an expense.