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

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

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.

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.

You are also the people before and after you

That's the joke.

I needed that laugh

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>

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

Not to mention self-documenting.

s/workforce/workplace/

Otherwise perfect. :-D

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

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.

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/

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.

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

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.

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

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.