The Low End

  • People need to remember the original intent of these products. They're supposed to help people automate their own jobs, not the larger business. When kept within these assumptions, they do a great job at proving out new approaches to do a job.

  • A few people have commented on the problems associated with taking over some homegrown Access or Excel application built to solved a local business problem. In general, the problems seem to arise from the lack of training and experience in database and software design principles and processes.

    Here's my take on it. The single biggest problem I face each day is my lack of domain knowledge. I've been consulting with or employed by the same company for about 12 years. Over that time, I've learned a lot (a lot!) about their business, but I'll never be an inventory guru, a production scheduler, or a comptroller. Yet somehow I need to create tools to help this diverse group do their jobs more effectively and more efficiently. Enter Access and Excel. Even reviewing a single-sheet workbook often gives me more insight into the problem than any user-requirements meeting has ever given me. That review serves other purposes, too. It makes us collaborators on a solution, it gives me an opportunity to give them some training, and it shows me where my applications have failed them.

    As a company, we pride ourselves on the product and production innovations developed by the line workers. I try to take the same attitude toward the little (and not so little!) Access databases, Excel 'spread-marts', and other applications built by the very people that use them. As with product or production innovations, appropriate experts need to get involved at some point to properly design and integrate those solutions. In general, I think we need more people doing this kind of thing, not fewer. By accepting it and bringing it into the open, you have the chance to provide skill-appropriate guidance, reduce the duplication of effort, and identify prime candidates for more formal efforts.

  • It is funny - I got out of school 15 yrs ago trained in C/C++ and I have only written 2 programs using those languages. Businesses like the RAD life cycle and time frame and I was forced to learn Access / VB to support that desire.

    Besides there is good money to be made consulting to support the applications that users created.

  • Often times it's good to just let the end users "prototype" their own applications in MS Access or Excel. The trial and error process is practically part of the discovery phase. When they finally call you in to build the real application, they already have an evolved idea of what they need.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Ron Porter (12/14/2010)


    By accepting it and bringing it into the open, you have the chance to provide skill-appropriate guidance, reduce the duplication of effort, and identify prime candidates for more formal efforts.

    This is what I was trying to get across with the editorial.

  • This discussion topic always interests me. We have the "I'm a real developer and know way more so I don't use Access/Excel. I have superior knowledge." We have the "Look - I get done what needs to get done and I do it quickly and my stuff is just as good." We see the "Only IT has the ability to develop real tools." We have the "I use Access/Excel all the time and I get my work done more quickly." And of course the "Yeah its all well and good until you have to come crying to us to fix your 'tool' so it works."

    Hmmm................

    So who is right? We all have individual experiences and we judge (hopefully) on that basis. I do most of my work, including analysis, in SQL (2008 R2 at the moment). I have used, and occasionally still use, Access. I often provide the requestors with Excel spreadsheets as the final product. They like it. They can understand it. They're comfortable with it. I manage the data in our databases and write many of the tools the company uses. I do not work in IT.

    My point? While I love to read other opinions and views, at the end of the day I do things in the manner that makes the most sense to me, works within the company's systems and provides the actionable information they need to make good choices. I'm guessing most of you do the same. I can't tell you what tools you need, and I would like to think that you feel the same.

  • Steve, your questions were: Are "easy-to-use" products like Access or Excel good for business? Should they be used to build applications?

    My answers to both are absolutely. You are right that it depends - I used to do enterprise work where we needed the robust data management of Oracle and SQL server. Now I work in small business and find that Access and Excel are much simpler for maintaining and reporting data. When properly developed they provide robust data and CRM management. Most importantly, they are easier for non-technical users (who are experts at their jobs) to understand and be productive with quickly. SQL stores large tables better, but these are easily read through links to Access.

    My job is helping users get productive quickly and reliably - why hand them an anvil when a fly swatter will do? Having said that, I've come across several Access dbs designed by programmers that were overkill. When the designer moved on the dbs were so complex the remaining people couldn't add functionality or in some cases even maintain them. Good designers can work at differing scales and factor in the client's ability to maintain the product or application as a part of the DB design.

  • Ray Hastie (12/14/2010)


    It is funny - I got out of school 15 yrs ago trained in C/C++ and I have only written 2 programs using those languages. Businesses like the RAD life cycle and time frame and I was forced to learn Access / VB to support that desire.

    Besides there is good money to be made consulting to support the applications that users created.

    :w00t::hehe::-P

    I am so right there with you! Trained in C/C+, the next year I was expected to know Java. All the contract jobs to support my college habit were in Access/VB. My first hired job? I was on an AIX/Unix platform and scripting in Awk.

    This is a big "it depends" topic. If it's useful and meets the need, use it. If it grows to big, then it becomes a prototype for taking it to the next level. Being prejudice about a language, application (or anything else!) just closes down your opportunities.

  • User prototyping is one possible use of low end tools such as MS Access and others (actually there are hosts of better prototyping design tools for professionals). However, I find that by far the biggest advantage to allowing savvy user's free reign with Access is in providing them updateable subsets of larger SQL Server databases, and giving them the ability to do all the ad-hoc querying and report building they could desire. Then if a user actually creates something useful for the enterprise, it is an easy task to migrate their solution to network rather than allowing others to share their Access databases.

    We all know that allowing massive ad-hoc queries against production enterprise databases is the quickest way to bring a server to its knees. Using tools like Access and/or non-production servers for this ability, is the only way keep the data flowing.

    Ron K.

    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler

  • I woudn't call MS Access or Excel a "low end development tool". Primarily they are general purpose tools for data analysis and reporting, and they are actually state of the art for their class. Both Access and Excel can store datasets, and they both have a scripting engine and programmable application object model, so someone who is MS Office savvy can sit down and start using it to code a front end and data store for a complete solution. It's a natural progression for anyone who uses MS Office on a daily basis.

    Where I work, we frequently pull small or medium sized datasets from SQL Server or Oracle into Excel and use it's built in features like Pivot Tables and analytic functions to analyze the data. We can markup specific rows, add comments, and then email or archive the document for reference. You would have a really hard time trying to convince the accounting department of any corporation to give up Excel in favor of some home grown or 3rd party web based application.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I too find it rather odd calling these tools "low end". I think they are quite the opposite: High end tools that don't require you to know how to deal with bits and bytes or complex join syntax, and have the ability to produce reasonable applications in a short time. As many people have said, it's not the tool, it's the discipline. I know of many successful companies that started their product as a VB app written by a single "untrained" person (that is, somebody who picked up programming as a hobby, and doesn't have a computer science degree, or any IT training).

    At least, I felt this way until last week when I started playing with PowerPivot and DAX. But that should be a whole different conversation, I'm sure.

  • The "low end" refers to the barrier to entry. It's easy(ier) to pick up development skills on these products, as opposed to C/C++

  • I think it's a lot easier to pick up development or (especially) admin skills on SQL Server when compared to Oracle.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Take a look in a small manufacturing company like the one I work for, we had an IT department of 7 including 4 IBM AS400 programmers when I joined IT in 1999. Now we have to use the corporate SAP system and have an IT department of one. SAP is so cumbersome and hard to get data out of, our company lives and breathes on Access and Excel systems. I am developing a Product Management application using SQL Server as the backend but for the front end I may be forced to use Access 2003. I would like to use a web front end, but we only have Visual Studio .Net, and for an occasional part-time programmer like me it is far too complex to be bothered with. Every time my computer gets a MS update it stops ASP.net from working. Microsoft has take VB out of the hands of those who need a quick and simple solution - all we have is Access and Excel, although they still only get to my SQL data through stored procedures.

  • I think Access and Excel are invaluable in business. I have had similar experiences to roger.plowman with Access. I developed a manufacturing database in Access with about 20 concurrent users. The front end was on each workstation and updated itself from the network whenever I placed an updated copy there. The data database was on the network and this ran beautifully, so much so that recently, the manager of that group told me that he wished he could still use it. About 2 years after the system was first used, a new .NET and SQL Server solution was developed and they had to move to that. My company uses Excel extensively for analysis with the data now coming mostly from SQL Server via .NET applications. Most of the applications I now develop are in .NET but I still need to maintain and develop Access databases sometimes.

    I have also been a consultant and have had many jobs sorting out Access databases that untrained/non-IT people have developed. I actually enjoyed this work as it often gave you ideas on how to tackle different issues, as these people would often approach their business problem quite differently to the way an IT person would. For a start there was no particular focus on technology, "Let's use the latest/cutting edge tool/language", but just what will do the job. It is also much easier to design and develop a system when the end users have a clue about what they want!

    It all provides a varied work life and keeps me from getting bored!

    Cheers,

    Nicole Bowman

    Nothing is forever.

Viewing 15 posts - 16 through 30 (of 34 total)

You must be logged in to reply to this topic. Login to reply