4 ms·

Access is highly underrated. I was able to build a CRUD app with 20 concurrent users in a month just using a shared directory to host the backend database. It

Access is highly underrated. I was able to build a CRUD app with 20 concurrent users in a month just using a shared directory to host the backend database. It would have taken a team of engineers 6 months to do the same properly developing a Java web app with Oracle database. Access does have such easy WYSIWYG reporting tools that I still miss.

specialist 7y ago
I was never more productive than using Access. Once wrote a full budgeting, cost estimating tool. Supposedly impossible. (Access' VBA had an 'eval' function.) We lost something in the switch from "workgroup" (dBase thru Paradox) to client/server. Spoiler: ODBC broke the tight coupling of code and persistence. Spawning monstrous hacks like ORMs and ActiveRecord. What Ted Neward famously called The Vietnam of Computer Science. It took me a very long time to figure out what went wrong. Even longer to fix it. Cliff hanger, I know. Someday I'll post polish and publish that fix. Using my real name.
- blihp 7y ago
  The thing that was lost quite frankly was most of the value that desktop productivity software used to provide before Microsoft consumed the market with Windows. It's not that client/server couldn't provide the same (or even better) value, it's that the companies left standing (think Microsoft, Oracle, IBM etc.) had no interest in providing maximum value to customers. They wanted to extract maximum value from customers. Access was created to compete with and replace those single-user and workgroup dBase-era software solutions from the 80's and early 90's. It helped them to cover the bases of the 'professional' desktop use cases as they won people over with Windows. With that mission complete and all competitors long gone, Microsoft now needs to kill off Access to get more people migrated over to SQL Server solutions which will allow them to extract more value from their customer base.
  - TeMPOraL 7y ago
    It's interesting to see that, given that in modern times, Microsoft is the only tech giant that can still build user-empowering software. Not Windows, that's getting dumbed down UX-side. But Office suite still includes Access and Excel, the latter being probably the single highest productivity booster in modern companies (to the chagrin of IT departments). And you're essentially saying that this is already another order of magnitude worse than what came before Microsoft. Now I wish I was able to see that older software in action.
    - blihp 7y ago
      If you look at how things have progressed from the GUI desktop->web->mobile you get a reasonably good flavor of the trade-offs that have been, and continue to be, made. Compare the richest, most powerful spreadsheet application you can find on the desktop to the same on the web to the same on mobile... there you go ;-) (and it isn't just the relative maturity of the platforms: once one player dominates a platform, things start to stagnate) If history is any guide, the mobile spreadsheet will never do some (probably much) of what the desktop version did[1] and the desktop version will never get some of the new capabilities of the mobile version[2]... yet over time the less capable, but 'better', mobile app will become the new normal for many. The good news is the mobile version will still be more powerful than whatever platform comes next. I'm greatly over-simplifying and glossing over some things (esp. re: the dynamics of the text UI and early GUI eras) but I think the basic idea still holds. [1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft... [2] The profit motive is no longer strong enough to warrant the needed investment in structural changes to the desktop application
      - TeMPOraL 7y ago
        > [1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft... I don't like that "good enough" argument, because it misses the fact that features shape use patterns. Features are enablers. To give a random example: I once visited my wife's office, and was given a task I could help them with while waiting. It was a task they did very frequently, and it boiled down to specifying a search query, and then adjusting some data in each of the result. They thought it'll keep me occupied for an hour or two, manually adjusting each of the hundreds of results, but I looked around the software and found a way to do a bulk update hidden somewhere in the UI, and was done in 3 minutes. I taught the people in that office the trick and they were grateful, but it made me wonder - what if one day the software vendor removes bulk update switch because it's rarely used? It's only rarely used because it's not easily discoverable (but the telemetry will not tell you that). Wondering even further - how much money and opportunity to growth do companies lose on office tasks that are inefficient only because software was developed for the lowest common denominator, and offers no advanced features and no path to mastery?
  - specialist 7y ago
    I don't have a thesis about the business (software publishing) aspects. Well, I do, but it's a tangent: Microsoft's failure to provide the much promised ramp from Access JET to SQL Server (which I also love) alienated me as a dev. Here I'm only commenting on the impedance mismatch between code (biz logic) and persistence (eg RDBMS) introduced with ODBC. (Specifically, type information in the db schema is lost to the client code.) Okay, writing this out now, Microsoft (and everyone else), probably didn't appreciate what was lost with ODBC, so didn't consider how to continue the Access style of CRUD to client/server. So we ended up with nonsense like LINQ.
pjmlp 7y ago
You can do the same in Java. Netbeans with Swing UI designer and database bean components.
- mobjack 7y ago
  That would mean using a server for the database, which means lots of meetings getting buy in only for it to be prioritized to get done 9 months later. You also have to deal with DBAs who like to say no and permissions every time you have to make a change. Even if you broke down all the bureaucratic barriers, Access is still quicker to make a simple to make a simple CRUD UI than Java swing. Sometimes worse is better. Not saying I would use Access today but that is because I became a software engineer who has more authority to use the proper tools. When I started out as an data analyst, Access was the only thing available I had to get the job done and it did it well.
  - pjmlp 7y ago
    The database could run local. I have experience with both and the NetBeans UI designer is hardly much different. Now if we compare languages, Basic dialects win hands down for such scenarios.

specialist 7y ago

I was never more productive than using Access. Once wrote a full budgeting, cost estimating tool. Supposedly impossible. (Access' VBA had an 'eval' function.) We lost something in the switch from "workgroup" (dBase thru Paradox) to client/server. Spoiler: ODBC broke the tight coupling of code and persistence. Spawning monstrous hacks like ORMs and ActiveRecord. What Ted Neward famously called The Vietnam of Computer Science. It took me a very long time to figure out what went wrong. Even longer to fix it. Cliff hanger, I know. Someday I'll post polish and publish that fix. Using my real name.

blihp 7y ago
The thing that was lost quite frankly was most of the value that desktop productivity software used to provide before Microsoft consumed the market with Windows. It's not that client/server couldn't provide the same (or even better) value, it's that the companies left standing (think Microsoft, Oracle, IBM etc.) had no interest in providing maximum value to customers. They wanted to extract maximum value from customers. Access was created to compete with and replace those single-user and workgroup dBase-era software solutions from the 80's and early 90's. It helped them to cover the bases of the 'professional' desktop use cases as they won people over with Windows. With that mission complete and all competitors long gone, Microsoft now needs to kill off Access to get more people migrated over to SQL Server solutions which will allow them to extract more value from their customer base.
- TeMPOraL 7y ago
  It's interesting to see that, given that in modern times, Microsoft is the only tech giant that can still build user-empowering software. Not Windows, that's getting dumbed down UX-side. But Office suite still includes Access and Excel, the latter being probably the single highest productivity booster in modern companies (to the chagrin of IT departments). And you're essentially saying that this is already another order of magnitude worse than what came before Microsoft. Now I wish I was able to see that older software in action.
  - blihp 7y ago
    If you look at how things have progressed from the GUI desktop->web->mobile you get a reasonably good flavor of the trade-offs that have been, and continue to be, made. Compare the richest, most powerful spreadsheet application you can find on the desktop to the same on the web to the same on mobile... there you go ;-) (and it isn't just the relative maturity of the platforms: once one player dominates a platform, things start to stagnate) If history is any guide, the mobile spreadsheet will never do some (probably much) of what the desktop version did[1] and the desktop version will never get some of the new capabilities of the mobile version[2]... yet over time the less capable, but 'better', mobile app will become the new normal for many. The good news is the mobile version will still be more powerful than whatever platform comes next. I'm greatly over-simplifying and glossing over some things (esp. re: the dynamics of the text UI and early GUI eras) but I think the basic idea still holds. [1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft... [2] The profit motive is no longer strong enough to warrant the needed investment in structural changes to the desktop application
    - TeMPOraL 7y ago
      > [1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft... I don't like that "good enough" argument, because it misses the fact that features shape use patterns. Features are enablers. To give a random example: I once visited my wife's office, and was given a task I could help them with while waiting. It was a task they did very frequently, and it boiled down to specifying a search query, and then adjusting some data in each of the result. They thought it'll keep me occupied for an hour or two, manually adjusting each of the hundreds of results, but I looked around the software and found a way to do a bulk update hidden somewhere in the UI, and was done in 3 minutes. I taught the people in that office the trick and they were grateful, but it made me wonder - what if one day the software vendor removes bulk update switch because it's rarely used? It's only rarely used because it's not easily discoverable (but the telemetry will not tell you that). Wondering even further - how much money and opportunity to growth do companies lose on office tasks that are inefficient only because software was developed for the lowest common denominator, and offers no advanced features and no path to mastery?
- specialist 7y ago
  I don't have a thesis about the business (software publishing) aspects. Well, I do, but it's a tangent: Microsoft's failure to provide the much promised ramp from Access JET to SQL Server (which I also love) alienated me as a dev. Here I'm only commenting on the impedance mismatch between code (biz logic) and persistence (eg RDBMS) introduced with ODBC. (Specifically, type information in the db schema is lost to the client code.) Okay, writing this out now, Microsoft (and everyone else), probably didn't appreciate what was lost with ODBC, so didn't consider how to continue the Access style of CRUD to client/server. So we ended up with nonsense like LINQ.

pjmlp 7y ago

You can do the same in Java. Netbeans with Swing UI designer and database bean components.

mobjack 7y ago
That would mean using a server for the database, which means lots of meetings getting buy in only for it to be prioritized to get done 9 months later. You also have to deal with DBAs who like to say no and permissions every time you have to make a change. Even if you broke down all the bureaucratic barriers, Access is still quicker to make a simple to make a simple CRUD UI than Java swing. Sometimes worse is better. Not saying I would use Access today but that is because I became a software engineer who has more authority to use the proper tools. When I started out as an data analyst, Access was the only thing available I had to get the job done and it did it well.
- pjmlp 7y ago
  The database could run local. I have experience with both and the NetBeans UI designer is hardly much different. Now if we compare languages, Basic dialects win hands down for such scenarios.