11 ms·

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed a

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a well paved road through the woods. If you take a light & narrow wheeled racing bike, you'll travel much much faster than if you ride a knobbly wheeled mountain bike with suspension, as long as you stay on the road. As soon as you need to go off the road and cut a new path, you are going to wish you had that mountain bike, and the road bike is actually going to make you go much slower or just stop altogether. So does the "speed bike"/advanced framework make you go faster? Yes, as long as you stay on the road (i.e. constrain your requirements to their feature set). The moment you need to "go off-road" (i.e. do something the framework doesn't do), such tools actually make it difficult or impossible to make progress. This is why, for a complex applications (most commercial software), I prefer the mountain bike. Yes, it's slower on certain paths, but when we need to "go off-road" I don't slow to a stop.

smhenderson 7y ago
Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible". Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is). I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote! http://www.vb.mvps.org/hardweb/hardbook.htm http://www.vb.mvps.org/hardweb/hardbook.htm
- tabtab 7y ago
  That's often the trade-off of any high-level tool or library. It will make a big chunk of related tasks easier, but won't be able to handle a small subset. Hopefully there are ways to work around the limits.
  - _asummers 7y ago
    The limits of tools only expose themselves when they're being stretched in ways the authors did not intend. Good tools have enough escape hatches to get you by those moments, and the bad ones break down entirely.
    - tabtab 7y ago
      Such tools should have a degree of "hooks" built in so that work-arounds are easier. For example, a ORM should have an operation to send direct SQL to the database for the times it can't generate SQL as intended. And maybe even modify specific clauses if needed so it's not all native or all raw, but something in between. Of course, if it's too open-ended it becomes a hacker's playground, so a happy medium needs to be found.
- JadeNB 7y ago
  > "Visual Basic makes 95% of your task easy and the other 5% impossible". Think what you will of the readability of Perl, but it's hard to beat its motto: "making easy things easy and hard things possible."
  - kevin_thibedeau 7y ago
    VB had access to the entire Win32 API. Nothing was impossible.
    - JadeNB 7y ago
      Per smhenderson (https://news.ycombinator.com/item?id=22038454 https://news.ycombinator.com/item?id=22038454), you'll have to take that up with Bruce McKinney, not me; I merely quoted it to compare.
  - smhenderson 7y ago
    Indeed. When I was finally exposed to Unix (SCO, yuck!) and Linux (Slackware, yay!) it was because I was trying to learn C and wanted free tools because I couldn't afford any commercial stuff at the time. But before I did much with C I became quite proficient with Perl. This really wasn't that long after absorbing all the VB material I could find at the time so it was interesting going from the one to the other, not to mention the OS differences. I still love using Perl 5 today even though it's totally out of style at this point. VB? Not so much! :-)
    - JadeNB 7y ago
      > I still love using Perl 5 today even though it's totally out of style at this point. Same here!
      - smhenderson 7y ago
        I suspect there's more of us than we think!
    - emilper 7y ago
- heelix 7y ago
  Back in the COM days, we were largely a C++ shop. There were times where our business folks did not quite know what they wanted - so we'd prototype the COM component out in VB. It worked a little too well - for about a quarter of the time, you ended up with something that only had a 10% (or less) performance penalty.
- tartoran 7y ago
  I remeber the same argument but it was applied to asp.net webforms, the stateful monster that MS created to usher desktop devs to the web world.. That was a crutch that turned out to be quite bad in the end, lots of new devs that came that route had a problem understanding that the web is a stateless protocol.
AnimalMuppet 7y ago
What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to. And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing to the "real" programming language.
- weiluen 7y ago
  I’ve found that most no code environments that I’ve tried advocate that they have this capability but in practice it’s still nearly impossible to get what I need because their abstractions aren’t at the right level. Not saying this is impossible just that my personal experiences have made me skeptical of this approach.
- asdfman123 7y ago
  I mean, that's pretty much how I program things. I start new web apps with an MVC framework that auto-generates new pages. When I want to do something, I try to use someone else's code as much as possible. If I'm doing a simple, well contained task, someone else has already thought of it and made a library for it. If I need to send an email, I just do something like calling _emailSender.SendEmail(message). Easy peasy. But processing data is complicated and nothing can completely abstract it away.
  - paulie_a 7y ago
    I am a lazy programmer in that way. I'd rather autogenerate and use robust libraries as much as possible.
    - asdfman123 7y ago
      It's not lazy, it's just smart. The less code you write, the better it is.
- spacechild1 7y ago
dlwdlw 7y ago
At certain large tech companies it’s the difference between an all terrain vehicle and laying frikin tracks for a frikin train.
ngoel36 7y ago
Most importantly, by the time you need to go off road, it's too late to switch bikes...
ivanhoe 7y ago
All you've said is 100% true, but in addition I'd argue that a big part of reason why no-code tools don't get more traction is also just the simple power of habit and the lack of motivation to invest time into learning it. We already know how to build things the traditional way, and all these no-code solutions require learning a lot of new, proprietary interfaces and stuff, playing with it and figuring it out, learning to work around the limitations. Many other tools and frameworks that we choose to use have similar, probably even worse problems, but they're popular so one feels like it's worth the trouble to learn them - just to stay in the game. No code tools on the other hand are proprietary, not very popular and the benefits they give you are just not that significant to a seasoned programmer. In all honesty, I never even gave them a chance.
- jeffshek 7y ago
  I don’t have enough experience with no-code tools either, but I don’t agree it’s motivation that prevents it from taking off. No-code is used mostly by non-technical founders who do seem quite motivated (enough to do it themselves). Engineers are more likely to build it themselves (realistically, over-engineer).
  - madeo 7y ago
    Those "non-technical founders" are usually the ones that have "ideas" to build another Facebook and don't want to pay a professional to do it.
leggomylibro 7y ago
We used to make this sort of analogy a lot at a web dev place where I once worked. Eventually it got boiled down to a pithy joke: "Ruby on Rails is great, but only if you stay on the Rails!"
Aperocky 7y ago
The only problem is, it’s actually not a road bike, but a shopping cart. The advertisement is that you can sit and not pedal (when down hill). And it’s not faster in any case.
Rury 7y ago
Reminds me of a similar situation with my technical manager. He’s very dogmatic in that we should never waste time “re-inventing the wheel” (e.g. there’s already a library/tool out there that does X, don’t waste time remaking it). This makes a lot of sense in many business cases, but not always... I like using this analogy to demonstrate why: Say we’re designing a race car, and our race car needs wheels. “Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!” I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!” If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)
- kls 7y ago
  The problem is sometimes you get the converse where developers have the "not invented here" mentality. I interviewed at a shop one time where they had built their own JS framework. Mind you this was a financial shop not a tech shop. They bellied up about 2 years after I interviewed with them and I cannot help but reason that they had "tech gone wild" as one of the reasons. The CEO fashioned his company as the Google of the financial industry but in the end they where a bunch of developers stroking their ego. It is a balancing act, a lot of times building on what exists is the best case but when it comes to your core competency and what distinguishes your business, that is where one should focus their development efforts. If you are rewriting Postgres you will just end up with a shittier database.
  - Rury 7y ago
    Totally agree it's a balancing act. Sometimes the existing tool is exactly what you need, in which it would be a waste to re-invent it. Ideally though, things should be evaluated case by case, rather than sticking to a dogma. I just happen to work at a company that's experienced the flip side of your experience. We ended up wasting millions on software some managers thought fit our needs. However, turns out it really didn't fit our needs after all was said and done, and they said if they had known everything up front (rather than what the salesman had said) they wouldn't have bought the software in the first place.
K0SM0S 7y ago
I think this drives your point with incredible wit: “On The Turing Completeness of PowerPoint (SIGBOVIK)” by Tom Wildenhain[1]. (5 minutes video) [1]: https://youtu.be/uNjxe8ShM-8 https://youtu.be/uNjxe8ShM-8 (Nerding out should always be hilarious like that!) [2]: Recording of a guest lecture he gave for the Esoteric Programming Languages course at CMU. (~1h) https://youtu.be/_3loq22TxSc https://youtu.be/_3loq22TxSc
fossuser 7y ago
The trouble with this analogy is that at some point an ATV comes along that’s much faster both on and off the road, but you’re still clinging to x86 because it’s more powerful than the “high level” languages like C. I generally agree with you, but I also suspect there’s a lot of room to improve the tools and it’s not always obvious when something is a paradigm shift in productivity or a dead end that will only work in tightly constrained use cases.
- ethbro 7y ago
  This is the perfect metaphor and the one I use. Just because we can build a Ferrari doesn't mean that a Ferrari is efficient in all situations. We have race tracks (smooth, evenly surfaced roads), highways (generally smooth roads over long distances), city streets (some potholes), gravel roads, dirt roads, and no-roads. A tank isn't great for a race track. And a Ferrari isn't great for no-road. The author muddles up the question to make their point. What they're really saying is "no-code tools aren't a good fit for general purpose coding" (for all the reasons mentioned). Which seems fair and accurate. But all coding is not general purpose coding.
abstratt 7y ago
Most commercial software is basically information systems, with very standard architectures, and no complexity whatsoever. At least not business-related complexity. Most complexity in those systems is accidental, exactly due to us using the wrong tools for the job (namely, 3GLs + frameworks), which do not provide the proper level of abstraction for the problem at hand. Even for a single system, no one should be forced to use a single level of abstraction everywhere. The game industry has been mixing 3GL code and assembly whenever needed since it moved on from assembly. You don't have to stick to one for everything.

smhenderson 7y ago

Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible". Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is). I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote! http://www.vb.mvps.org/hardweb/hardbook.htm http://www.vb.mvps.org/hardweb/hardbook.htm

tabtab 7y ago
That's often the trade-off of any high-level tool or library. It will make a big chunk of related tasks easier, but won't be able to handle a small subset. Hopefully there are ways to work around the limits.
- _asummers 7y ago
  The limits of tools only expose themselves when they're being stretched in ways the authors did not intend. Good tools have enough escape hatches to get you by those moments, and the bad ones break down entirely.
  - tabtab 7y ago
    Such tools should have a degree of "hooks" built in so that work-arounds are easier. For example, a ORM should have an operation to send direct SQL to the database for the times it can't generate SQL as intended. And maybe even modify specific clauses if needed so it's not all native or all raw, but something in between. Of course, if it's too open-ended it becomes a hacker's playground, so a happy medium needs to be found.
JadeNB 7y ago
> "Visual Basic makes 95% of your task easy and the other 5% impossible". Think what you will of the readability of Perl, but it's hard to beat its motto: "making easy things easy and hard things possible."
- kevin_thibedeau 7y ago
  VB had access to the entire Win32 API. Nothing was impossible.
  - JadeNB 7y ago
    Per smhenderson (https://news.ycombinator.com/item?id=22038454 https://news.ycombinator.com/item?id=22038454), you'll have to take that up with Bruce McKinney, not me; I merely quoted it to compare.
- smhenderson 7y ago
  Indeed. When I was finally exposed to Unix (SCO, yuck!) and Linux (Slackware, yay!) it was because I was trying to learn C and wanted free tools because I couldn't afford any commercial stuff at the time. But before I did much with C I became quite proficient with Perl. This really wasn't that long after absorbing all the VB material I could find at the time so it was interesting going from the one to the other, not to mention the OS differences. I still love using Perl 5 today even though it's totally out of style at this point. VB? Not so much! :-)
  - JadeNB 7y ago
    > I still love using Perl 5 today even though it's totally out of style at this point. Same here!
    - smhenderson 7y ago
      I suspect there's more of us than we think!
  - emilper 7y ago
heelix 7y ago
Back in the COM days, we were largely a C++ shop. There were times where our business folks did not quite know what they wanted - so we'd prototype the COM component out in VB. It worked a little too well - for about a quarter of the time, you ended up with something that only had a 10% (or less) performance penalty.
tartoran 7y ago
I remeber the same argument but it was applied to asp.net webforms, the stateful monster that MS created to usher desktop devs to the web world.. That was a crutch that turned out to be quite bad in the end, lots of new devs that came that route had a problem understanding that the web is a stateless protocol.

AnimalMuppet 7y ago

What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to. And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing to the "real" programming language.

weiluen 7y ago
I’ve found that most no code environments that I’ve tried advocate that they have this capability but in practice it’s still nearly impossible to get what I need because their abstractions aren’t at the right level. Not saying this is impossible just that my personal experiences have made me skeptical of this approach.
asdfman123 7y ago
I mean, that's pretty much how I program things. I start new web apps with an MVC framework that auto-generates new pages. When I want to do something, I try to use someone else's code as much as possible. If I'm doing a simple, well contained task, someone else has already thought of it and made a library for it. If I need to send an email, I just do something like calling _emailSender.SendEmail(message). Easy peasy. But processing data is complicated and nothing can completely abstract it away.
- paulie_a 7y ago
  I am a lazy programmer in that way. I'd rather autogenerate and use robust libraries as much as possible.
  - asdfman123 7y ago
    It's not lazy, it's just smart. The less code you write, the better it is.
spacechild1 7y ago

dlwdlw 7y ago

At certain large tech companies it’s the difference between an all terrain vehicle and laying frikin tracks for a frikin train.

ngoel36 7y ago

Most importantly, by the time you need to go off road, it's too late to switch bikes...

ivanhoe 7y ago

All you've said is 100% true, but in addition I'd argue that a big part of reason why no-code tools don't get more traction is also just the simple power of habit and the lack of motivation to invest time into learning it. We already know how to build things the traditional way, and all these no-code solutions require learning a lot of new, proprietary interfaces and stuff, playing with it and figuring it out, learning to work around the limitations. Many other tools and frameworks that we choose to use have similar, probably even worse problems, but they're popular so one feels like it's worth the trouble to learn them - just to stay in the game. No code tools on the other hand are proprietary, not very popular and the benefits they give you are just not that significant to a seasoned programmer. In all honesty, I never even gave them a chance.

jeffshek 7y ago
I don’t have enough experience with no-code tools either, but I don’t agree it’s motivation that prevents it from taking off. No-code is used mostly by non-technical founders who do seem quite motivated (enough to do it themselves). Engineers are more likely to build it themselves (realistically, over-engineer).
- madeo 7y ago
  Those "non-technical founders" are usually the ones that have "ideas" to build another Facebook and don't want to pay a professional to do it.

leggomylibro 7y ago

We used to make this sort of analogy a lot at a web dev place where I once worked. Eventually it got boiled down to a pithy joke: "Ruby on Rails is great, but only if you stay on the Rails!"

Aperocky 7y ago

The only problem is, it’s actually not a road bike, but a shopping cart. The advertisement is that you can sit and not pedal (when down hill). And it’s not faster in any case.

Rury 7y ago

Reminds me of a similar situation with my technical manager. He’s very dogmatic in that we should never waste time “re-inventing the wheel” (e.g. there’s already a library/tool out there that does X, don’t waste time remaking it). This makes a lot of sense in many business cases, but not always... I like using this analogy to demonstrate why: Say we’re designing a race car, and our race car needs wheels. “Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!” I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!” If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)

kls 7y ago
The problem is sometimes you get the converse where developers have the "not invented here" mentality. I interviewed at a shop one time where they had built their own JS framework. Mind you this was a financial shop not a tech shop. They bellied up about 2 years after I interviewed with them and I cannot help but reason that they had "tech gone wild" as one of the reasons. The CEO fashioned his company as the Google of the financial industry but in the end they where a bunch of developers stroking their ego. It is a balancing act, a lot of times building on what exists is the best case but when it comes to your core competency and what distinguishes your business, that is where one should focus their development efforts. If you are rewriting Postgres you will just end up with a shittier database.
- Rury 7y ago
  Totally agree it's a balancing act. Sometimes the existing tool is exactly what you need, in which it would be a waste to re-invent it. Ideally though, things should be evaluated case by case, rather than sticking to a dogma. I just happen to work at a company that's experienced the flip side of your experience. We ended up wasting millions on software some managers thought fit our needs. However, turns out it really didn't fit our needs after all was said and done, and they said if they had known everything up front (rather than what the salesman had said) they wouldn't have bought the software in the first place.

K0SM0S 7y ago

I think this drives your point with incredible wit: “On The Turing Completeness of PowerPoint (SIGBOVIK)” by Tom Wildenhain[1]. (5 minutes video) [1]: https://youtu.be/uNjxe8ShM-8 https://youtu.be/uNjxe8ShM-8 (Nerding out should always be hilarious like that!) [2]: Recording of a guest lecture he gave for the Esoteric Programming Languages course at CMU. (~1h) https://youtu.be/_3loq22TxSc https://youtu.be/_3loq22TxSc

fossuser 7y ago

The trouble with this analogy is that at some point an ATV comes along that’s much faster both on and off the road, but you’re still clinging to x86 because it’s more powerful than the “high level” languages like C. I generally agree with you, but I also suspect there’s a lot of room to improve the tools and it’s not always obvious when something is a paradigm shift in productivity or a dead end that will only work in tightly constrained use cases.

ethbro 7y ago
This is the perfect metaphor and the one I use. Just because we can build a Ferrari doesn't mean that a Ferrari is efficient in all situations. We have race tracks (smooth, evenly surfaced roads), highways (generally smooth roads over long distances), city streets (some potholes), gravel roads, dirt roads, and no-roads. A tank isn't great for a race track. And a Ferrari isn't great for no-road. The author muddles up the question to make their point. What they're really saying is "no-code tools aren't a good fit for general purpose coding" (for all the reasons mentioned). Which seems fair and accurate. But all coding is not general purpose coding.

abstratt 7y ago

Most commercial software is basically information systems, with very standard architectures, and no complexity whatsoever. At least not business-related complexity. Most complexity in those systems is accidental, exactly due to us using the wrong tools for the job (namely, 3GLs + frameworks), which do not provide the proper level of abstraction for the problem at hand. Even for a single system, no one should be forced to use a single level of abstraction everywhere. The game industry has been mixing 3GL code and assembly whenever needed since it moved on from assembly. You don't have to stick to one for everything.