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»»»

In Praise of Barebones Applications Expand / Collapse
Author
Message
Posted Wednesday, September 30, 2009 8:57 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 2:46 AM
Points: 575, Visits: 2,500
Comments posted to this topic are about the item In Praise of Barebones Applications


Best wishes,

Phil Factor
Simple Talk
Post #796115
Posted Wednesday, September 30, 2009 11:07 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 2:50 PM
Points: 36,711, Visits: 31,159
I'm all for POP (Proof of Principle) code... the problem is, that people don't make such code scalable to begin with. People want the code real bad and that's the way they get it. It's usually undocumented, slothful, and sometimes inaccurate. The biggest problem is that it appears to work and who would ever go back and fix something that works?

There's nothing wrong with people using spreadsheets to explore possibilities nor to even run the business especially if they're good at it (and many are). Spreadsheets were the first form of wide-spread BI. The key is to provide those spreadsheets with common and accurate sources of data in a timely fashion. Spreadsheets also allow the users to experiment with the data to do critical what-ifs and a host of other things including formatting the data the way they want to present it.

I think most shops have gotten carried away with such PITA tools as Business Objects, Reporting Services, and a whole host of other reporting software. Let people play with their data... help them do it in a consistant manner by providing it in a timely and consistent manner.

A great example of what I mean occurred at the shop I was recently working at. The rule was that Reporting Services was the tool that users would use to get the "data". They couldn't get it in the format they wanted so they could "what-if" the hell out of it, so they ordered a report that would return nearly half a million rows. Of course, Reporting Services hurled on that. Cut it short folks... if you don't want to make a gazillion ad hoc reports each month, give the users the raw data (gen it from a stored proc) and let them play with it. It's actually what they get paid to do.

The problem with that suggestion is that 5% of the people have screwed it all up for the rest of the world necessitating such things as SOX which can pretty much put the kabosh on such things.

So, let's flip this around... the users need to be patient and helpful to IT because IT is trying to do their job, as well. That job would be to not only correctly insert or gen the data, it must also protect the data by lawful edict. Hell, they can't even purge old email messages anymore unless they've been archived. They're just doing their job and if you want them (IT) to help you, then you have to help them a bit, as well.

Remember... you're all in the same company. Make it work, folks.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #796138
Posted Thursday, October 1, 2009 4:38 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 19, 2012 2:17 AM
Points: 4, Visits: 50
Phil

Yippee! Someone's talking sense for a change! Written specs can never fully cover what users actually require. The simple reason is that translating what they want on to paper is not the same as seeing it on the screen. So many times when I show a screen to users they pick up items that are missing or not required, and ask questions like "How can I do XYZ from here?". Feedback is so much more useful and the customer is involved in the process. A win-win every time.

Well done Phil.

Ian Logan



Kind Regards,

Ian Logan
straker.com
Post #796242
Posted Thursday, October 1, 2009 5:51 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Tuesday, May 20, 2014 4:09 AM
Points: 100, Visits: 111
I think the problem IT departments have is lack of control. If these little applications are developed beyond their control, IT are left holding the can when the developer leaves. If they know a) that something is being developed, b) what it is supposed to do, c) where it resides, d) what the dependencies are and e ) who the users are then they might have a chance of fitting it into their overall strategy. If these things are done then these little ad-hoc applications are quite good for capturing requirements, demonstrating functionality and keeping the business going.


Post #796262
Posted Thursday, October 1, 2009 6:46 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, July 14, 2014 4:59 PM
Points: 19, Visits: 67
xnfec is on to one of the core problems with "give it to me fast, cheap, and working". You just can't do all three.

One of the key issues I've seen with doing quick and dirty barebones proofs as a "demo", is that they *always* end up in production just the way you finish them. The "we'll fix it later" mentality that supposedly accompanies these projects turns into "that works just fine as it is" (with its un-normalized Access database running on Susie's machine in the break room), and then you're off and running to the next whim that the business users come up with. You never get the chance to go back and re-do that application correctly. Further, six months down the road when that crap-app is losing data, has totally farked up all of its primary keys, isn't actually working the way they thought it did, the Ambulance Chaser that wrote it is nowhere to be found, and the company is having a complete and total meltdown, people get incensed when you tell them that it will take weeks or months to fix it (and the data may be gone for good) instead of the few days that a properly developed app may have taken had it been done right in the first place.

While I can certainly see the business users' distress at their great new idea taking longer than they'd like to implement, I also agree that many applications are over-engineered for the sake of over-engineering (or for the sake of using that shiny new technology). I do think that a balance can be struck between sticking to some good core design principles, building in a touch of scalability (but maybe not that full-blown effort you'd like to do), and that the app can be kept under the aegis of KISS to satisfy the need for faster development time, but also making a little time for ensuring data integrity, some amount of scalability, and ensuring that you have an app that is functionally sound. The key is having strong project managers or lead developers that are able to sit with the business users and strike that perfect balance.

I've been the victim of a department hiring some outside yahoo (the guy wasn't even skilled at his job), and then getting incredibly angry when we denied their out-of-the-blue requests for unrestricted access to some of the most sensitive data we had. In point of fact, we had no idea they had even hired this guy, no clue what project they were trying to embark on (it turned out to duplicate almost perfectly our already underway data warehousing initiative), we just knew that they suddenly wanted su level access to our databases. Of course we said "absolutely not" when they refused to even provide us with a reason that they needed that access. The first we heard of their project was when we were pulled into a meeting with the entire pantheon of top executives for a chewing out for being "territorial" and "obstructionist". It was a mess.

Certainly the key is in good communications between stakeholders and IT management and architects/leads. The business users have to understand that good IT staff are working to ensure the company isn't sued into oblivion/can pass IRS/Security Audits/can keep the IP safe and intact, and IT users have to understand that business users are trying to hit that next big thing before the competition does to keep everyone's paycheck coming every two weeks. If both sides can understand the challenges that the other side is facing, a balance can certainly be achieved to satisfy as many goals are possible between the two groups.
Post #796282
Posted Thursday, October 1, 2009 7:01 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:55 PM
Points: 2,656, Visits: 19,182
Garry, I think that's part of Phil's point and part of the problem though, that the IT side feels that they don't need to keep the business side informed or vice versa. If the business side had known of your data warehousing initiative, would they have wasted time and money on a consultant? Probably not.

If the business would tell IT their critical needs, and IT would tell the business what their plans are already and what is available for their use, I think lives would be better. Mine would, anyway.


---------------------------------------------------------
How best to post your question
How to post performance problems
Tally Table:What it is and how it replaces a loop

"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Post #796290
Posted Thursday, October 1, 2009 7:14 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, July 14, 2014 4:59 PM
Points: 19, Visits: 67
I probably wasn't entirely clear. Executive was fully informed and aware of our initiative. They were not, however, informed of the other department's (department in this case being a semi-detached sub-unit of the business - think like a Mortgage Company running under the roof of a Real Estate Company) initiative, and in fact, we found out later, had no idea she had been out spending money on IT Consultants. There were a myriad of communications failures on that one. :)

Both sides of the house definitely need to get past their stereotypes of the other and communicate more to help the business leverage both sides' assets more effectively. :)
Post #796299
Posted Thursday, October 1, 2009 7:20 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 12:30 PM
Points: 3, Visits: 58
In my experience, the most effective app development happens when there is a more fuzzy line between the developers and their clients. In my company (a large manufacturing company), we ask that each client designate a superuser. This is someone who understands their business very well and also has a good "sense" of how data moves and is stored, especially in their specialty area. This person is heavily involved in requirements gathering, testing, and training. We've also benefited greatly from having developers that have some hands-on experience in the client's business. This allows the developers to anticipate future gotcha's, develop a best-practices approach to the app's workflows, an council the client on what they really need, rather than what they think they need. Using this perspective, we've found that business knowledge is almost as important as technical knowledge.


Post #796306
Posted Thursday, October 1, 2009 7:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, October 2, 2009 6:43 AM
Points: 57, Visits: 151
Excellent topic!!

I've been on both sides of the fence over the past (too many) years.

On one side (A) as a mainframe programmer in the USAF, software developer, and consultant, and on the other (B) as Director of Customer Support and Estimating for the #3 metal casework manufacturer in the US.

On side A, I spent weeks or months building applications for users that never seemed to know what they wanted.

On side B, I got fed up with IT people that couldn't understand that I needed to be able to grab whatever data I needed at the moment and view, manipulate, or report it instantly however I needed it to be done.

I am now in the middle (side C??) as a systems analyst again, and am again frustrated by IT. If have had a DBA tell me that "users should be able to download data to excel and play with it." The attitude being that users should only be able to access the data through the "formal" ERP system and IT approved tools.

I say "baloney". If the most effective way to "get the right data into the right hands at the right time" is via a quick and dirty Access download and export to excel, than that is the right way to do it.

I can write SQL queries, but it is orders of magnitude faster for me to develop in Access via "drag and drop". And, since Access optimizes the query before passing it on to the SQL server for execution, I believe there is very little additional overhead executing the query on the SQL server.

And I've also encountered a "one size fits all" mentality that says "all the ERP screens and reports must look the same in every division because that is what's best for IT."

This is insanity at it's finest. Each division started out as a separate company and has different products and needs. To say that they should all use exactly the same program in exactly the same manner is as idiotic as saying that everyone should wear 8EEE shoes because that is what I wear.

IT should be responsible for the physical security and integrity of the data only. They should have people on staff and qualified in the enterprize package, and also have individuals that understand how users can take advantage of tools such as MS access/Excel for ad hoc information requirements. This means understanding how to set up ODBC connections, etc., and know how to kill errant processes (such as open join queries) if necessary.

They should also create an end users training in powerpoint, etc. on how to use tools such as access for quick and dirty reporting or exporting to Excel. They should also train "Key Users" in each division that could then work with that division's users to develop the quick and dirty apps. We all know of an in house "expert" in MS word, Powerpoint, and usually Excel. Why not have the same type of person for Access?

This would then relieve IT of virtually all of the tedious "one off" requests from end users and allow them to focus on truly business wide needs.

It would also broaden the base of knowledge so that there is less likelihood of a "developer" leaving and IT getting "stuck,"

Data isn't information until you can make sense of it and use it in a meaningful manner. Users are the ones that do that. Realistically, IT doesn't. Therefor it makes sense to provide users with tools that allow them to access and manipulate data in whatever way is most effective for them.

Just my NSHO...
Post #796308
Posted Thursday, October 1, 2009 7:58 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
I'm firmly in the "incremental improvements" camp. Build something that does something useful for the users. Then add to it incrementally and constantly review for potential improvements. Be ready to drop whole sections of functionality and code if they are no longer needed/useful or if they can be supplanted by something better.

Extinction is the result of too low a mutation rate in a changing environment.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #796344
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse