GUI Schmooey ‒ You Need to Know Code!

As those of you my age and older may recall, as recently as 20 or 25 years ago you pretty much had to know a great deal about how your computer worked in order to use it effectively (unless you had an Apple Mac). Today, with the dominance of "easy" point-and-click graphical user interfaces (GUI), good luck troubleshooting that error message without programming skills.

Yet in the business intelligence world, you see a lot of animosity toward do-it-yourself coding. After all, technology evangelists proclaim, you can pick from among all sorts of really cool point-and-click interfaces that make BI so easy! Why, the software practically does the work for you!

Does it really? What happens if something goes wrong? What happens if you don't understand something? What happens if, for some reason, you need to manually look at or edit something?

This is not even to mention the extensive (and expensive) training issues that surround implementation of any new software package.

It's good that technology is helping to make our lives easier (so I am told), but just as many BI specialists prefer to code manually, there's a very good reason why, say, most coding and programming in other realms isn't generally done with point-and-click. Somebody needs to understand just what the heck is going on behind all those fancy GUIs and pretty pictures.

An over-reliance on point-and click means an under-reliance on the fundamentals. Indeed, as at least one anticoding blogger concedes, even enterprises that use powerful extract, transform, load (ETL) tools often misuse them because they don't understand the fundamental concepts underlying data integration. True, good coders do not necessarily make good data system architects, but you cannot create a good data system architecture without a good basis in coding (just as you would hope that the architect of your new house understands how to make good wood joints, even if he's not going to do the sawing or hammering himself).

Worse, because the tools can be frustrating to use sometimes for seasoned developers, some admit to backdoor coding (sometimes undocumented). (See: To Code or Point & Click: The BI Dilemma.) Combined with the superfluous lines of code that point-and-click solutions tend to spew out haphazardly, this kind of work environment can lead to poorly integrated infrastructures and platforms. As Google employee Steve Yegge wrote in an infamous, accidentally public Google+ rant, "The golden rule of platforms is that you eat your own dogfood."

Over time, this sort of scenario can lead to a disastrous BI environment -- and, worse yet, even more reliance upon the tool that helped start the problems.

Powerful data integration point-and-click tools can be great as a supplement to your BI architecture, allowing your data and data-based decisions to be more accessible to your non-technical business users. But those tools should be just that -- a supplement.

Rather than design your data architecture around a single point-and-click software suite that may or may not be your best solution, invest in building a coding-based data architecture (well-documented, of course) from scratch. Then, and only then, look for an "easy" software solution that will fit your architecture -- as opposed to trying to do it the other way around. After all, no business solution is one size fits all. This will allow you greater adaptability (not to mention return on investment) for the long term without becoming too deeply entrenched in "what the machine tells you."

Accessibility is great. "Easy" is great. When it comes to your data infrastructure, however, ease and accessibility are not dogma -- understanding is.

Point / Counterpoint, Attorney & Marketer

Joe Stanganelli is founder and principal of Beacon Hill Law, a Boston-based general practice law firm.  His expertise on legal topics has been sought for several major publications, including U.S. News and World Report and Personal Real Estate Investor Magazine. 

Joe is also a communications consultant.  He has been working with social media for many years -- even in the days of local BBSs (one of which he served as Co-System Operator for), well before the term "social media" was invented.

From 2003 to 2005, Joe ran Grandpa George Productions, a New England entertainment and media production company. He has also worked as a professional actor, director, and producer.  Additionally, Joe is a produced playwright.

When he's not lawyering, marketing, or social-media-ing, Joe writes scripts, songs, and stories.

He also finds time to lose at bridge a couple of times a month.

Follow Joe on Twitter: @JoeStanganelli

Also, check out his blog .

Counterpoint: Train for Data Visualization Skills

Chances are you've already got good data visualization experts on staff, even if you don't know it yet.

Customer-Centric Banking Analytics Scares Me

Banks have tons of customer data at their disposal; unfortunately not all will use it scrupulously.

Re: Architecture for the long term
  • 4/7/2012 11:02:48 AM

True. I guess the main crux of the argument is based on who you ask and their responsibilities within the project or implementation (mostly how difficult their role becomes).

Re: Architecture for the long term
  • 4/6/2012 3:25:43 PM

Hi aaphil,

I commented on your remarks in the counterpoint stream as well. In short, I agree with you and think this holds true for lots of things in life. Solutions need not be mutually exclusive and at times a solution is good enough to move forward with, no matter how strongly some might argue for a perfect solution instead.

Re: Architecture for the long term
  • 3/31/2012 5:33:57 PM

They don't have to be mutually exclusive. In some instances, it works. Some IDE's make it a good starting point with the GUI then the back end coding to advance.

Re: Architecture for the long term
  • 3/31/2012 5:21:43 PM

Exactly there is a big difference between what looks good and what will actually work.

Re: Architecture for the long term
  • 3/31/2012 2:14:18 PM

If you are a developer you do need to know programming and coding, but if you are just an end-user, you can interact with the application via a GUI user interface. An advanced uer can also customize the application via an API (Application Programming Interface), but I don't think that we could expect that from everybody. 

Architecture for the long term
  • 3/30/2012 11:26:13 PM


I agree GUI is great for the demo but it rarely can be scaled for mass usage.




Re: Understand The Code and It's Implications
  • 3/30/2012 5:44:55 AM

I'll add my voice on the middle-ground idea. But the middle should lean towards code side. It is a bad thing to learn to rely on point and click for major system architecture. It is similar to building a house with a weak foundation. You cannot even embed security mechanisms in the code when using GUI alone. Not to mention the basics like troubleshooting, which has a close limit when using point and click. My take: Work with code mostly...use GUI to connect the point to the less tech oriented members of the BI team.

Re: Code and GUI
  • 3/28/2012 12:22:42 PM


Chad I agree that architecture is key to scalable solutions and solutions that can grow to meet the ever changing needs of users, its part and parcel of that marriage that is so elusive.

Re: Understand The Code and It's Implications
  • 3/27/2012 10:20:28 PM

I really like Maryam's position on this and I think from a pragmatic view it is probably the best choice.  Really not necessary to sit on both ends of the extremes.  Those who prefer GUI's should at some point take an interest in coding and the code itself.  I am sure packages offer all sorts of little utitilies that only coding would make possible and the converse could be argued for a purely coding approach - a GUI will be necessary for those less skilled at understanding code.  So Maryam position is probably what will be the case in most cases.

Re: Understand The Code and It's Implications
  • 3/27/2012 9:56:30 PM

Hi Louis,

What do you think about Maryam's middle ground between GUI and coding?

Page 1 / 2   >   >>