September 30, 2009 at 8:57 pm
Comments posted to this topic are about the item In Praise of Barebones Applications
Best wishes,
Phil Factor
September 30, 2009 at 11:07 pm
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
Change is inevitable... Change for the better is not.
October 1, 2009 at 4:38 am
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
Ian Logan
straker.com
October 1, 2009 at 5:51 am
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.
October 1, 2009 at 6:46 am
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.
October 1, 2009 at 7:01 am
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[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"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."
October 1, 2009 at 7:14 am
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. 🙂
October 1, 2009 at 7:20 am
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.
October 1, 2009 at 7:23 am
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...
October 1, 2009 at 7:58 am
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
October 1, 2009 at 8:03 am
GSquared (10/1/2009)
Extinction is the result of too low a mutation rate in a changing environment.
And that is the best argument so far. Nice one, Gus.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"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."
October 1, 2009 at 8:16 am
I agree with Phil. IT too often these days is so concerned with preservation and protection (of data, systems, etc.) that they forget the root reason for their existence, which is to service the other parts of the business.
On the one hand you hear horror stories where an outside clueless developer was brought in and wreaks havoc and destruction on the existing IT structure. What is never mentioned was the direct and indirect stonewalling that led to that outsider being hired in the first place.
I am currently working as an IT asset owned by the marketing department. I got hired specifically because I can and will build things quickly and I look for ways to get things done without requiring lengthy requirements docs, business case analysis or other red tape.
Since I live outside the main IT group, I spend a lot of time having to justify any request I make to them, things that would be granted by default if I were part of their group.
One of the main things I do is maintain and support a MS-Access app that was developed in the marketing department after the IT group told them that what they wanted 'couldn't be done.' So they went and built it in Access, all the while the IT development group was telling them how this Access app would fail and couldn't possibly be stable or reliable. Four years later this app has become mission critical to the department, has been more stable, responsive, and accurate than the vast majority of the IT developed apps rolled out in the same time period. It started as an Access only app. When I came in, I switched it to a SQL Server backend, and now we are looking to replace the Access front-end with Java, but in the meantime the Access app, very much built a feature at a time, has done what the IT group said couldn't be done.
October 1, 2009 at 8:18 am
Lots of great comments, most of which I agree with so I won't repeat it all here. I think the discussion demonstrates why there is a move twoard hiring IT people who can bridge that gap between IT and the business users. That communication gap is the biggest problem we face as IT professionals, IMHO. In my own experience, projects where there is a close connection with the business unit are the most successful. Projects where there is a disconnect from the business unit were rarely successful, and always delivered over budget and well beyond the due date.
I've seen people on both sides of that IT/business unit gap try to bridge it, and other people on both sides who try to widen it. The trick is to support the first group, and either retrain or "offer other options" to the second group. Which requires management buy-in to the philosophy that the two groups can and should work together. Sometimes that means shifting the corporate culture, which requires some heavy lifting to say the least! I've never seen a successful corporate culture shift without at least one champion at the executive level pushing for it, and convincing the other executives to support it.
It's very frustrating, I think, for the people who see the need and the solution, but are unable to implement it. Sometimes it leads to liasons between business units and IT that are below the "executive" radar. While that works for the departments involved, it really is a pity it can't be spread corporate-wide, since it is so much more effective for the business. I think that companies that fail to realize the benefits of an IT/business unit hook-up will be much less successful in the future, because change is happening at such a rapid pace and that pace will be increasing. Less successful = less competitive = how long will they stay in business?
Which type of company would you rather work for? And how can we help move our own company in that direction? Food for thought.
Steph Brown
October 1, 2009 at 8:26 am
Stephanie's post seems like a good transition here, I just saw this article in an ACM newsletter, and am now wondering if this would serve to widen the gap or shrink it? If we don't accept anything less than perfect (as is suggested in the link) because it is theoretically possible to determine that, can we support Phil's contention that actionable software should be delivered to end users as soon as possible, and vice versa?
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"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."
Viewing 15 posts - 1 through 15 (of 48 total)
You must be logged in to reply to this topic. Login to reply