Data Warehousing & Data Academy Blog
http://dataacademy.blogspot.com/
A good friend of mine is a top High Street fashion designer.
(I'm not going to name-drop; or "out" her as the kind of girl who hangs out with computer programmers! But suffice it to say that, if you are in an office right now, there is a good chance that somebody around you is wearing one of her pieces.)
In a recent conversation, she talked about the importance of "brand identity". It isn't enough to create a beautiful shirt - it has to be part of a collection, which itself has to be a part of a brand; because it is that with which the customer ultimately identifies. And so if something doesn't fit with the "band identity" - it is discarded, because the customer just won't buy it!
So, what has this got to do with anything?
Well... I am often asked about particular approaches taken by Data Academy. In particular, the behavior of the User Interface.
Wouldn't it make sense to put these check-boxes on a tab?
Isn't it more logical for this screen to have the button here?
And I've always struggled to answer these questions. But it occurs to me that although these issues arise in isolated contexts, the answer is that we have to look at the software as a whole - and in this sense, it is all about "brand identity"!
We could put the check-boxes on a tab, but we don't do it anywhere else, so we've compromised our brand identity... and the customer won't "buy it"! (Albeit using "buy it" in this sense to indicate acceptance rather than purchase.)
Now, I will freely admit that the fact that Data Academy even has a brand identity, was happenstance as much as anything else - it arose out of the employment of a fairly rigid, but highly economical UI framework.
But it was good happenstance - and when I next design a piece of software from scratch, it is something I intend to remember.
As developers, we have been taught that code re-use is A Good Thing (TM). But as anyone who has ever eaten two liters of Ben & Jerry's Chocolate Chip Cookie Dough Ice Cream in a single sitting will tell you, you really can have too much of A Good Thing.
(And... yes... but it was the 90s, man, and if you weren't there... you wouldn't understand!)
But to get back to the code for just a moment...
I've been bitten more than once by the following pattern.
You create a function called DoStuff() which does... well... "stuff".
Then, a few weeks later, you find yourself needing to do "stuff" again... but ever-so-slightly differently. So, you re-use DoStuff, resulting in DoStuff(bool slightlyDifferently).
Some months down the road, you need to DoStuff again, but this time in Oracle. So now you have DoStuff(bool slightlyDifferently, bool inOracle).
You see where we are going with this? It is re-use, for sure, but it is already starting to have abusive undertones.
(And let's not even think about what happens when you start using optional parameters in VB.NET!)
As I've become more experienced, I've learned how to re-factor-out these kinds of issues before they occur - sometimes, at least*!
But recently, I realized I've unwittingly taken this problem to a whole new level in the Data Academy UI.
Regular users of Data Academy will know that STAR-it and (new module) MAP-it are sub-classes of TRANSFORM-it; and although the UI contains dedicated top-level forms for each module, the "detail" forms are simple re-use - a single form, with a lot of code which looks like this:
If TransformationType = STARit Then
____FactDimensionPanel.Visible = True
Which is fine... except for the fact that we also have "If" conditions for pivot, un-pivot, Slowly Changing Dimension, etc. etc.
And then we added MAP-it!
At the time of writing, I still haven't figured-out exactly what the answer is. The textbook solution would probably include the word "sub-controls" but I'm not convinced that does any more than cut the problem up into small pieces, and bury them even deeper; because the sub-controls would still have to expose various conditions and parameters of their own.
And yet, I have to do something because I am starting to compromise the sensibility of the UI itself.
I know... I'll add another parameter!!!
(UPDATE: Yup - adding another parameter is exactly what I did! Wanna know more? Ask us about a BETA of 5.6!!)
-------------------
* If you ever get the opportunity to look at the method signatures for the Data Academy Database Installer... please don't!
There is always something to do in a garden - mow the lawn, trim the hedgerow, prune the roses - the work never ends!
And computer software is the same - that's why I've recently been on gardening leave!
No, no, no - not THAT sort of gardening leave - Data Academy haven't fired me... yet!
But I have been 'gardening' my software - taking the time to untangle some of the thickets which have grown-up over the years - doing those little jobs which I KNOW I should do, but which I don't otherwise get around to.
So, what about you? Have you got a Stored Procedure which needs commenting? Or a STAR-it Star Space which requires indexing?
Then, why not ask your boss for some gardening leave?
Only...
... perhaps you'd better not call it 'gardening leave'!
Read More...