Archive for August, 2010
Reflections on the book A Mathematician’s Lament by Paul Lockhart
Because I am an IT professional, many people assume I must love math. While I did OK at math in school, I never really enjoyed it. A Mathematician’s Lament goes a long way to explaining why.
In contrast, I remember vividly my first contact with computers. I was in grade 5. I had Mr. B. (one of those cool male teachers who went by his initial only). The computer was an Apple II E. The code he showed us was simple:
10 PRINT “HELLO”
20 GOTO 10
Of course, this meant the computer would print HELLO forever, or at least until you hit the ESC key. I was immediately stuck by the infinite potential of a machine that did exactly whatever you said. I would go on to spend years tinkering with code, writing home-made computer games and otherwise experimenting with these great machines (one silly experiment involved seeing how much abuse a 5 1/4″ disk could take before becoming completely unreadable – surprisingly, it could take a lot!) I went on further to win multiple awards as a top computer student and yet never really pictured myself working with them, doing a business degree instead. Computers were for fun!
Math, on the other hand, was pure drudgery. The timed multiplication table quizes in elementary school were the worst – to this day I freeze up on any short timed event (I am unable to play Scategories with the timer). Throughout my mathematical education, I often thought “if only I could get a computer to do all this!” Mathematical proofs in high school were no better – I took them as exercises in irrelevance that simply had to be memorized. My success in high school math came only from monotonous repetition of exercises. I took out my frustrations in math with a doodled character I named “Math Man” who had gone insane because of math, loosely based on Bloom County’s Bill the Cat.
Once in second-year university, an economics professor realized that most of us had no clue about calculus (even after finishing 2 courses on it) so he took the time to give us an economist’s eye view of calculus, and for the first time calculus actually made sense. Sadly, moments of inspired understanding such as this were few and far between.
What Lockhart tells us is that the way math is taught in schools is wrong. It kills creativity, innovation and true understanding. I agree completely. Lockhart argues that if music were taught in the same way, students would spend years transposing written music from one key to another but never hear a song. He argues that high school math proofs are written in jargon and incomprehensible, even to most mathematicians. For a truly successful mathematical education, it needs to be experimentational and even fun. Math education should involve play and discovery, puzzles and games, and moments of eureka!
In a sense, my education in computers and mathematics gave me very opposite experiences. One was fun, free-spirited adventure; the other boring, formalized and sterile. Lockhart tells us it doesn’t have to be this way. I highly recommend his book to anyone who felt that his or her mathematical education was a waste of time.
“Don’t Panic!” – The Hitchhikers Guide to the Galaxy
I often find that when business users are faced with large, even colossal, discrepancies in data sets, their first response is sheer panic. For me, the larger the discrepancy the calmer I am about it. Why? Because discovering source problems in data sets is almost always much easier the larger they are. The truly bedevilling problems are the inconsistent, small, and seemingly random discrepancies that occur.
What do I find the number one cause of numbers being 5, 10 or even hundreds of times greater than they should be? A time series snapshot that is summing all time periods. This is remarkably easy to fix, and can happen easily in a data cube without proper current time period settings. It is a common mistake for junior report developers, especially when they are expecting to see current period only.
Other common and simple problems include rounding errors or inconsistencies, improper unit of measure calculations, unexpected null values nixing a summarization total, or cube update failures. Always check for obvious and easy solutions first, and work your way down to more complicated resolutions as necessary. Note when a problem started and attempt to isolate what has changed since then. Be methodical and don’t panic!
Self-Service BI can be a wonderful thing. Ideally, business users will have a wealth of corporate information at their fingertips and be able to produce meaningful reports quickly and easily themselves, freeing up time for BI developers to work on other meaningful BI initiatives such as scorecarding, data warehousing, data mining – just to mention a few.
The real danger, however, is that Self-Service BI can be an IT driven initiative to reduce workload on itself, often resulting in a product built entirely from an IT perspective with limited input from business since they are often “too busy” to talk about BI. The end result can at best be confusing and at worst useless to the business user community.
In my experience, the best results in BI are achieved when developers and business users work closely and collaboratively on business and technical issues. When the developer or data modeler can understand the business being modeled and the business user can understand the basic technicalities of the design, a true win-win can be achieved. This is not to say that a developer must fully understand the complete business end-to-end, or that the business user must understand each line of code. But when each can see the solution from the other’s perspective, an optimal solution is close at hand.
Overall, Self-Service BI can be successful if:
- The scope is well defined
- The business is well-defined and understood by developers and modelers
- Business users are active participants in planning, designing and testing
- The business user community is well trained in the BI environment’s reporting tools
This last point is particularly essential if business users are expected to create their own reports.
In this final entry in our series on the SDK we’ll touch on Cognos Extended Applications, a set of JSP tags that enable the development of custom “portlets” that can be hosted by a number of “portal” applications, including IBM’s Websphere portal and SAP’s Enterprise Portal (as well as Cognos Connection, of course.)
JSP technology includes the ability to create custom tags that contain back-end code. Just as a set of tags like <a> </a> means something specific to the browser, and <%> </%> are used to demarcate code that will be executed on the server side (but is contained within the JSP page) the user can create tags of their own that will call code when the page is rendered but exists in a java class the user has created.
The Cognos SDK includes several tags libraries that can be used to create JSP pages that can then be registered with a portal. Once again, these libraries enable the user to essentially perform any task that can be performed through the normal interface, but extended or combined as the user wants. Once registered the JSP portlet will be available to users of the existing corporate portal. The details of registering a JSP page with the portal vary with the portal being used.
The Extended Applications approach is ideal for the development of content you want to present within an existing portal, but it is complex, and requires the use of the JSP portion of the J2EE stack.
Cognos security in its simplest form is very straight-forward: You either can access the Cognos environment or you cannot. Typically most Cognos clients I know shy away from highly complex hierarchical security implementations within their organizations, where managers, regions, departments and/or VPs all have specialized access rights to reports, filtered data or even column-level control. Security is usually broken down into a very small number of groups (if even that much) and reports are usually on a “see-it-or-not” approach.
The reason that most Cognos security implementations are kept so simple, I believe, is that managing a highly complex Cognos security implemenation is a real chore. The more granular and complex the security, the more burdensome the task. Furthermore, this is not a one-time setup task, but an administrative requirement to maintain for the life of the Cognos environment, as users move around the organization.
But there is a product that can help.
I recently attended a demo of Security Studio by First Quarter. The product allows you to define security easily throughout your Cognos 7 and Cognos 8 environments. You define your users, groups, roles and rights with a simple interface, and then Security Studio updates these security settings in the Cognos environments. I could easily see how this would be a huge time-saver for a complex hierarchical security implementation. It’s certainly worthy of consideration if you are mantaining or considering a complex Cognos security environment.
A Book Review of The Math Instinct by Keith Devlin
As part of my summer reading, I read the fascinating and informative book The Math Instinct. This included an interesting journey through mathematics in the natural world, plus a review of how math works in the human mind. It was this latter part that really intrigued me the most.
The book opens with recent studies that show newborn babies have the innate ability to count to 3, even at a few days old. It turns out all humans, including the ancients, have the natural ability to count one, two and three. In fact all numbering systems use a similar system to show these numbers as either a dot or line. What about our representation of 1, 2, 3? Looking back at the ancient Indian script these numbers are based upon, they match the pattern as well:
1, 2, 3 in modified Ancient Indian script (without lifting the pen)
What’s more, studies show that people are very good with arithmetic when it is used in a meaningful context. Children shopkeepers in Brazil were shown to have good math skills at their market stalls, but failed abysmally at identical math questions in a formal classroom setting. The same was found with adult shoppers and carpenters. Why? Because when math is reduced to symbols it quickly loses its meaning to most of us.
And what about those pesky times tables? Our minds are made to recognize patterns, and it is this pattern recognition that messes us up when it comes to multiplication. A typical six year old child has a vocabulary of between 13,000 and 15,000 words but will struggle to learn the 18 numbers in the single digit times tables times (removing repeats and simple ones like times 1, times 2, and times 5). It is pattern interference that prevents us from learning this easily.
In short, we are all better at math than we give ourselves credit for. We have no trouble determining the larger size of a product when shopping and we are very good to spot a bargain. This book will help you see math differently, and open up your mind to the possibility that we may all be math-smart after all.