Hacker News Reader

Comment by rahimnathwani | Hacker News Reader

During my first job after university, I spent a bunch of time developing apps using Lotus Notes. Because all of the company's 2000+ employees already used Lotus Notes for email and calendering, deploying these apps was easy.

And in many cases I was able to develop the basic functionality of a workflow app whilst I was talking with the main user to gather requirements. And, although the platform supported a proper programming language (LotusScript, with almost the same syntax as VB), I was often able to build what I needed with just the GUI tools and a few formulae (roughly equivalent to formulae in Excel).

There are a lot of Lotus Notes haters. I think the majority were put off by the email experience, which is very different from other systems.

But the ease of developing, deploying, updating and using internal-only workflow applications was truly awesome.

I hope App Maker is as easy to set up, for simple use cases at least.

View on HN

Hi, I am the guy that came in a few years later and had to reimplement a bunch of custom (undocumented) Lotus Notes applications in order to move actual documents to a proper document management system (with access profiles and searchability) integrating the apps in an intranet portal, allow them to talk with other applications and finally put everything under SSO.

Thank you for the experience.

Speed vs reliability is a common tradeoff in the workplace. Everyone hates the apps or tools that were built before you start working.

In my experience speed vs. reliability soon transmogrifies in inertia vs. rational (and usually inertia wins).

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.

I find this better than the people who try to build 3-tier sql dB driven apps for all those scenarios.

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.

What lots of people fail to understand is this: little work-saving apps seems to work magically (for the users) because a lot of the logic, especially how to handle thorny edge cases which nobody considered before, is left in the brain of the user himself. If I designed an app where a particular use case would be handled by "write down the caller's number on a post-it note and then ask George from accounting over a coffee cup at the cafeteria" I would face the firing squad. But ironically enough this is how the "little spreadsheet my cousin helped me with over the weekend" handles this case, and all other unanticipated cases, and this is great because it's not a 3-tier sql dB driven app. (An app that handles everything else, though, and has to meet also regulatory requirements including SOX).

This is a board with 90% or so software developers. Your point, of course, is accurate. It's going to get torn down anyway.

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

I’m a software developer. I build big things, and I wrestle through rewrites of spaghetti Code. I once had to convert a start up from a cold fusion web site the ceo and biz dev (both non developers) had written. I get it.

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.

Agree, understanding this point is a significant milestone on the way to becoming a good engineer.

Hmm all of the features you describe can be done with Notes/Domino. Granted, it's not pretty, but it's there.

I'll gladly take your word for this. My company was contracted to do the stuff I described, but the decision came from the customer's IT staff. Maybe it was political to milk more budget for the project.

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.

Yet Excel is probably one of the best "UIs" you could support for data entry in the workplace.

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!

Agreed on the middle ground.

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).

A problem is that before you have a webapp at the level of Excel without any customization, we're talking developer years of effort. Webapp frameworks are for trivial frontends, they make the equivalent of slide handouts.

(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.

>> The moment that they need to scale, they become a liability, like...

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.

Yeah, Notes/Domino got a bad rap for a lot of stuff, like the cruddy 90s UI that never got updated, but it was quite powerful for what it was.

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.

Exactly. Domino was NoSQL before it was cool...

I'm one of the team that was hired to take the Excel app that one overdue-to-retire person had spent 20+ years developing (without documentation, and inserting every miscellaneous feature he felt was desirable, regardless of actual need, and which, of course, he wanted all of to be kept) for the entire company's metrics and reporting, and turn it into something that could actually be understood by anyone else, with proper database normalization, API access, etc.

Yes, we stand on the shoulders of giants :)

Giant ~something~, certainly

Obligatory xkcd: https://xkcd.com/1667/

I understand the sentiment, but you are assuming:

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).

You are wrong: the project I described is real but was most assuredly not for the company you worked with (for a start, it was for a big Utilities company... in Italy).

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).

This is a real misconception a lot of programmers have about Lotus Notes shops.

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 have also found that when I enter a new workplace, everything done before me was a mess of unwieldy, poorly documented and unstructured code. Worse it uses an old, archaic platform that is long overdue for a complete overhaul.

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

You are also the people before and after you

That's the joke.

I needed that laugh

s/workforce/workplace/

Otherwise perfect. :-D

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

Not to mention self-documenting.

I, too, would like to pat myself on the back for having excellent code management skills, and problem solving. But most of all, for going completely meta on people.

This is a nice joke.

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.

The easiest scapegoat in software history: the previous developer(s).

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

The best is when you work on something, then shift to another part of the business, come back, and uncover some crazy construction that has you scratching your head and what the hell the person who made it was on at the time.

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>

It seems a little presumptuous to assume every app in any language is not built well.

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.

I wonder what people did with your big integrated and centralized ivory tower after you left.

Tools like that can be extremely productive, and easy for people of no or low programming ability to utilize.

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.

> nobody but the original creator really knows what's going on.

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

> 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.

A friend of mine spent a very lucrative few years in the late 90s, early 00s doing Excel contracting. Usually for banks who seemed to have quite a lot of these monstrous abominations and a wish to make them far more monstrous going by conversations back then.

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

>> Tools like that can be extremely productive, and easy for people of no or low programming ability to utilize.

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.

I worked for a huge consulting firm that had built a lot of workflows around Lotus. I hated it at the time, but then I moved to an org using Exchange. I asked how to do something simple like send a five question survey by email, allowing editing, and combining results into a dB and was surprised Exchange didn’t have an equivalent.

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.

If you don't care about confidentiality, then you can do a simple survey using a SharePoint 'List'. It's as easy to set up as a Notes database. But less flexible.

That’s what my IT people said. SharePoint is harder to use, integrates poorly into outlook, lists are a terrible data source, SharePoint permissions are buggy, and the pricing model is all different than outlook.

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.

Very similarly was HyperCard. It was a bit before my time, but reading up on it, it seemed so powerful and yet friendly for non-programmers to use to make useful tools.

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)

I always got the impression that Lotus Notes was a great idea, but very poorly implemented. The concepts in it were good, it was just a shame it inflicted so much suffering.

What aspects of Lotus Notes seemed like a good idea? Genuine question. I remember being horrified by almost everything about Lotus Notes. Sametime was great, though.

I'll bite...

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.

Replication was huge, we didn't even have an internet connection when I setup a application replicating between three suppliers and a bank.

Yeah, when I first started to use Notes, using modems over POTS lines to call HQ was still a thing, so that replication was a big deal.

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.

I realized how great Sametime was after I was forced to move to Skype for Business. The meeting functionality wasn't great but there were other great features. I sorely miss the button that allowed you to drag a rectangle on your screen and it would automatically send the resulting screen capture as a message. Not as an attachment that you had to open up, an actual image in the chat. Why can't skype figure that out!?

I still wish for a widely-deployed replacement for Notes/Domino.

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.

Does Filemaker Pro solve that problem?

I have never used it, but it's no longer available as of last month:

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."

IIRC, File Maker Pro Advanced is basically FileMaker Pro with additional features enabled. You would be able to use that in its place, but it might have a higher price tag.

Reply on news.ycombinator.com