211–220 of 331 posts
Definitely not future-proof as new business rules may be hard to add after a while, but by then the PoC has shown its value and ROI, and writing a real app might become a no-brainer anyway.
Earlier quoted context omitted.
> you have to use react, redux, install 10+ npm modules, etc... just to make a POST request back to your internal API!). Or just use HTML, CSS, and JavaScript?
I see this line of thought floated a lot. Go build a fully dynamic app used by internal teams with just those three tools and tell me how it goes after you've been maintaining and building on it for a while. Those are good building blocks but they're simply not sufficient if you are building a 'Web App' and not a 'Website'. Also I'll cut off the inevitable, "The web was not built for this and it shouldn't become a pl…
We're talking about internal tooling for businesses here, this isn't necessary at all.
I disagree with the person you're responding to, PHP and HTML should be more than enough for such things.
Earlier quoted context omitted.
I think you are radically underestimating the perceived barriers to entry with programming. You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. This type of insider view is often referred to as 'the curse of knowledge'.
I think you're right about perceived barriers to entry, and I certainly didn't say (nor did I mean to imply) that anyone should "just" learn to code. But I think the promise of "apps without code" is a siren song, always ending in frustration. I'd never tell anyone that learning to code is easy (only that most people can do it with some hard work), but I would also never tell anyone that tools like this will make it…
That's what this tool looks like will accomplish. A new class of apps will be built - that have never been built before. The so called app market will expand.
This doesn't replace the current apps, or the current set of engineers developing these apps. This grows the overall market to be 10x larger than what it is now.
Earlier quoted context omitted.
Writing a first iteration fast with no code is a smart move. You can later on create a second iteration with more traditional languages and tooling like Python.
I tend to disagree here. The thing that makes writing business software take a long time (using code, to be pedantic), isn't the fact that it's in code -- it's the fact that the requirements are often so fast and complex that there's no way to capture them in the application without taking a good chunk of time. If you want an application that doesn't actually meet your requirements, but at the very least, exists, get…
As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me.
But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.
Earlier quoted context omitted.
Can someone smarter than me explain why the AWS UI is so off-putting? I also find myself just put off by AWS UIs. I can't even figure out why I hate it so much. Looking at the screenshots though immediately filled me with the sense that this thing would just be awful to use. When I go back to the screenshots to try to find objective things I dislike about the UI, I can't really find anything. It seems to do the stuff…
I seem to be the only person who likes the AWS UI. So here's my defense of it. AWS is like the hardware store. Who thinks Home Depot is elegant? It's not. Who think their organization scheme is a thing of beauty? It's clunky and just functional. But the idea is, when you go to Home Depot, you're there to get work done. The interior communicates that. The real work comes after you leave - Home Depot understands it's j…
> the most bare bones UI
The AWS UI is one of the most cluttered, complex, complete-opposite of "bare bones" of almost any web app I can think of, except for maybe Salesforce.
>basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results.
My largest gripe with AWS is that it does not have a clean mapping of fields/pages/results. The flow of getting to "results" in one AWS service is completely different from the flow of getting to "results" in another. The launch wizard for ECS, for example, doesn't even follow the same paradigm that the launch wizard for EC2 follows. One of them has a clear vertical layout with successive config pages, while the other has a mixed vertical/horizontal layout with sub-pages.
When doing something as basic as launching an EC2 instance, the AMI selection page has "Select" buttons next to each AMI on the right side of the page, and clicking one takes you directly to the next page. And then on that very next page, the instance type selection, the format has changed. Now the way you select something is by clicking a radio button (which is on the complete opposite left side of the page!) and then clicking "Next" at the bottom of the page. Why do these two pages require completely different models of interaction when they are essentially accomplishing the same thing?
Even within the VPC service for example, some pages have clusters of information that are right-aligned on the page, while others put the same information at the bottom of the page. Some pages have the "Create new resource" button on the top left, while others have them on the right side. I could keep going... It's the total opposite of "clear mapping of results" to me, and certainly isn't anything close to "consistent".
I don't think AWS "nudges you as little as possible", I think AWS nudges you a lot, but nudges you in completely different directions for every single service, causing you to feel bounced around like you're in a mosh pit when you're having to switch between EC2, CloudTrail, S3, etc.
Even in Home Depot they at least have uniformity in how they arrange their aisles. The nail aisle has little buckets where nails are arranged by a specific ordering system, typically by type of nail and size. If you go an aisle over to plumbing, the pipe joints are all arranged in similar little containers, also with a sensible ordering system typically by type of pipe and size. If you go to the paint aisle, the displays are different but you can still expect them to be arranged in a sensible ordering system, such as by type of paint and color.
If they went the AWS way, the aisle of nails would just be 2-3 large tubs with a bunch of individual nails thrown in, while the plumbing aisle would have things organized in small tubs alphabetically by the name of the manufacturer, while the paint aisle would be condensed like a newspaper with the pages in order of Bob's favorite colors. It would be chaos.
Sorry for the rant. I respect that you apparently like the UI, but it's weird to me that we have such opposite experiences. You say "Home Depot understands it's just a faclitator" and that AWS is too, and I totally agree. But my opinion is that AWS completely fails at effectively facilitating.
Or is this just for apps that would otherwise be run from a spreadsheet, and not displacing anything an engineer would build?
I think the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context. The hard part of creating useful software is that you have to understand a business process and its requirements so precisely that you can write it down for the computer to do. I work with business stakeholders creating internal…
I think you are radically underestimating the perceived barriers to entry with programming. You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. This type of insider view is often referred to as 'the curse of knowledge'.
But here's what I think you give up if you don't have code. Over the past 70 years, one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams. This complexity includes not just the program you're working on, but potentially the entire ecosystem of algorithms and solutions available for your use. Nothing comes close to "code" for addressing this problem.
As a result, I think if you're going to give up code, you have to accept that your projects will run out juice if they get too big or complex, or that you will have to solve some interface problems with manual steps. That might be perfectly OK.