Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

Uncontrolled Code Expand / Collapse
Author
Message
Posted Tuesday, January 21, 2014 4:15 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:50 PM
Points: 5,604, Visits: 3,457
I consider them more of an evolutionary prototype where eventually they MAY require a "proper" solution. Depends on all the factors previously mentioned (by me and others) and probably more factors besides.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1532955
Posted Tuesday, January 21, 2014 4:36 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, September 18, 2014 2:43 AM
Points: 100, Visits: 795
"I think this is where things like MS Acces / Fox Pro / Lightswitch etc are excellent."
Ditto, couple Excel to Access and most of these problems disappear.
Post #1532960
Posted Tuesday, January 21, 2014 5:02 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 28, 2014 5:08 AM
Points: 11, Visits: 36
grovelli-262555 (1/21/2014)
"I think this is where things like MS Acces / Fox Pro / Lightswitch etc are excellent."
Ditto, couple Excel to Access and most of these problems disappear.


Well, it's horses for courses, it depends what they're doing and the risk involved - If you're managing the risk profile of a multi-billion pound/dollar investment bank on a spreadsheet which it outside all normal IT governance and has never been independently tested, is not subject to change control and source control, then when the inevitable problems may well have a big effect,

Same goes for many many uses of EUCs on a more usual scale: if it's used for inventories of office supplies in an SME, then no problem, if it's used to calculate the bonuses of sales teams, you should probably go through the normal SDLC and not let the work experience kid throw something together.

If you read that research from the UOH: http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm
It shows - and we all know this - that even experienced developers make mistake in code. The problem with EUC and Excel in particular, that thos problems don't get picked up because of lack of testing and/or code review - and given the nature of Excell, that individual cells contain their own code and you can't easily see logic errors at a glance - even those good practices don't get picked up. The takeaway from that research is "Spreadsheets WILL have errors and they're hard to find" and the more complex the sheet, the more those errors will compound.
Post #1532968
Posted Tuesday, January 21, 2014 5:52 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Yesterday @ 2:18 AM
Points: 54, Visits: 369
chris.smith 91049 (1/21/2014).............. The takeaway from that research is "Spreadsheets WILL have errors and they're hard to find" and the more complex the sheet, the more those errors will compound.


Chris, all applications will have errors, I haven't found one app that hasn't but still live in hope.

I have heard that MS Access:
* has been used for years to provide the fuel calculations for an air fleet of a world leading airline.
* used to track the sales of $1 billion because it was more flexible than Oracle financials

Yes, neither of these is best practice and I know that a lot of IT pressure was made to get these changed. But the different IT departments could only promise a deadline that was months/year away which was unrealistic for the business operation and profit margin.

I would prefer that the logic was in sprocs and constraints but it is only a preference and not the only way of meeting business requirements.


Post #1532993
Posted Tuesday, January 21, 2014 5:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 3:50 AM
Points: 125, Visits: 675
I think we often forget that businesses don't exist to use our software or follow our procedures. They exist to deliver a product or service to a customer and, in so doing, make money. If our software and processes facilitate that we can expect the business to engage with us. If we obstruct that the business will turn away... and will be right to do so.

I think Steve's final sentence was telling. We need to deliver solutions faster than the business unit can develop their own. That might be an all singing all dancing fully integrated system or it might just be sitting down with the user and helping them write the spreadsheet. I absolutely agree that we should put as many development tools as possible in the hands of users and then be there to support them when they need us to.
Post #1532998
Posted Tuesday, January 21, 2014 6:24 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 28, 2014 5:08 AM
Points: 11, Visits: 36
FunkyDexter (1/21/2014)
I think we often forget that businesses don't exist to use our software or follow our procedures. They exist to deliver a product or service to a customer and, in so doing, make money. If our software and processes facilitate that we can expect the business to engage with us. If we obstruct that the business will turn away... and will be right to do so.

I think Steve's final sentence was telling. We need to deliver solutions faster than the business unit can develop their own. That might be an all singing all dancing fully integrated system or it might just be sitting down with the user and helping them write the spreadsheet. I absolutely agree that we should put as many development tools as possible in the hands of users and then be there to support them when they need us to.


I absolutely disagree - we don't have a hope in hell of developing faster than users can knock something up in Excel or Access - as long as we're following best practice and designing systems, testing them and reviewing them, practising standard change control practices etc. So it's not a fair comparison.

Obviously, those take up more time than if you don't have to do them, but quite often the quality threshold is much lower for EUC and they release then test and fix things on the fly - often introducing new errors. A professional dev team would never dream of doing that for very good reasons. In almost every field of human endeavour, a quick shabby and substandard version can be done quicker, and the challenge to build a better version doesn't usually have the time constraint that it must be as fast as the lowe quality one.

Putting development tools into the hands of users may seem attractive at first - it gives them results fast and takes the pressure off dev - and for very very constrained tools, that's fine - I remember a time when IT would be responsible for producing presentations and I think Sharepoint is a massive step forward in user empowerment. However, Excel is an extremely powerful tool and is often used as a fundamental step in important business processes, but in common usage doesn't have the checks and balances that you'd hope a formal SDLC process would build in.

The challenge is pointing out to proponents of EUCs what the problems in their approach are, and be flexible enough to know when to leave them alone to do their own thing.

However, like I said before, often the problem is one of short-termism - an end user doesn't give a toss about the big picture or future-proofing, they're under pressure, they're overworked and they're looking at a fix for that problem. However, they're probably ignorant of the risks inherent in their approach. A good company will have policies regarding the use of EUCs and try to limit the amount of it, reduce risk from it and/or ensure that there's an appropriate level of oversight and control of their development.

Post #1533013
Posted Tuesday, January 21, 2014 6:26 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 9:12 AM
Points: 672, Visits: 6,767
Excel can be great in the right hands, your worst nightmare in the wrong hands.
Yes, it is no surprise that it costs money to build a data warehouse, or create more controlled processes when reporting results.
But when everyone top to bottom can use the same data source and logic to get to the same results, a couple of wonderful things happen.
With more eyes on the data, rules are tweaked, or incoming data gets cleaner.
Less time is spent questioning results, more time is spent top to bottom working towards improving them.
Business Rules need to be in formal processes, whether in Excel, or in a data warehouse.

Excel can be a great tool to prototype with, and is a user friendly way to work with data.
Many of the workbooks I created for the business led to expansion of measures and dimensions in the data warehouse.
Take a look at PowerPivot, then how it can be in a published workbook in SharePoint (control).
Then with SharePoint 2013, you can actually use this data model and enhance it.
So it does start bridging some gaps when used in certain ways.

I've been on both sides of the fence - Excel programmer, and BI Developer.
So I have had exposure so some of the best and worst that can happen in both worlds.
Post #1533015
Posted Tuesday, January 21, 2014 6:49 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 2:29 AM
Points: 723, Visits: 122
The auditing (or not) of these Excel application that are created by various people around the business is what is the most dangerous thing. I have done a fair bit of Excel development in my time and in one large retail organisation, buyers were planning their ranges on spreadsheets that they had created themselves or inherited from the previous buyer for that department and presenting their forecasts based on this data. When developing a company-wide replacement, we kept the front-end in Excel, in a locked-down state, and provided a database back-end for it with all the formulas and calculations agreed by management. When these agreed formulas were compared to what was in the original spreadsheets created by the buyers there was quite some variance!

We often talk about several versions of the truth in databases throughout a business, Excel is the ultimate tool for this to happen. As well as people working in silos with separate spreadsheets of the same data giving differing results, I have also seen people spending time reconciling spreadsheets against each other which seems to me like a complete waste of time.

As an IT professional, I would love to see data provided in a user-friendly consistent manner all the time from a trusted source, but the ubiquity of the "Export To Excel" option on a large number of applications makes it so easy for users to grab some data and start manipulating it that I don't see that genie ever being put back in the bottle.
Post #1533029
Posted Tuesday, January 21, 2014 7:12 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:50 PM
Points: 5,604, Visits: 3,457
chris.smith 91049 (1/21/2014)
FunkyDexter (1/21/2014)
I think we often forget that businesses don't exist to use our software or follow our procedures. They exist to deliver a product or service to a customer and, in so doing, make money. If our software and processes facilitate that we can expect the business to engage with us. If we obstruct that the business will turn away... and will be right to do so.

I think Steve's final sentence was telling. We need to deliver solutions faster than the business unit can develop their own. That might be an all singing all dancing fully integrated system or it might just be sitting down with the user and helping them write the spreadsheet. I absolutely agree that we should put as many development tools as possible in the hands of users and then be there to support them when they need us to.


I absolutely disagree - we don't have a hope in hell of developing faster than users can knock something up in Excel or Access - as long as we're following best practice and designing systems, testing them and reviewing them, practising standard change control practices etc. So it's not a fair comparison.


Sometimes being involved from the start requires compromise. A tactical solution (e.g. Excel) can be a valid choice until a strategic solution can be delivered. This also allows for the time to do the job like a craftsman!!! (using the non-gender specific of man)


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1533041
Posted Tuesday, January 21, 2014 7:20 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:14 AM
Points: 2,605, Visits: 3,956
Being a developer, I usually agree that a "proper" application with a "proper" database is better than an Excel solution. There are times, though, where an Excel solution makes sense. Excel does not suck; people do. It's the people putting together the solution, be it a "proper" one or an Excel one, that determine if it's good.

Tom

Post #1533052
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse