Category: Editorial

As this piece shows, more information can be bad. As drivers get more choices, options, and opportunities to interact with information, they may not be driving as well as they otherwise might. Restaurants and retailers have seen something similar. Too much information either prevents decisions or slows the process. I know when I go to a restaurant that has too large a menu, I often find myself taking a long time to decide on an item.

I think this can certainly be a problem for our clients in technology, as we discuss specifications and requirements with them. If we allow clients too many choices, and too many options, it can be hard for them to make a decision, much less understand the implications of their choices. As software professionals, we need to give clients two or three options, but recommend one and explain in a fairly simple manner what the advantages and disadvantages of each solution are.

Too much choice can also be a problem for us in technology. If we have too many architectural options, we can debate entirely too long. If we have too many requirements, we may be unable to get work done if we can’t focus or distill them all down. If we have too many concerns, we may not find an effective solution because we’re looking for a perfect one. The latter is a situation I find all too often with developers that want a perfect, 100% solution when a 90% one will work fine because the edge cases so rarely occur.

The exceptions to this, both in my restaurant experience, and in research, are when the person already knows what they want, or they have some preconceived idea. That can be good for us in technology, as we can move quickly when we have some idea of what is needed. However this is a double edged sword as it can lead us to work with tunnel vision, not thinking about the alternatives or possibilities we may face.

In general I think more information is better than less, but we can’t let the abundance paralyze us from moving forward and accomplishing work.

Steve Jones

Wow, Excel really sucks. To be fair, that isn’t just Excel, but any spreadsheet that’s used to make decisions in business (or government) and hasn’t had proper auditing or checking. Spreadsheets are amazingly powerful and useful, and so ubiquitous that Microsoft gave up on a separate BI tool and built one into Excel.

I ran across this story on a serious Excel issue that cost a lot of money in the London Whale case. There are a lot of comments with the post as well as a discussion on Hacker News as well. I also found this piece on the amount of spreadsheet errors that exist in the world, based on a number of studies. It’s dry reading, and also scary.

As I read through the thoughts and posts, I’m somewhat stunned that we don’t have many, many more business problems because of a spreadsheet being used as an application without any auditing. Perhaps we actually do and just don’t know about it. Perhaps the reason you didn’t get a bonus last year at your company was because of a spreadsheet error. There could have been either an error that caused a poor business decision, or one that incorrectly calculated bonus payouts.

It’s a mess, and I honestly don’t know what to do. A more rigid structure in building applications that are checked, rechecked, audited that can prevent the miscopying of formulas is a great idea, but in the real world, we know it takes too long. Perhaps more time is a good thing and businesses should slow down, especially financial businesses, but I can’t see that happening either. Perhaps we need more tools that handle precedents and dependents. Personally, I’d like to see some VCS hooks built into Excel as well.

The entire process of building applications with spreadsheets reminds me of a race to the bottom, where companies take more and more shortcuts and chances, just because they think other companies are doing the same thing. Ultimately I don’t think we can fix this, but we can try to make a difference by producing software quicker, and pointing out the errors in spreadsheets that become too important. We can meet somewhere in the middle between a full application development lifecycle and total ad hoc spreadsheet based tracking and processes.

Steve Jones