Thank you for the experience.

Then when I arrive, I make everything logical, nice, structured and proper.

After I leave, once again the place falls prey to disorganized minds who take my work and mess it up for flashy new technologies that are not as reliable as what I had done.

For some reason, this keeps happening.

edit: corrected word thanks to @brlewis

The same dev(s) that allowed the place to run with all the long hours and the most check-ins, are the cause of all the woes when the next dev(s) take over (usually to justify a version 2).

The second easiest scapegoat: third parties, component builders and providers.

All of these can be attributed to Not invented here (NIH) syndrome. [1]

Devs always know more about a system they themselves worked on, and noone wants to be liable for a system that they didn't build that can have hidden gotchas simply because it was NIH.

At every iteration in every single system, even outside of software (you can see this in generations and politics), each iteration teaches lessons and uncovers unknown problems or creates them. Many times this is no fault of the creators but the simple iteration attempt progressed knowledge enough to be able to learn about a new problem that could not be found without said iteration/advancement. In this sense iterations and different teams aren't bad, but they will always blame the former because it uncovered new problems, which is ultimately a gift to solutions and progression.

New problems create new solutions which are what we call progression and innovation, and the next in line should be happy those problems were found that they can solve, for they themselves will eventually be providing this service to those after them.

[1] https://en.wikipedia.org/wiki/Not_invented_here

However I've seen it for real too: a former boss calling me about a problem with a Sybase Adaptive Server Anywhere problem. So I tell him I've forgotten it all but it is all documented in the wiki I set up with the guy who supported the system after me so, just search for Sybase.

Well... Turns out that documentation is gone.

And as you wind your way through the lack of documentation or sanity in how things were done, you inevitably find some sign that the person who created it was...you. <facepalm>

Not to mention self-documenting.

Otherwise perfect. :-D

1. The applications I created were undocumented. They weren't.

2. The applications I wrote were used for managing documents. They weren't (with one exception, which was for publishing process manuals on the intranet, to save trees and improved searchability. That app had no functionality except for the Lotus Notes built-in storage/retrieval/search, and each record had 3 fields: title, reference, content).

I just wanted to explain what happens to all the effort-saving nice little apps that people wrote to solve a real problem in the workplace... and I wasn't picking up on you specifically, I am sure you did your best and that using the tool at the time made perfect sense.

It's just that the real problem (IMHO) has never been "wow with Lotus Notes or whatever I am really productive even if I am not a full fledged developer" - the real problem is who takes responsability for it and how much of a struggle it will be to move the functionality back to a properly intgrated application.

(So apologies, it was just a rethorical trick on my part).

I also worked in a Lotus Notes shop for several years. We built apps on Notes/Domino and did some pretty cool stuff pre-dot-com, including a Project Management system like Basecamp[1] that was a hosted SAAS (using Domino's web server) in 1998 (crazy to think that was 20 years ago), when SAAS was just a buzzword.

IIRC, more than half of our company's Notes development staff were comp sci grads. It wasn't just a bunch of random dudes throwing a bunch of forms together using the built-in formula language.

[1] https://books.google.ca/books?id=jlIEAAAAMBAJ&pg=PA52&lpg=PA...

I'd like people that create "quick prototypes" and "just a throwaway excel with a few macros" realized that while they are valuably shortening the time to get something usable they are also shortening the time before their thing turns in a sort of albatross tied to the neck of the users.

My estimate is that for every 20 “throwaway Excel,” only one becomes used heavily and required a painful redesign.

Trying to build all these correct from the start is actually inefficient because 1) you don’t know which 20 is right until quite a while in; 2) the idea that better requirements gathering and design is a myth as functionality and use is frequently, in my experience, new based on the spreadsheet and users don’t tell this to the design team; 3) the cost of properly designing all 20 is enormous so trying to pick only the most likely 5 is still expensive and has a decent probability of producing zero useful systems.

So while it sucks to be the engineer cleaning up some yahoo’s hack that got used by the CEO, I’m not sure what the solution is that is best for the enterprise.

It's like convincing lawyers that they're not needed in situation X. Doesn't work.

But I think there are lots of little scripts and one-offs I write that are suitable for me, but would make so sense as a large designed system. Every once in a while they’ll get promoted or reused.

The solution to this problem isn’t premature optimization to write all my code with max generalization using on the enterprise approved development platform. But to just accept in life there are positive inefficiencies.

There’s also a decentralization argument here somewhere.

The point I wanted to raise is that excel, DBIII+/Clipper, VB, Access and other "low code" solutions are fine as long they help a single individual (or, at best, a small team like 2-3 people max) to be more efficient.

The moment that they need to scale, they become a liability, like... having to add .csv import to your application because the users do all their planning/what-if scenarios on some excel sheet prepared by someone who already have left the company and then they prefer to upload the results (bypassing any of your carefully designed server-side business logic) instead of retyping each value manually.

Yeah, but this is true of just about any home-grown solution, whether they are "low code" or not. There are surely a lot of VB and PHP ("high code"?) applications that were quickly thrown together to solve what was at the beginning a small problem.

The reason they're not best practices is usually because there's no IT support or money to build it, so someone (often self-learned) finds a way to build it themselves. You can complain about having to rewrite it once it became a mission-critical app, but more often than not, that app would have never been written by a seasoned developer because the original user(s) of the tool couldn't justify the resources to build it at the time.

Damn easy to create new forms, actually not that bad to implement import if the forms aren't brain damaged, it probably beats whatever you make in terms of UX for data entry not to mention ability to massage data locally.

The problem is, IMO, the lack of middle ground. A lot of those solutions are old, and integration of more modern functionality is lagging - it's there, but it's not well integrated because the concept of multi-user system with access controls wasn't a concern when the system was originally made!

Specifically, I would really be happy if people that launch themselves into this kind of little projects could (maybe with help from IT) decide "ok, we have reached a point of complexity where this stuff has really to be integrated back in the main system".

(And budget appropriately for this to happen).

(so "budget appropriately" means developer years for simple apps with equivalent functionality to basic excel sheets. It is not reasonable to expect this to happen)

In 2009 or so everybody decided that webapps don't even need a data table component at all, and I have yet to find such a component that has the features of Delphi 1.0's datagrid (sorting by row, dynamic rows, built in search, accessible, ...)

GWT is the only thing that even came close, even made an attempt (and tolerable means, the third iteration - cell tables). It's the only thing that I ever found tolerable for developing business web apps.

This means that anything built after that point that has a web UI has subpar data presentation to a windows 3.1 app. And it shows. Handling nontrivial amounts of data in a webapp ... well compare Google Sheets with Excel, and it's obvious even there. Sadly Google Sheets probably has hundreds of developer-years in it at least, maybe thousands, and that's what it requires to get a webapp to that point.

A couple of things in particular were really good - reliable replication (which meant your workers could work offline and sync back later) and the document based store.

Fast forward 20 years from Domino 3, and you'll notice that the document based store model is still around in the form of CouchDB (spiritual successor to Domino?) and other products like MongoDB.

A mess can be made in any language, by every developer, if we're improving every day, looking back, our work looking back 5 years will always look and often feel like garbage.

But just like excel, it's a double edged sword, as people "specialize" in it and create monstrous abomination applications way larger than the tool is fit to sustain. It becomes a rat maze of gotchas and obscure tricks, and nobody but the original creator really knows what's going on.

That’s true of most “serious” codebases too! Writing code that others can understand takes time and expertise (both expensive), and it’s often not worth it for one-off tools.

Paid for their Porsche 911 until the .com bust broke contracting generally.

Absolutely. BUT, in the early days, the value of return for end users is higher than the cost of development and maintenance. If the tool is useful and grows, it's going to flip where the cost of development and maintenance is higher the the return, and some tough decisions need to be made.

perl devs used to refer to this as job security :)

The Exchange people pointed me to the SharePoint people who explained this is an entirely different license and then showed me how to do my survey. It took more development time and somehow had an even worse UI than Lotus.

So there is stuff worse than Lotus, and I think that enterprises do need some simple way for non-devs to make modules or apps or whatnot that they can integrate into workflows. Basically like Access was in the early days where normies would make databases for paper stuff.

The idea that a non-dev should hire people for simple data collection and analysis, while nice philosophically to me as a dev, is pretty crazy in the long run as it doesn’t scale.

It’s effectively a whole different platform than exchange and so it’s basically easier to use survey monkey or google forms.

But hopefully this gets better with office365.

For a demonstration of HyperCard's power, play the original Myst some time. The original Myst runs on HyperCard (the Mac versions anyway; it obviously had to be ported for Windows and other releases). Incredible.

I struggle to think of tools like these that exist today. Access, perhaps? (and of course the tool in the article)

Sure, I can build CRUDish apps with Django, but there are simple use-cases that take me a week with Django, that would have been a day with Notes. It's crazy that things are slower for me 20 years later. I'm pretty sure I'm not dumber now.

http://www.filemaker.com/products/filemaker-pro/

"FileMaker Pro is no longer available. It has been replaced by FileMaker Pro Advanced which includes more features to help you develop and deploy custom apps faster and more efficiently."

1 - Document Store (iirc, CouchDB was inspired by Notes/Domino)

2 - Replication - even past the 90s, it was one of the best tools for disconnected users

3 - Low barrier to application creation (it was about as easy as building something in Filemaker Pro)

4 - Easy publication of applications to the web (this was BEFORE 2000, so kind of a big deal back then)

5 - Administration of servers was pretty easy

6 - LotusScript (similar to vba) let you go much further than the prebuilt formula language (if you were willing to learn it)

Keep in mind, these benefits were available pre-2000, and in that time many were strong competitive advantages.

Hell, I don't even think all laptops had ethernet ports back then either. In a lot of cases, you had to buy PCMCIA cards for that.