> Just like Javascript made programming more accessible to a broader audience
I think this is entirely cart before horse. What actually happened was the web made programming relevant to a much broader audience and JavaScript is the language you use to program for the web, so everyone learnt that.
Also anybody could right-click and "view source". (Imagine being able to do that in any Swing app in their peak, for contrast.)
When pages were just a few hundred lines any page could be recreated with a web browser, ambition, and enough time. Those days are long gone, now, with huge transitive node dependencies, minification, and feature-combinatorial-explosion. Like a sandboxed document-centric qbasic.
I’d save whole websites and play with their code (back then that meant html2/3 and early css and Javascript, but still). It was enticing after playing with terminal views for years before that. Kids like colourful things, what can I say.
Yeah, so many of us got into the trade that way, and in turn developed it into what it became. I’m not proud of my animated GIF phase. Since websites are inscrutable and often irrelevant to the cutting edge internet experience now, it makes me wonder what welcoming medium the kids are going to find that solidifies it as the next creative platform that industries are built on.
To some extent it was both. The web made programming relevant to a much broader audience, and JS is much more approachable than other popular languages from that time (eg C++).
JS appeared at the same time as PHP and Ruby. Python was 4 years old when JavaScript was first released. All those languages are about the same level of complexity.
Now the latest boom if JS is its use in full stack applications with Node.js One language, everywhere. Also supersets like TypeScript for validation and specificity.
It's JQuery and its successors that made Javascript more accessible to a broad audience. If people still had to handcode Javascript it wouldn't be nearly as widespread.
Programming is 75-90% repetition of patterns. The remaining 10-15% are the difference between a simple translation of usual human language into a foreign language vs. developing algorithms and/or logic to solve a problem.
If we can get rid of the non-algorithm, non-logic part we'd be better off, and this is what i read into this sentence.
You have to put that exactly in every Java program. Why? What does it mean? Why can't I omit it?
To answer all of those questions, you need to go into method visibility, the difference between static and instance methods (itself easily requiring the teacher to introduce the concept of 'state' and what OO is at a basic level), types and the notion of a "void" type, and odd historical baggage which prompts the JVM to look for 'main' as a special, magical name. You haven't even gotten to "Hello, world!" and you have to unpack at least a lecture's worth of knowledge into the poor sap's head.
It's a lot easier to have a language where you type commands and the machine follows them. Even fundamentally bad languages, like GW-BASIC (my first language), have a hypnotic power over young programmers simply by virtue of that immediate response.
This is what is said. So why do you appear to oppose?
Programming today still means 85%-90% doing repetitive stuff. Tools could do away with this, freeing the developer/engineer to spend more time on solving actual problems.
If you oppose to this, please state the reason why, since I'm probably fogged.
To be more clear, I don't propose to make programming easier. I do propose to make so-called "programming" go away, to focus on the actual problem-solving part. "Programming" to me means mostly translating requirements into code (without having to deal with decomposing and recombining requirements, which is the real work).
> Programming today still means 85%-90% doing repetitive stuff.
But some languages have more than others, which is why they're bad teaching languages.
That's my point.
> To be more clear, I don't propose to make programming easier. I do propose to make so-called "programming" go away, to focus on the actual problem-solving part. "Programming" to me means mostly translating requirements into code (without having to deal with decomposing and recombining requirements, which is the real work).
Translating requirements into code is programming. Reducing boilerplate isn't making programming go away.
No, it's known as a Read-Eval-Print Loop, or REPL.
"Shell" is a kind of REPL for a kind of language, both being optimized to minimize typing required to execute commands and string them together in a pipe. It's good at its job, but it's poor general REPL. Proper programming REPLs are very powerful and very useful tools, to the point I'm pretty unhappy when I have to work in a language without one.
repetition of patterns is the easy part, so getting rid of the easy part and leaving the difficult part might not make much difference in the end. Especially as the easy part can be an access point to the more complicated.
Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now? It seems like a pipe dream. It's built on some innate belief that someone can create tools that work for every kind of business possible, which is crazy. I can think in the past few years I've worked on health care registration websites, diamond auction websites, oil reserve management software - nothing would have been tied together with any common tool and all required extensive amounts of custom code for their business logic. I think it's time we drop this dream of normal "business analysts" writing all the software in a company.
> It seems like a pipe dream. It's built on some innate belief that someone can create tools that work for every kind of business possible, which is crazy.
It doesn't need to work for all every kind of business.
Often it starts with an excel sheet. Which works for surprisingly long, but eventually problems with concurrent data entry, or more logic / validation etc. really make that untenable.
But, going from a highly customized excel sheet to an in-house developed custom application is a huge leap; only when you start to replace it do you realize just how many Excel features you were actually using.
When you start writing a custom application, you need to take of authentication, permissions, audit logging, search functionality and so. Maybe your web framework helps you with some of them, but never all of them, and the missing concerns are a huge pain to get right.
I really want something, either a framework or a highly extensible application, to let me actually focus on the business logic. And at the same time, still let me deploy on premise, let me have a functioning CI/CD pipeline and keep my code in git.
For a complex project, it will be a programmer writing the code, not a business analyst. But they should focus 90% on intrinsic complexity, not on accidental complexity. We're not there yet, so we need something better.
> For a complex project, it will be a programmer writing the code, not a business analyst. But they should focus 90% on intrinsic complexity, not on accidental complexity. We're not there yet, so we need something better.
What follows is a tired argument, but hear me out as I'm using it as a springboard. The reason you hire engineers to design bridges is because they know how to do the important engineering bits. If all it took to make a bridge was knowing how cars will move from one side to the other, then we wouldn't need engineers. So...
We often want our software engineers to do all the business logic too, which is why engineers that provide the most value to projects are actually people who love building business solutions and not engineering software, or some blend in between. But maybe that's also why most software sucks and costs a fortune (sorry everyone).
Is the issue that we're conflating the two tasks into one? If so, is a product that would solve your problem one that cleanly delineates between software engineering tasks and logic tasks? Or is it one that gets rid of software engineering all together, if that were possible?
> I really want something, either a framework or a highly extensible application, to let me actually focus on the business logic.
I would argue there's already many relevant application frameworks that are good at this once you learn them, the trouble is the industry moves so fast between tools so your business solution specialist programmers spend all their time learning new software engineering paradigms.
> Is the issue that we're conflating the two tasks into one? If so, is a product that would solve your problem one that cleanly delineates between software engineering tasks and logic tasks?
Oh yes!
> Or is it one that gets rid of software engineering all together, if that were possible?
I have no problem with doing software engineering when I don't have the feeling that the problem has been solved dozens of times before.
Let me try to give an example: you run a colocation business. So you have to manage data centers, cages, racks, and the hardware that's in the racks.
I want a solution where the boring CRUD is mostly taken care of, so you get a list view of the hardware, you can filter it, modify and so on. You can also define some constraints (like, a hardware inherits the location from its rack) that are automatically enforced. And of course permissions are enforced, a customer can only see their own hardware, and can only access racks that contain only his hardware etc.
But I also want the flexibility that adds a rack view, where I can show a 2d graphics of the rack and where each piece of hardware is, which port is connected by cables to which other port etc. This is something that nearly no other business needs, so I'm totally fine writing my own thing for this view.
Software like ServiceNow allows the first part pretty easily, but it's expensive, cloud only (unless you pay several millions a month, I've heard) and doesn't have the kind of flexibility to allow me to implement the rack view, for example.
> Is the issue that we're conflating the two tasks into one?
I'd say it's the opposite. Business logic is software. More than that, bureaucracy is software too. Same goes for contracts, and laws too[0]. It's because "If <this> then <that> happens" is code. "Do <this bunch of stuff> until <this happens>, except when <something else happens>, do <that> instead" is code.
So when you're encoding the business logic in your software, what you're doing is copying some external code into your program, and translating it from natural/legalese to your programming language. With all the consequences this entails - you now have two independent pieces of code that do the same, are not visibly connected, and evolve separately. Whenever something changes in the way business works, someone needs to update that same code across applications that use it. Mistakes are bound to happen.
A big problem in the above is the state of the code you're translating from - the actual logic of the business. It's a continuously evolving system that's being developed by people who are specialists in business, not in logic. That's why business rules often seem sort of but not quite coherent, with exceptions and repetitions, and special cases. It's because people responsible patch them up as they discover problems, but the concept of refactoring or unit testing or integration testing of actual business rules is something between not known and not doable in practice.
So in the end, I'd think that yes, there's more than one type of jobs in here, but they're actually all software development. Not in the sense that they're all writing programs for computers - some of it is writing programs for humans (the bureaucracy) - but all of it could use some of the insights and tooling from software development. There is no separation between "software" and "logic" - there's only separation between what can be fully specified, and thus treated as code, and what cannot be specified, because it's too much tied to fuzzy, case-by-case value judgements.
(Going back to your bridge example: you hire civil engineers to design the bridge, but then again, you don't just go out and say "hey, I have money, go build me a bridge!". A bridge has to serve a purpose and integrate into other systems, which is why those bridge designers get input from traffic engineers, urban planners, and other engineers/engineer-likes.)
--
[0] - Now, to be very clear, I'm not on-board with the current ideas of "code as law", and I don't want them becoming reality any time soon. Fully specifying laws would require us to have total understanding of human values, which we don't have - that's why the role of human judgement is important, and that's the good reason for which laws are underspecified. Same goes for contracts and some business rules too.
[1] - They sometimes also have an incentive to keep things opaque. Sometimes a reason for a business rule to be unnecessarily lax may be that the "wrong" state is actually a "good" state to someone who doesn't want to admit to it. Think e.g. costs savings by trading off security or reliability, or tax evasion.
> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
Excel is that way now. It's programming for people who do not program, and it's no less mentally involved. It's just harder to extend beyond a certain point, because Excel is a pretty lousy development environment, and it typically doesn't have productivity helpers like source control.
It's also hard to port an Excel program to anything else because spreadsheets are their own programming paradigm, almost, although 'dataflow' isn't a completely alien term in the CS world.
> because spreadsheets are their own programming paradigm
They're reactive programming. Yes, the current hot buzzword. The stuff you do (or at least you're supposed to) when building React apps, or working with FRP libraries in your programming language. The stuff that boils down to defining a dependency DAG, and having the framework keep recomputing it as you change individual nodes.
Excel is that. There's actually a set of buttons in the ribbon somewhere, called "Trace Precedents" and "Trace Dependents" - when you click them, Excel will start drawing arrows between cells, showing you the underlying DAG.
(I literally used this yesterday to help someone I'm tutoring to understand how to rewrite the spreadsheet we've made in C++, and why these are two forms of the same program.)
Those exist; the one I'm most familiar with is Odoo. You download it, point it at a Postgres server and start it up. It shows you a web UI which asks you for a name for a new DB and a admin password.
After that, you get a login screen of a typical web app, but almost empty, with just a menu to configure users, groups and basic company info.
From there, you can create a module (just a folder with some basic metadata) and in it write a Python class with a few fields (like a Django model), and a menu linked to it. The system takes care of generating some views for CRUD: you just click the menu and it shows you a list of records, then click on a record to see an editable form, etc.
Permissions is just a matter of configuring in the UI or writing a CSV file that says which user groups can read and/or write which class / model, or you can write more complex rules (like users of certain groups can only see records created by them, other groups can see all).
(Disclaimer: I worked for a few years for companies that developed Odoo modules, but have left the platform for a couple of years now)
But a lot of things that used to require custom software ... don't, anymore. I think what happens is that the kinds of jobs that are stitched together with Iftt/Zapier/Google sheets/whatever stop being classified as "software," so we've got an ever-moving-target.
There'll always be a frontier that requires deeper technical expertise. But that frontier will keep moving.
I view my career through this lens now: I aim to find things to work on that I believe are very likely to remain in that frontier that remains classified as "software".
I find this useful when thinking about companies and projects. If they seem to be building a CRUD app with clients for different platforms, at a small to medium scale, that might not be far enough into the frontier for me.
This is purely a matter of taste or personality. Another very useful (and probably more lucrative) thing to do is to find ways to leverage the ever-increasing ability to build that kind of simple but useful application for some domain without writing much or any of your own "software". But for me, that just doesn't match my interests as well.
I think is better to say "software usable in 10 minutes" for people that is not a full time developer.
Things like excel, access fit there. The big mistake is not provide a way out the "click and get a full app!" step. This in when things go to fail with this kind of ideas.
---
I learn foxpro as my first language and is surprising how many "non developers" use it in the day.
I think it get loved precisely because was a bit "harder" than access: You hit a wall with access/excel much faster than foxpro/jupyter, making them for some people HARDER tools than the "harder" tool.
Not fun when things are easy, and suddenly, impossible. I say that we can give people credit and them could learn some complex stuff, as long fit well their use case.
I think the same. My side project is to build something alike. Programming move out "RAD" tools when the web come and making rad for web is near impossible, so somehow that translate "and then stop for everything else".
Ironic, because now with mobile it have a good chance!
It’s funny: nobody asks for “cars that don’t require technical skill to build” or “airplanes that don’t require technical skill to build.” Why this need to open up software development to people without development skill? As you point out, people have been banging this drum for decades! Why is it ok for some goods to require specialized skill to build, but for other goods the need for this skill is always seen as a problem that urgently needs solving?
People want cheaper engineering services, in all fields. some work and some companies are working on that. See "generative design" in Mechanical Engineering and Architecture.
As for the demand for software tools ? Old startups in that field are starting to show good results, there's money available, so it looks like a good opportunity for a VC.
I don't know if "software that doesn't require any tech skills to build" is realistic.
But a lot can be done, much faster, with much less expertise required, using modern "low code" tools.
Just a few examples from the OutSystems marketing materials(i can't vouch for them, but still):
------------------------------------
"Eighteen applications are already in productive use, some of which have hundreds of users.
The company has succeeded in its aim to make research scientists self-sufficient, so that they can build and deploy mobile apps for high-speed experiments, without clogging-up the central IT development team."
> Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now? It seems like a pipe dream
Whether or not it is possible, it means nothing that it hasn't happened in 25 years.
25 years may feel like a long period of time, but it isn't when we're considering the development of technology. In historical terms, we're still in the infancy of computer technology.
> Haven't we been hearing about "software that doesn't require any tech skills to build" for 25 years now?
Does anyone here have examples of startups/products that tried to build "no-code" tools historically and failed? (aka. more examples like "Dreamweaver"?)
I don't have too much historical context on this stuff and would like to look at the graveyard. :)
Programming shouldn't exist. Problem solving, algorithm development and logic decomposition/recombination should exist instead.
To me, and I presume to the author, "no code" doesn't mean no engineering but the exact opposite: do away with mechanic vocabulary to vocabulary translation work and focus on the actual skills, which are decomposing requirements into atomic units of work and (re-)combining them in a manner making the domain understandable if expressed as code.
> focus on the actual skills, which are decomposing requirements into atomic units of work and (re-)combining them in a manner making the domain understandable if expressed as code.
That's literally almost all there is to programming; the rest is just typing things up.
What we program in now is a thin veneer over machine code. And as you point out, it's been 50 years. We're supposed to go totally code-free in the next 10?
Everybody in this specific social group of investors continues to list Developer Tools as, effectively, an Evergreen space.
What’s baffling to me is that the amount of innovation in Developer Tool businesses (not tools, businesses) is surprisingly small. There are three factors that influence this, IMO:
(1) The OSS community has trended towards an insular culture incentivized by OSS popularity where stars and Twitter followers are status signals. In this world, it’s hard for talented engineers to stop seeking “star status” and transition to the business ecosystem where they’re bottom rung of the ladder.
(2) The space is extremely sophisticated — with longer R&D cycles — and VCs routinely incentivize suboptimal growth trajectories when they’ve identified apparent winners and miss opportunities with more practically iterative companies. (Expecting growth at all costs in a space where continuous delivery + R&D is the norm.) This blows up some companies early and prematurely kills other promising technologies. I think the 18mo expected cycle time probably needs to be adjusted for these companies, especially early stage.
(3) Founders are heavily pressured towards exits. Long R&D cycle time, the pressure cooker of VC growth expectations, and the rarity of high-ownership, customer-oriented developer tool + engineering talent makes early exits extremely attractive for both founding teams and acquirers.
How do we fix this? Between Daniel, Elad and a bunch of folks who keep writing this stuff — I think it’s time for a new developer-oriented fund, backed by the people and companies passionate about the space.
I’ve been a major sponsor of Vue.js for years. I’d like to do more to help talented developers start businesses in the future, when possible. If anybody thinks something like this is interesting, give me a holler.
There was a recent post here on HN for a medium article "Get Rich Slow And Steady" [1]. It seems like this is a space attracting the attention of investors. I think the developer tool business overlaps with the type of SaaS businesses described in the article.
There is still space to tackle getting from a no-revenue idea to a stable cash-positive subscription service. My eyes water when I see ideas attracting 10+m in seed capital before they even have a viable product. I remember pitching an idea with a friend for a slow burn SaaS startup (in real-estate). We wanted under 1m and we were laughed out of every room. Everyone wanted to back a potential unicorn and not waste their time on guys thinking so small.
Maybe things have changed but it seems right now there are two categories: startups with huge ideas that can get substantial venture capital to take moonshots and stable existing SaaS business that can slow burn on existing subscription revenue. I'm just not sure there will ever be a market for "Give us 1m and we'll build a company that generates 250k/year of profit".
Well, to be fair, some (or even most) small niche ideas won't be that profitable (if they are profitable at all). That is the reason why I feel that the market for those small investments will never really flourish. The downside is the same, you lose all your investment. The upside is completely underwhelming, you recoup your investment after 4 or 5 years after which hopefully you see a profit.
This is traditionally the space for friends-and-family investment or bank loans. If I was an investor then I don't think it is a space I would get into.
It also explains why the article I mentioned is focused on established and profitable SaaS businesses. That means the filter for crash-and-burn has already taken place allowing investors to change their ROI calculation enough to make it viable.
Isn't it harder to compete on established and profitable SaaS business? What can a small dev shop, or an indie developer do to compete in a space like this?
To be clear, the article isn't advocating for investing in companies competing against established/profitable SaaS businesses. It is advocating investing in the existing companies that have already achieved profitability.
Heck, you could start ideas with much less. Here in colombia you can do US3000/month * Dev to do whatever you say. But even the people here that give funds not do that!
I'm the guy behind Sidekiq, also mentioned in the article.
One person can still built amazing, successful tech with a slow and steady approach and little to no funding. My trick was to charge something reasonable ASAP and get to a sustainable "default live" state.
I think monetization is difficult IFF you don’t think about asking for money from the get-go. I’m actually of the opinion that open source projects are not well-equipped to build companies around, but can serve as an early guide to nascent market demand.
Monetization looks difficult because people keep building free things and then trying to figure out how to charge for them. From my perspective, the better bet is to build a free thing, prove the market, and then figure out what the paid thing might look like — even if totally different.
I think there’s a decade ahead of us where developers can start asking, “how can I turn this {useful tool} into a SaaS product?” We've been seeing this for years, I just think folks can start getting more ambitious about it. :)
Yeah, this hurt. I think you could find many talented developers with high interest in advance the state of art, but then remember need to put food in the plate and that is.
----
My dream is to build a foxpro/access kind of tool (starting as a relational lang), but this is purely a side of a side project that I still keep alive by purely fun. Having in the mind that the chance of being financially good is near zero and with more pressing needs, is hard to make it.
I could totally take a small investment just to get "survival" for months, but who will invest it?. I think even much more skilled developers like http://journal.stuffwithstuff.com/ will not get funds for a startup for dev tools, that is look to me anyone in the field must work for big corp to hace a chance to see it.
VERY interesting. I have a few friends with companies in the "shovel industry" that are VC backed and they also raised very similar points to the ones you've mentioned, which is keeping me away, having experienced being in a business that was hit by a variant of (2).
Technology-wise there is a great many approaches out there in their infancy, that usually die before they get a chance to be fleshed out into larger companies.
The intersection between No-Code & Developer-Tools is to me one of the most-exciting spaces to watch.
I can't imagine we'll design & document business-logic and requirements with so many breaks in the chain to production ten years from now.
> DuckDuckGo is small, but it’s growing 50% year-over-year. As of last week, it is also a search option on every European Android device. If the growth rate were to double, DDG would surpass Google in 6 years.
That's what we call a "Big If". And doesn't DDG just rent someone else's index?
Their marketing and brand are the most important aspects. Bing proxies are a-dime-a-dozen but only DuckDuckGo has achieved tremendous media attention and funding.
One of the proxies had to win out, right? We're only talking about DuckDuckGo and not BearBearClaw because they survived. I don't think they're doing anything particularly special. They're also a much older company with a lot smaller search volume than people realize.
If you are willing to spend a decade marketing privacy features and bashing the establishment, yes. They are not Google-style "tech disrupters". One could say their success is as much a product of Edward Snowden's revelations and the subsequent societal shift towards tracking-as-a-liability as much as actual technology. Don't get me wrong, their UI gimmicks like !g are nothing to be scoffed at. UI has value, just ask Robinhood and Stripe. But DuckDuckGo is certainly not "hard tech".
You sure could. But DDG is a decade old company and its total lifetime searches amount to less than a week's worth of Google searches so it's likely your efforts will be in vain.
I don’t think GP’s claim is entirely accurate. Bing is an input into the results, along with other inputs (Bing is less than majority responsible in most cases iirc). I don’t remember if DDG does any indexing on it’s own.
Hopefully someone more informed can chime in but GP’s claim was strong, provocative, and to my knowledge inaccurate so wanted to correct it.
Practice creative writing daily. I'm not too convinced reading a lot is part of it, as the other comments suggest. Else we'd all be great writers. I'd argue that consumption is the least important part of being a good creator. Else we'd all be good creators with our endless content consumption.
But I guarantee you will notice results if, every morning, you write at least a few paragraphs answering some sort of creative writing prompt. After a while, creative ideas will just come out of your head as you try to write. Just like how words and phrases magically come to you as you get better at another language.
https://old.reddit.com/r/WritingPrompts/ is a great resource. I like to read a few ideas in the morning and consider them in the shower. Then I brew a coffee and write as much as I can before I start my day, even if my idea completely sucks. I just try to treat my crappy idea as a constraint and run with it.
Read a lot and think about what makes this writing good or bad. Then try to duplicate it and show people and get feedback. Show it to everyone and anyone.
This is how I approach physical board game design. Play as many games as I can and contemplate the choices made. Why do people like this game even if I don't. Then make my own and have anyone and everyone play them. Modify and test again until strangers ask me when they can buy the game they just played.
When you think or hear a particularly clever phrase, write it down. Whenever you feel the creative urge, stop all other things and write it down.
When writing, try to imagine and feel what it is you are talking about, and metaphors will naturally suggest themselves from a combination of embodiment of feeling and resonance against the words you have already written. For each of the lines you noted above, can you feel how the author feels and thinks about the item being discussed?
Particularly potent writing uses this device, lingering on these interwoven metaphors to set a contextual feel that makes it easier for you to get the point they intend for you. In this example, the first three are interwoven metaphors all drawn from the schoolyard.
Read a lot of content like it, really the same as any sort of writing.
Then practice.
You could additionally look to use a memorisation tool (something like Anki perhaps) to store new words and phrases that you like, so they are in your head, ready to be retrieved as you're hammering away at the keys.
Half the bullet points on here all fall into enterprise SaaS...
In my opinion the shift from big game changing ideas like Airbnb, Lyft/ Uber, and Stripe to a dozens enterprise SaaS apps popping up in San Francisco has been one of the biggest reasons why I've felt for the last year that there doesn't feel like there's been a "big next thing" for awhile.
I just can't get excited by another dressed up note taking app, and wouldn't be excited to work for one.
It’s more exciting to work at a company that is actually game changing. Some SaaS cos fit into that bucket as well, but majority I see funded today fill some niche project management use case that just isn’t that appealing to me.
While these two may seem contradictory, I see this as a great trend for developers.
Developers of 10 years ago would focus on building common solutions like blogs and landing pages. Now there are slew of NoCode startups that allow non-developers to do it themselves.
This frees up developers to focus on more complex problems.
The Developer Tool startups of today should be asking - "what are the common tasks that developers are doing today, that will be easy for non-devs in 10 years?"
Perhaps my thesis if wrong, but that's what we're hoping to achieve at https://supabase.io
In our case the "complex task" is creating CRUD APIs. Creating these are monotonous and developers could be spending time on much more valuable tasks. We're starting to see this with the rise of amazing tools like GraphQL/PostgREST.
Other areas to watch will be the "simplification" of databases. Think "MS Access" for advanced databases like Postgres. Metabase is a good start here, focusing on the reporting aspect of the data. The next steps may be database design and data entry, - Retool seem like they could do well in this area.
Possibly, In 10 years low code will dominate enterprise development, IOT and quite likely , also most consumer crud apps.
And today, many people develop very similar services across companies. In the future most of those services will be available online.
On the other hand software will become dominant in many more fields.
SO that will require more infrastructure, and more software engineers dealing with machine learning, unstructured data, data science, 3d objects and worlds, machine creativity, experts in optimization.
"3. The New Meme: Enterprise Search
“Enterprise search” is shaping up to be in 2020 what RPA was in 2019. A startup idea that hits the seed ecosystem like a fashion fad, with a surprising number of founders suddenly all wearing the same ripped jeans. I’ve seen about a dozen teams and companies working on next-generation enterprise search in the past few weeks. They’re all attempting to build the same thing: a search/feed/discovery product that helps you find things amongst Slack, Gmail and Salesforce clouds.
I’ve yet to see anyone properly tackle the more rudimentary, “boring” and lucrative approach: an on-prem search appliance, similar to GSE, that indexes internal intranet, wikis as well as email. On-prem software is annoying to build, something many founders shy away from."
At my old startup Pinecone, we built something similar called Ask Pinecone. It would index everyone's emails and internal wiki's on premise. Then you could send an email with a question to ask@youcompany.com some Bayesian based modeling would then forward the email to the most appropriate person at the company based on the contents of their inbox and your email.
> I’ve yet to see anyone properly tackle the more rudimentary, “boring” and lucrative approach: an on-prem search appliance, similar to GSE, that indexes internal intranet, wikis as well as email. On-prem software is annoying to build, something many founders shy away from."
It's hard because you need to access the documents and from a security perspective that's not ideal. We took a different approach which actually builds a search graph based on what's discussed (plugs into email, slack, etc.): https://insideropinion.com/
Works very well and doesn't need access to the source document (so more secure), although that'd improve the search.
Re: the first point, Amazon is terrible now. I’m afraid to buy things because of all of the fake reviews. How are you supposed to buy products sight-unseen with fake reviews abound?
I wonder if a curated, moderated Amazon could work? Probably wouldn't scale very well, but perhaps if there were more live humans involved in the process of choosing which items were available for purchase, it'd work a little better?
I sorta feel like the future is in smaller more boutique sites for specific things. Like Wayfair for home furnishings or Chewy for pet supplies. A bit like going to the local pet store instead of Walmart for your dog food.
Here's one non-abstract idea that you can get for free, even though I might try myself as well:
Give Confluence a run for its money.
Confluence is so bloated that a clean install takes longer to start than it takes to boot my laptop and log in.
Plugin SDK documentation is a mess.
As far as I can see it only sells because of the brand and because of network effects.
If anyone could manage to create a real wiki (remember, it means quick!) and market it they might have a chance at some nice cash that would otherwise flow to a company that keeps wasting peoples time.
I would adjust this. No company will buy products just because they are a bit better. You have to completely knock that out of the park to be compelling.
OTOH, I'll grant if you really fail on support etc. you will probably fizzle out anyway.
I've bumped into two organizations which use Confluence for developer reference rather than Github's own repo-based wikis. Why??? In one case a manager even made us move an extensive github wiki to Confluence. After that, developers stopped using the reference and that had an impact on code quality. WTF.
There are already some good general purpose wiki providers out there, too!
> Given free transcription and the drive of remote work to video conferencing, we’re about to witness a Cambrian explosion of cataloged meeting information. What was previously oral knowledge will be automatically documented by machines. We’ll see many opportunities come out of this.
Automatic searchable transcripts for video chats. Now that sounds useful!
My startup is currently working on this now. One of my major concerns is data security and client confidence.
One hurdle I haven't figured out how to get over is reassuring clients that their data is safe with us -- i.e. we aren't reading/listening in on every conversation.
"I’ve yet to see anyone properly tackle the more rudimentary, “boring” and lucrative approach: an on-prem search appliance, similar to GSE, that indexes internal intranet, wikis as well as email."
Is there a reason to believe this is something enterprises actually want? Was GSE too early?
Enterprises want this. Source: Every single company, tech or otherwise, everywhere in the world, is a complete mess when it comes to discovering information you need to do your job.
Whether or not you can actually make enough money from building a selling on-prem search is another question. It is an incredibly difficult space to develop for, because every one of these messes has a vastly different IT stack. [1][2][3]
You could take the easy way out and build search for Slack + Jira + Email, but that would help less than 1% of businesses world-wide.
[1] The first full-time job I worked had an unholy amalgamation of HP Quality Center, SeaPine source control, something about Sharepoint, and random documents stored in people's shared folders. Oh, yeah, and it had an on-premise Google Enterprise Search (Or whatever it was called back in 2011), which was almost entirely useless.
[2] The second was a mix of Jira and TikiWiki.
[3] The current job my wife holds has a bunch of files in a shared directory, a database that is installed from four floppy disks, and an IT stack that quite prominently includes Windows 2003.
> It is an incredibly difficult space to develop for, because every one of these messes has a vastly different IT stack.
I have a strong feeling that Google Desktop Search had a lot of this sorted.
That was 10 years ago.
With all the advances that has been happening in the meantime and assuming businesses are interested enough to adjust a tiny bit to simplify crawling this doesn't seem impossible at all if a well-funded team started working on it.
The technical problem is solvable, the deployment and technical support, and sales problem, and getting customers to upgrade, and the technical support, and did I mention the technical support problem would be a complete nightmare.
You can't actually leverage any of the economies of scale that you can get from building software, when you have to hold the hand of every single customer you deal with.
Someone like Oracle[1] can get away with this sort of thing (While charging an arm and a leg for it), but this is not the problem that your typical startup can solve.
[1] The other difference is that your Oracle database + solution is business critical, and businesses have no problem with paying $XY,000/year for business-critical solutions. Intranet search is a nice-to-have, and businesses balk at paying $5/user/month for that sort of stuff.
Totally agree. We looked at providing tech in this space and it means you have to plug into literally every system. It’s an endless problem.
Slack search is awful and they have a full team on it. Jira is a mess. Gmail search is pretty good already, which is one of the things that makes frontapp far less useful also.
whether they want it or not, they probably need it. the last few enterprises I've been in, I could never find anything. And because people couldn't find stuff, it was a disincentive to document stuff (because no one would ever be able to find it anyway).
Getting everyone to put everything in confluence - for example - helps, but... there are entire categories of data that don't end up getting stored in confluence, so... it wouldn't get found. And, fwiw, the confluence search always seems to be not very helpful whenever I'm needing to find something - but I often can't tell up front if the search is bad or the data just isn't there (or I'm searching for the wrong terms).
If they don't want it, though, they won't buy it, whether it's helpful to people on the front-lines or not.
Probably yes. I think there are a few companies that are hesitant to put everything on the cloud. There are probably hybrid options worth exploring. But lucidworks.com is in this space so ... I think you can be self-hosted or managed.
Well, thanks for introducing me to Vayyar at least ;)
If I understand their value prop, they provide a single sensor solution that is essentially a black box. And the output is the wide-range 4D point cloud. Power consumption is ultra-low. But the fidelity is still very high. It's up to the partner to design the software that consumes the data. Vayyar just provides the black box.
If it works. The total market here seems on order of "replacing cameras" in retail, manufacturing and surveillance!
A start-up at the intersection of 'developer tools' and 'NoCode' would be very exciting to me. I'd love to see tools that reflect some of the principles outlined in Bret Victor's blog.
Just remember that the tool has to be useful and practical at the end of the day. Red's obsession with crypto tokens and the failure of Eve reflects badly on the rapid application development ecosystem (on the other extreme, you have Embarcadero Delphi and SAP, each costing n-figures). Microsoft's suite is for some reason on life support. Access, Visual Basic are all pale shadows of their former selves.
Visual Basic died because Microsoft chose not to continue development of the VB6 comatible ecosystem. It was a multibillion dollar a year business in the 1990s
We tried building NoCode (used to be hosted at noapp.mobi), I think around January 2017. The project has been abandoned since then, you can find the project at -
This was a POC project. It was quite suitable for simple business process management based apps. One of our customers has been using a conference room manager built on this platform, for 3 years now.
Does "No Code" just mean having a UI? What I mean is the examples it gave for "No Code" look like regular Saas companies so I don't see what's the difference between something labeled "No code" and a regular software product that you use a UI to do things since the code is abstracted away. The majority of web based products don't require the user to code so "No code" seems like a buzzword more than anything.
For #3: If anyone is looking for an enterprise search they can boot up "cloud-prem" (in their VPC), that's exactly what we're building at https://landria.io/customers/why-landria.
It's totally feasible to start a successful company outside of these ideas. I think this list is helpful because they answer the "why now" question that VCs are looking for.
In other words, this list is helpful if you're trying to start a $10B company today.
Not to be too cheeky, but this is mostly a list of trends dictated by companies started three or more years ago.
Meaning it's actually "VC Compatible Startup Ideas 2017."
Outside of Developer Tools (I'm a fan!) I would say your advice -- it's feasible to start a company outside of these ideas -- is probably exactly where you want to be looking if you're starting a company today. Daniel's an investor, so he's casting a net for startups / founding teams he hasn't heard of yet. Content marketing is dealflow 101. That said, if you're a founder in one of these spaces, he has a fantastic reputation, so you should absolutely reach out. He wouldn't have posted it if he wasn't looking for awesome people!
Interesting read but none of these ideas actually explain what problems they solve. Programming is my hobby and being financially secure, I’m in position where I could easily spent half a day writing someones code for nothing more than “thank you, good job”. Seriously, so long as I know someone’s problem is being solved. I wish there were website like “thank you for programming dot com” where people with low or no budget could post problems that programing can solve and programmers could tackle those at zero financial gain, maybe only as a extra point in their resumee.
Bytedance?? OK, I guess... But Lark's home page blurb seems a bit direct: "Hey look, the Chinese government is going to hack into your servers and look at all your corporate secrets sooner or later, why not just make it easy for both of us and use this service now? Sign up here."
Was this published in 2019 or 2020? There’s a line pretty far down the page in the Enterprise Dabblers section that says “As of today (January 2019), we see a half dozen pitches a week for automation software”
Maybe that was a typo? Or maybe this is a slightly updated article from a year ago?
Re 2. Saying Yes to NoCode ... We are working on an MVP in this space called Webase. It is still very early but we are starting with basic CRUD operations and then will be layering on more sophistication going forward.
Completely agree on the "Carbon and Climate" section.
Negative makes a carbon negative bracelet made with carbon dioxide pulled from the atmosphere. I created the company to make carbon more personal. http://gonegative.co/
Interesting thought. If TikTok got banned they would probably release a web interface for Americans or Android phones would suddenly become really popular among teens.
So teens would dump iPhone for Android just to get TikTok? That would be very interesting indeed.
The other year, teens were surprised when they got a green bubble on their iMessage, indicating the other person was not using an iPhone.
Admittedly, TikTok does appear to be more fun and interesting (for teens) than Instagram, Twitter, or Facebook, because the point is to just watch fun and pointless stuff. And maybe learn something new, or do something yourself to imitate them.
I think this is entirely cart before horse. What actually happened was the web made programming relevant to a much broader audience and JavaScript is the language you use to program for the web, so everyone learnt that.