Hacker News Reader

Even if you had presented, there was a big chance that SQL Windows would have been chosen anyway. The risk calculation senior leadership would have considered delivering anything sooner with iterative improvement versus a long ramp up but with more efficiency. While the first may end up being more expensive, it's less risky and more likely to pay off. The longer and more complicated ramp up a project has higher risk, the more likely it will fail before it even delivers.

Leadership is FAR more likely to lean on a sure thing than higher risk/reward. To bypass that you need a proven strong leader and team who delivers big complicated projects and a VERY strong presentation to show the problem was thought out.

Even then, competing priorities and other factors may come into the decision making process.

And I am not saying I agree with the decision making much of the time, but this is what I have experienced.

To be very honest, the only time I managed to get a project like this approved is when I proved with 100% certainty that all the alternatives would fail, why, and how. Even then it took me 1.5 years and significant buy-in from principle engineers to convince senior leadership the it was the only path forward.

It was easier to get free stuff from Microsoft for choosing their products than the C++ standards committee.

https://en.wikipedia.org/wiki/Gupta_Technologies doesn't seem to have anything to do with Microsoft?

You're right. I didn't realize they had a SQLWindows tool that wasn't associated with Microsoft. Microsoft used to be real aggressive with their trademark on Windows.

> SQLWindows was one of the first GUI development tools for Microsoft Windows.

There was no C++ Standard's Committee in 1993.

That's the joke.

A friend asked me offline to elaborate on my scenario, answering publicly.

We had a gap of about 12 capabilities in our environment. The capabilities were in the same family, but functionally different. To make matters more complicated, different teams/leaders only required 1-3 of the capabilities and did not know about or care about the others.

So senior leadership (about 4vp, and a dozen or so directors) saw this as 12 problems that can be solved with 12 solutions.

The problem is solving it as 12 solutions required 12x the engineering to implement, 12x to operate, and 12x user support -- actually I'm simplifying, it was worse in reality. The financial cost was also higher but more like 4x.

To be solved as a single solution required a far longer ramp up time to a functional solution, but would take significantly less engineering resources at every step. To boot, it would also scale far far better - requiring far less people to operate and scale.

So two problems needed to be overcome is convincing leadership that it was not merely a problem of solving their perceived problem of 1-3 capabilities, but 12, and that if we had to support all 12 capabilities we'd need a significantly larger team.

Adding to that was the upfront financial cost for a unified solution was more expensive than solving the perceived 1-3 capabilities any leader knew or cared about.

The solution was shot down 3 times with me being directly told "This is the wrong solution, please have someone else propose a better solution."

And to be very clear, this company actually had good leadership. But with such a large environment they all had their priorities and limited people/budgets to get them addressed with.

The problem was they needed to understand a problem existed outside of their domain, a domain they didn't see as as affecting them very much, so they didn't want to dedicate time to learn it.

The solution was to convince their trusted advisors. Principle and senior engineers, senior program managers, etc.

Politics suck, but they affect any organization with people. The more people you have, the more politics. The more people you affect, the more politics. If your company becomes successful, you will have to ultimately have increased politics. Period.

I’m disposed to liken it to an anytime algorithm (https://en.m.wikipedia.org/wiki/Anytime_algorithm). You want your projects to be as ‘anytime’ as possible, IMHOBOLHE. I think that’s what your comment is driving at: that there’s a significant benefit to a plan that delivers half the benefits if it only runs for half the (eventual, real; not planned) time, vs a plan that requires a long investment of time but only - hopefully - pays off in full right at the end.

Law of Focus

> PowerBuilder, Gupta SQLWindows, and good old C++

Was there any sense in 1993 that C++ would still be alive and kicking in 2022, while most people wouldn't have even heard of the others? Half the lesson is just "choose boring tech."

Good question, because from 30 years later, I think you're right.

But my recollection of the zeitgeist then was all about progress. The trend of the computer industry was always about upgrading, whether that's your hardware, or your OS (this was in the midst of moving from DOS to Windows 3), and there were tons of examples of important languages being left behind, like COBOL or FORTRAN.

And prejudicing the decision against C++ were other related but separate technologies that had led to the failure of the project's original inception. The VP in charge of this major project (it was upgrading the company's core customer tooling from DOS to Windows) had us trying to do all kinds of crazy things. CORBA comes to mind, although I don't recall the details, and trying to make the entire architecture being data-driven.

So there was a sense - not entirely unfounded - that C++ pulled in too much complexity, and we needed to shift gears to something much more straightforward.

But I do recall realizing even as the decision was being made that the kind of simplifying abstractions that these 4GLs gave us may be great so long as what we want to do is "inside the box", but stepping out of the box leads to greater pain than if we'd been trying to accomplish it with conventional tools. Of course everyone realizes this, at least today. The difficulty was an management believing that the entire application, or nearly all, could be built inside that box, and that product owners wouldn't demand special and fancy behaviors.

So I remember spending a good deal of time (and fun!) writing wrappers around Windows message handlers, with their LPARAMs and RPARAMs and the challenge that entails, so that other SQLWindows developers could do these things - whereas the C++/OWL path is designed to deal with such stuff natively.

Speaking of progress... Progress 4GL was the main tool used by the small company I first worked for after university. (https://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Lan...)

It worked in the context of the company being a VAR for solutions that used it to run big business ERP systems and the like, but our manager saw it more as a universal hammer for any job. Fair enough; he had become the manager after being the sole wunderkind programmer for this company, and had no management experience, or really much other prior job experience. I like to think we've all grown beyond our initial roots since.

The amount of hype surrounding C++ in 1993 is really hard to believe these days. You couldn't walk in to a Walden Books or a B. Dalton book store without seeing it in the entry at the mall. The USENET had many different flavors of C++ groups as well. I think at this time even Microsoft was converting a lot of their development towards C++.

C++ was the future at the time, and for some time after. You may recall that there really were not many choices if you wanted to deliver a mass-market or even small-market product to end users. Your realistic options if you wanted to avoid assembly were C or C++.

Pascal was fading. Smalltalk, Lisp, Objective-C weren't viable in 1993 for various reasons outside of very specialized niches. Java didn't exist. (I don't think GNU Ada existed yet? But if it did, you had to use GCC, which kinda sucked back then compared to commercial compilers -- slow and poor codegen.)

We are so spoiled today compared to then. I could automate my house with a system written in bare metal Scheme on a cluster of Raspberry Pis if I had enough time and energy.

There was Object Pascal, supported by Apple and Borland. In 1993 the earliest versions of TP for Windows were available already, and Delphi would come out not long after.

>choose boring tech

This is one of those things that is easy to tell someone but profoundly difficult for certain novel stimulation-driven personality types ( which I would say predominantly is what the HN audience is made out of ) them to internalize without feeling the pain of it yourself a few times.

On hacker news today, choose boring tech is celebrated - unless it’s Java

PHP!

Oh God, SQLWindows. At The Instruction Set (quite well known UK training company), I re-wrote the only UK training course for this (the Gupta course was basically unteachable). It's really a terrible kind of Visual Basic, but with few of the good points, such as VB sort of had. And teaching them to use the tree-structured editor was, shall we say, "interesting".

The second time I presented the course a couple of goons from Gupta sat in and started complaining because I was showing the punters how to use the Windows API to add features that SQLWindows simply did not support. Eventually I had to get my boss in to consign the goons to the smoking lounge.

Ah yes, that outline/tree code editor was one of the worst ideas I ever had.

I'd gotten hooked on some of Dave Winer's stuff - ThinkTank and GrandView - and thought everything should be an outliner.

Be grateful that you and the world were spared at least some of this: at first I thought that even expressions should be done in outline form. We punted on that and left them in text form.

After 2-3 years I left Gupta to work for Cooper Software on Ruby (no relation to the programming language). This was originally going to be a user-programmable shell for Windows 3.0, but Microsoft decided to go a more conventional route with Program Manager and File Manager, and turned Ruby into the "Visual" part of Visual Basic.

So you can blame me for the worst parts of both SQLWindows and Visual Basic!

As much as the management decision to use SQLWindows bugged me, I was rather fond of its outline-based UI.

As it happens, around this time I had also attended a usergroup presentation demoing a beta test of OS/2 Warp. It incorporated a file manager with an outline metaphor.

This inspired me to "invent" an outline-based UI for our own product that, a couple years later, turned out to be exactly what Microsoft did in Windows 95 for their File Explorer, except that I'd also included a type-ahead search at the top of the outline pane to search for nodes matching the input (there were quite a lot of nodes).

Our management rejected my idea, though. Instead, their favored UI metaphor was tabs and pages, which was quite popular at the time. The thing is, such was the complexity of the data we were collecting (lots of outline nodes, as I mentioned) that this metaphor led to major tabs across the top of the window, minor tabs down the right side. Then they originally had a third row of sub-minor tabs across the bottom until someone realized that this broke the metaphor in the physical world - how could the metaphorical notebook be bound? So the sub-minor tabs were switched to be pages within the sub-tabs, using left and right arrow buttons to flip from one page to the next.

I still maintain that the tabbed design was an unwieldy mess, and the outline-based one that I proposed, with the search on top, was vastly more usable.

> So you can blame me for the worst parts of both SQLWindows and Visual Basic!

Something to be proud of :-)

Actually, I didn't dislike SQLWindows _that_ much, because I knew how to write C & C++ code for Windows, so I could program round its little foibles. But it was tough to teach!

I haven't heard "Borland's OWL framework" in over 20 years. Wow, that brought a flood of memories and nostalgia back. I used Borland products starting with Turbo Pascal back in the 1988-1992 time frame before switching to Microsoft C/C++ and MFC. Thanks!

Did you make a video about this on YouTube?

The YouTube app on my TV autoplayed a video last night while I was doing chores around the house. I didn't get to listen to it closely, but I overheard "Gupta SQLWindows" (for the first time ever, mind you) several times and I remember hearing something about INTERCAL.

I don't have access to my YouTube play history at the moment or I'd check it instead of writing this reply.