5 ms·

> It means we have a new prototyping tool. Cool. Don't worry, your skills aren't going to become obsolete Not at all actually. There is a ton of demand for lig

by mbesto 10y ago

> It means we have a new prototyping tool. Cool. Don't worry, your skills aren't going to become obsolete Not at all actually. There is a ton of demand for light code app builders (waves hand) for simple CRUD stuff in most businesses. These apps are usually cost prohibitive to build and maintain, so things App Maker make a ton of sense.

Clubber 10y ago
What happens when the business outgrows what AppBuilder can do? I would assume that's a ground up rewrite. Seems like it's kicking the issue down the road and accumulating technical debt along the way.
- mbesto 10y ago
  > What happens when the business outgrows what AppBuilder can do? Then they just find an off-the-shelf solution (SaaS most likely) to replace it. > Seems like it's kicking the issue down the road and accumulating technical debt along the way. If you do a ground-up rewrite or find an off-the-shelf solution then technical debt doesn't matter anyway does it?
  - marktangotango 10y ago
    You see this same situation with large and small legacy systems that have reached end of life and need to be replaced. In some since the app or system can serve as the requirement for the replacement, but no one ever sees it that way. Why is the rewrite late? Still waiting for requirements! That running system over there is your requirement! Wait, that old crap? Yes that old crap.
- kartickv 10y ago
  If App Maker takes an order of magnitude less time than writing the software they want, then it can be low-risk. If something takes a long time and may not work, that's when it's risky.
- aryehof 10y ago
  Better to build for today, than be consumed with what might be tomorrow
  - candiodari 10y ago
    I work in a huge company. Being consumed with what might be tomorrow is taken to an extreme. Given what I hear from other companies, this is very common. Sad part is, it never works. Designs don't ever match up with real world requirements (they match up very well to stated requirements). Anticipated changes never happen, but other changes do, and ... then of course a rewrite is needed, after attempting to get 2-3 unanticipated changes built into the "agile" design. "Technical debt", is the explanation, often without any further clarification. We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants. Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving. The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it. Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
- cookiecaper 10y ago
  Because it's harder to read code than to write it, most freelancers/contractors a small business would get will insist on a rewrite anyway. Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
- onion2k 10y ago
  What happens when the business outgrows what AppBuilder can do? They use AppBuilder 2. The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers. Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
  - scalatohaskell 10y ago
    That's what's been promised for last 30 years :)
    - onion2k 10y ago
      It is, and if you compare the resources needed to build software 30 years ago to the resources we need now it's pretty obvious we've made some incredible advances that will continue to make it possible to build software with even less.
  - Clubber 10y ago
    I mean grow in complexity, not scalability. The crux of the issue, and why all of these type things fail to gain enough coverage to concern me, is business grow in complexity. Each. Individual. Business. Cumulatively it's exponential complexity. These type solutions are general solutions designed as one size fits all. In reality, that usually covers small businesses and for a short period of time. All businesses are niche. Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application. They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
    - 10y ago
- sorenbs 10y ago
  You are underestimating how much of corporate america runs on spreadsheets, email and paper.

by mbesto 10y ago

Clubber 10y ago

What happens when the business outgrows what AppBuilder can do? I would assume that's a ground up rewrite. Seems like it's kicking the issue down the road and accumulating technical debt along the way.

mbesto 10y ago
> What happens when the business outgrows what AppBuilder can do? Then they just find an off-the-shelf solution (SaaS most likely) to replace it. > Seems like it's kicking the issue down the road and accumulating technical debt along the way. If you do a ground-up rewrite or find an off-the-shelf solution then technical debt doesn't matter anyway does it?
- marktangotango 10y ago
  You see this same situation with large and small legacy systems that have reached end of life and need to be replaced. In some since the app or system can serve as the requirement for the replacement, but no one ever sees it that way. Why is the rewrite late? Still waiting for requirements! That running system over there is your requirement! Wait, that old crap? Yes that old crap.
kartickv 10y ago
If App Maker takes an order of magnitude less time than writing the software they want, then it can be low-risk. If something takes a long time and may not work, that's when it's risky.
aryehof 10y ago
Better to build for today, than be consumed with what might be tomorrow
- candiodari 10y ago
  I work in a huge company. Being consumed with what might be tomorrow is taken to an extreme. Given what I hear from other companies, this is very common. Sad part is, it never works. Designs don't ever match up with real world requirements (they match up very well to stated requirements). Anticipated changes never happen, but other changes do, and ... then of course a rewrite is needed, after attempting to get 2-3 unanticipated changes built into the "agile" design. "Technical debt", is the explanation, often without any further clarification. We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants. Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving. The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it. Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
cookiecaper 10y ago
Because it's harder to read code than to write it, most freelancers/contractors a small business would get will insist on a rewrite anyway. Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
onion2k 10y ago
What happens when the business outgrows what AppBuilder can do? They use AppBuilder 2. The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers. Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
- scalatohaskell 10y ago
  That's what's been promised for last 30 years :)
  - onion2k 10y ago
    It is, and if you compare the resources needed to build software 30 years ago to the resources we need now it's pretty obvious we've made some incredible advances that will continue to make it possible to build software with even less.
- Clubber 10y ago
  I mean grow in complexity, not scalability. The crux of the issue, and why all of these type things fail to gain enough coverage to concern me, is business grow in complexity. Each. Individual. Business. Cumulatively it's exponential complexity. These type solutions are general solutions designed as one size fits all. In reality, that usually covers small businesses and for a short period of time. All businesses are niche. Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application. They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
  - 10y ago
sorenbs 10y ago
You are underestimating how much of corporate america runs on spreadsheets, email and paper.