October 1, 2009 at 8:36 am
The problem with "perfection" is that it is contextual. Code that is "perfect" now will be buggy when conditions change.
The idea that someone can "prove" with mathematical precision that a kernel is "perfect" is not only ridiculous, it is down right scary. It suggests that the code can never be improved in performance, effectiveness, or functionality.
Better to consider software as "imperfect" as one can always expect (hope) for it to be improved as conditions and needs change.
Which brings us back to starting with something workable and going from there...
October 1, 2009 at 9:01 am
Great topic. . .with a lot of common sense replies.
I just sent a division business newsletter to some of my IT staff that mentions some technology initiatives that are being done by them as a reminder that what they may do is "technology" but in the end it is really about "people".
Many times we provide read only views to our SQL Server and Oracle databases (being attentive to data sensitivity) for the customer and train on importing and/or linking from Access via an ODBC connection so they can report on their data the way they need. We can't do it all. And that empowers them the way they need to be empowered.
And at the same time that there is a need for speed in what we do, we do need to be attentive to good software architecture, coding and GUI standards, and yes, the dreaded "D" word. . .Documentation! All of that dependent on the estimated lifespan of the system.
October 1, 2009 at 9:01 am
bob.willsie (10/1/2009)
(snip)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.
Access is not aware of the metadata the way the linked database is and therefore cannot make the best decisions on how to efficiently retrieve it.
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.
Agreed, but in my experience, that's not been an IT decision.
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...
I think your mention of "integrity" is key here to the discussion. At what point is the integrity compromised? Certainly from the master table where the data resides, but what about once it leaves the database?
Actual case: Business group has need. IT is not staffed to handle that need as a priority because management has not made that need a priority. But since everyone has Office tools and the business group has demonstrated to management that they can do it themselves in MS Access, they get the OK. Enter scope creep and lack of IT foresight (e.g. scalability and data recoverability), and it becomes a major IT project.
Is IT the problem?
Actual case #2: Business has decided that users need ad-hoc access to ERP data, but has not enforced training requirements for those users. One user decides to make a "temporary" data silo in MS Access for many departments that makes the data look prettier than the monsterous ERP system because IT doesn't have time. However, the Access user is not privvy to business decisions enacted by IT as to the nature of the data, say for example, inventory part usage. So when the definition of inventory part usage changes to exclude certain business activities, suddenly the data silo numbers are grossly inflated. And users are making business decisions (purchasing, forecasting, etc.) off of this data silo and damaging the business.
There's a reason companies have IT departments. And it's up to us to make sure they know why.
My $.02,
Rich
October 1, 2009 at 9:09 am
Actual case: Business group has need. IT is not staffed to handle that need as a priority because management has not made that need a priority. But since everyone has Office tools and the business group has demonstrated to management that they can do it themselves in MS Access, they get the OK. Enter scope creep and lack of IT foresight (e.g. scalability and data recoverability), and it becomes a major IT project.
Is IT the problem?
Actual case #2: Business has decided that users need ad-hoc access to ERP data, but has not enforced training requirements for those users. One user decides to make a "temporary" data silo in MS Access for many departments that makes the data look prettier than the monsterous ERP system because IT doesn't have time. However, the Access user is not privvy to business decisions enacted by IT as to the nature of the data, say for example, inventory part usage. So when the definition of inventory part usage changes to exclude certain business activities, suddenly the data silo numbers are grossly inflated. And users are making business decisions (purchasing, forecasting, etc.) off of this data silo and damaging the business.
There's a reason companies have IT departments. And it's up to us to make sure they know why.
My $.02,
Rich
Rich, both these cases are deficient in communication. If the focus was on the business priority, not the separate priorities for IT vs Business, then in Case 1, IT management would prioritize effectively and solve the problem from the get-go, building a proper solution, and in Case 2, the definition that changed would be communicated back to the business, which would change how they use the data.
Not arguing that there is a reason for IT, but there's a reason for management too, and if they can't communicate what will drive business forward, someone has forgotten the reason.
---------------------------------------------------------
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 9:13 am
Some businesses at least have legal bounds on their information systems, such that software development either in a hurry or by non-specialists can get you into trouble. For instance use of in-house e-mail or instant messaging without logging, or mishandling confidential data... People can go to jail, or their managers can, as a result of having a bright idea and implementing it themselves.
October 1, 2009 at 9:34 am
Developers become recalcitrant only because experience has shown them that
(1) As soon as they develop a quick and dirty Windows app to run on a handful of workstations, management will come along and say "Great! Now deploy it as a web app for these 10,000 users"
and
(2) The temporary solution that you create as a young developer will probably still be running in some form when you retire
So forgive us if we need to occasionally rein in the management hotheads and force them to really think about what they're asking.
All landlords start out being nice people, and all developers start out wanting to agile development. Once reality hits, they change.
October 1, 2009 at 9:36 am
I think communication is key. Unfortunately there is often a huge disconnect between IT and business end users.
IT is important and has a strong position to play in any business. However if that position is always played as "we know best so you'll only get what we give you and how we give it to you", it will lead to exactly the situations that have been described here.
When everyone understands what parts IT does best (data security/integrity) and what part users do best (interpretation of data into information to run the business) everyone wins.
I'll give you an example. Our company has an "IT Steering committee." It consists of top level executives and the IT department heads.
When a suggestion was recently made to add end user department representatives the reply that came back, almost verbatim, was: "The purpose of the IT Steering Committee is for IT to tell the top level executives what IT is going to do. It is not intended to set policy or direction for IT." The response was provided by the head of IT on the IT controlled company web site.
To me this is a clear example of a significant disconnect between corporate end user needs and the IT department. IT is, after all, a service department.
October 1, 2009 at 9:37 am
jcrawf02 (10/1/2009)
Rich, both these cases are deficient in communication. If the focus was on the business priority, not the separate priorities for IT vs Business, then in Case 1, IT management would prioritize effectively and solve the problem from the get-go, building a proper solution, and in Case 2, the definition that changed would be communicated back to the business, which would change how they use the data.Not arguing that there is a reason for IT, but there's a reason for management too, and if they can't communicate what will drive business forward, someone has forgotten the reason.
For case 1, agreed, but IT should not be prioritizing projects. IT does not own the data, the business does. They need to decide, with IT's undivided help, which projects get priority. My original point was that management was not fully aware of the possible ramifications of their decision and IT was either unable to effectively communicate the threat or (much less likely) also unaware.
For case 2, to some extent yes, but I can't see how a business can effectively communicate every business decision to every employee. My example was just one. There are likely dozens, hundreds, or thousands of those that regularly take place. If the data is centrally presented (e.g. from the database via ERP system + DSS package), then changes to the definition of that data can be effectively done completely. If ad-hoc tools are used against raw business data, the integrity of the business data can -- and will -- be compromised.
My point -- sorry, not well stated -- was that app sprawl outside of IT can be damaging. There are better IT solutions for business decision making than ad-hoc queries to raw business data.
October 1, 2009 at 9:41 am
bob.willsie (10/1/2009)
When a suggestion was recently made to add end user department representatives the reply that came back, almost verbatim, was: "The purpose of the IT Steering Committee is for IT to tell the top level executives what IT is going to do. It is not intended to set policy or direction for IT." The response was provided by the head of IT on the IT controlled company web site.To me this is a clear example of a significant disconnect between corporate end user needs and the IT department. IT is, after all, a service department.
Ooooh. Ouch! 100% right there, Bob. I somewhat jokingly inject the phrase "..for you, our customer" when talking with users, but I do mean it and explain that to them as well. There are still approval channels to go through for IT work to get done, but come on! Your example makes me shudder...
Best of luck to ya!
Rich
October 1, 2009 at 11:18 am
Jeff Moden (9/30/2009)
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?
I've had to go back and either 1) document or 2) fix this kind of code and it ain't fun. The worst code is written by engineers who took a programming class in the language and think if they are using legal code constructs they are engineering software. NOT!
October 1, 2009 at 11:20 am
notquitexena (10/1/2009)
Jeff Moden (9/30/2009)
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?I've had to go back and either 1) document or 2) fix this kind of code and it ain't fun. The worst code is written by engineers who took a programming class in the language and think if they are using legal code constructs they are engineering software. NOT!
With much love for engineers, Engineer = hammer, world = nail.
---------------------------------------------------------
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 11:21 am
GSquared (10/1/2009)
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.
I agree with incremental improvements, but they need to be added by people who know what they are doing. Otherwise you get a hodgepodge of coding without any firm plan. And heaven help you if the original framework was not designed to be easily augmented.
October 1, 2009 at 11:47 am
notquitexena (10/1/2009)
GSquared (10/1/2009)
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.
I agree with incremental improvements, but they need to be added by people who know what they are doing. Otherwise you get a hodgepodge of coding without any firm plan. And heaven help you if the original framework was not designed to be easily augmented.
Mostly true.
My own software career started out with an Access database, and it was junk. But it was better than what we had prior (which was post-it notes). Over the years, it kept getting better, and it ended up as something that was pretty darn good. It's been over two years since that software was in use, and I still get e-mails from former co-workers telling me they were spoiled by it.
- 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 11:59 am
From my perspective, I have been burned many times by departmentally developed systems that suddenly become business critical. My opinion is that if IT does not have the time to provide what the business users consider critical systems, then the business does not have enough IT resources.
I have yet to see any system that was developed in a department that didn't become cross department and critical at some time in its life. Anytime that you have databases created by people who do not understand database design and data integrity, you have a database that will have logic errors, performance problems, and just plain BAD data in it.
Add hoc reporting tools are a great idea as long as the access to the database has a way to protect the database from users trying to use LIKE clauses on millon row tables to find the 100 records that they really want. I have had databases completely locked up by badly formed end user reporting tools.
Yes we need to be responsive to the business users needs and wants. I want to make their jobs and lives as easy as I can. To do that, the business needs to staff the IT department so that we can be responsive.
October 1, 2009 at 12:25 pm
Perhaps it is a question of need, urgency, and scope.
Consider that many information needs are high in urgency and narrow in scope.
Should these needs be unmet because IT is unable to have a "qualified" developer write finely tuned code? I think not. If an end user or knowledgeable "key user" can knock out something in Access that meets the need in short order, then why not.
There are literally hundreds of needs like this that pop up every year that IT can't meet for various reasons.
A small number of these needs will grow in scope and number of users, but typically, the urgency also drops in that case. When the scope is broad enough, the number of users high enough, and the urgency at a level that IT can meet than let IT take over.
The focus has got to be on effectiveness. IT is most effective in an environment of static requirements. Users with Access/Excel are probably most effective in an environment of dynamic requirements.
To me the key is understanding the effectiveness issue, keeping communication open, and knowing when an app should realistically be upsized from Access to something else.
Viewing 15 posts - 16 through 30 (of 48 total)
You must be logged in to reply to this topic. Login to reply