4 ms·

The dream came true. In a modern non-software startup environment people often write code only as a last resort. I regularly see BizDev people setting up new bu

The dream came true. In a modern non-software startup environment people often write code only as a last resort. I regularly see BizDev people setting up new business process automations with services like Zapier, Jira, Zoho, AutoPilot etc. There are plenty of CMS systems, customizable BPM, CRM, ERP etc where you can define UI and logic without writing a line of code and it just works. The cost reduction compared to the traditional coding is tremendous and enables small IT teams to run quite sophisticated businesses. Developers usually don’t see this, locked within their code-based programming paradigm, but this is already real.

fsloth 6y ago
Thanks for this! You are quite right. For the space that is dominated by "CRUD" apps there are quite a lot of alternative implementation pathways than pure coding. And as most of the business value lives between the UI and the database, I understand why there is no driving incentive to create similar high quality tools for numerical, data intensive programming tasks that run on the customers desktop. We work in a niche, hence must be self sufficient.
- wiz21c 6y ago
  IMHO, the business value lies in the data and the way they are structured. The user interface is important to the users, but the data are what make the business run longer than its users. Basically, without the data you can't provide the service; or worse, with bad quality data, you can't provide a good service. I've spent (in bizdev, e-gov) tons of time figuring out badly structured data, fixing data quality issues, handling tons of administrative tasks to access sensitive data, etc. I think it's up to a point where the structure of the databases actually influence the structure of the government. That's because nowadays, the databases and the business rules they embody are so complex that even the civil servants tend to forget how they work.
  - FeepingCreature 6y ago
    Sounds like a version of Conway's Law: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." The assumption was that the communications structure would come first and then the design would imitate it, but with really ossified hard-to-change systems it seems plausible that the departmental organization would shape around it.
  - TeMPOraL 6y ago
    > but the data are what make the business run longer than its users. How often is that the case these days, though? Currently, when I subscribe to a service or buy a product tied to a service, I feel there's a 50/50 chance the company will shut down the service (or itself) while I'm still using it.
zelphirkalt 6y ago
Let me tell you, mostly these solutions suck. There are several reasons for this: (1) leaky abstraction, (2) not the correct abstraction, which works in all envisioned cases without limiting you, (3) often you do not want to only use an API, but instead change a tiny thing and that needs code or accept limitations (4) the existing API is weird or has a weirdly structured result (5) it is inefficient (6) you depend on a third party (7) you might have some rate limits, and probably more reasons. If you got capable developers, let them do their job and create a flexible (expecting changes, simple design, usually not an elaborate many classes design) solution, that actually fits your situation. Developers are (should be) abstractions specialists. They should be able to find working ones in most cases. Or live with limitations and the spread of thinking, that some things are not possible in various appartments. Mental barriers, that stop creative thinking, simply, because the tools do not exist.
- arethuza 6y ago
  "mostly these solutions suck" I think that's a bit harsh - a lot of these tools can be pretty powerful if they are used for the kinds of tasks that they are well suited for. However, stray into a task that is just that bit more complex than what they are good for and they can be an utter nightmare. Of course, deciding whether a particular task is a good fit for a particular tool can itself be a tricky question.
- ivan_gammel 6y ago
  Well, as a software engineer who wrote first line of code in 1991 and as a CTO of a medium sized company I would disagree here. These solutions do not suck. They work, they are cheap and they are efficient in addressing the business needs. You don’t always need a developer for simple automation, just like you don’t need a computer to calculate 2+2. Abstraction leaks, third party solutions and other things you mention are not the problems that always need a solution. Developers often overthink scalability and invest time in perfection of a code which will become obsolete in a year or two because of the change in the business model. It is there you can find the art of engineering: in finding the right problem to solve, rather than working on the problem for which you know a conventional solution. Zapier is unconventional, but it takes 30 minutes there for something that a development team would require a week or two. The limitations do exist, but it often takes some courage to understand that in your specific case you can ignore them.
collyw 6y ago
It was excel a decade ago,and those only work well up to a point.
- ivan_gammel 6y ago
  It’s still there together with the Google Spreadsheets. And that point is quite high :)
  - collyw 6y ago
    I guess viewing the point as quite high is pretty subjective. Plenty of important business practices rely on them, so in that sense you are correct.

fsloth 6y ago

Thanks for this! You are quite right. For the space that is dominated by "CRUD" apps there are quite a lot of alternative implementation pathways than pure coding. And as most of the business value lives between the UI and the database, I understand why there is no driving incentive to create similar high quality tools for numerical, data intensive programming tasks that run on the customers desktop. We work in a niche, hence must be self sufficient.

wiz21c 6y ago
IMHO, the business value lies in the data and the way they are structured. The user interface is important to the users, but the data are what make the business run longer than its users. Basically, without the data you can't provide the service; or worse, with bad quality data, you can't provide a good service. I've spent (in bizdev, e-gov) tons of time figuring out badly structured data, fixing data quality issues, handling tons of administrative tasks to access sensitive data, etc. I think it's up to a point where the structure of the databases actually influence the structure of the government. That's because nowadays, the databases and the business rules they embody are so complex that even the civil servants tend to forget how they work.
- FeepingCreature 6y ago
  Sounds like a version of Conway's Law: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." The assumption was that the communications structure would come first and then the design would imitate it, but with really ossified hard-to-change systems it seems plausible that the departmental organization would shape around it.
- TeMPOraL 6y ago
  > but the data are what make the business run longer than its users. How often is that the case these days, though? Currently, when I subscribe to a service or buy a product tied to a service, I feel there's a 50/50 chance the company will shut down the service (or itself) while I'm still using it.

zelphirkalt 6y ago

Let me tell you, mostly these solutions suck. There are several reasons for this: (1) leaky abstraction, (2) not the correct abstraction, which works in all envisioned cases without limiting you, (3) often you do not want to only use an API, but instead change a tiny thing and that needs code or accept limitations (4) the existing API is weird or has a weirdly structured result (5) it is inefficient (6) you depend on a third party (7) you might have some rate limits, and probably more reasons. If you got capable developers, let them do their job and create a flexible (expecting changes, simple design, usually not an elaborate many classes design) solution, that actually fits your situation. Developers are (should be) abstractions specialists. They should be able to find working ones in most cases. Or live with limitations and the spread of thinking, that some things are not possible in various appartments. Mental barriers, that stop creative thinking, simply, because the tools do not exist.

arethuza 6y ago
"mostly these solutions suck" I think that's a bit harsh - a lot of these tools can be pretty powerful if they are used for the kinds of tasks that they are well suited for. However, stray into a task that is just that bit more complex than what they are good for and they can be an utter nightmare. Of course, deciding whether a particular task is a good fit for a particular tool can itself be a tricky question.
ivan_gammel 6y ago
Well, as a software engineer who wrote first line of code in 1991 and as a CTO of a medium sized company I would disagree here. These solutions do not suck. They work, they are cheap and they are efficient in addressing the business needs. You don’t always need a developer for simple automation, just like you don’t need a computer to calculate 2+2. Abstraction leaks, third party solutions and other things you mention are not the problems that always need a solution. Developers often overthink scalability and invest time in perfection of a code which will become obsolete in a year or two because of the change in the business model. It is there you can find the art of engineering: in finding the right problem to solve, rather than working on the problem for which you know a conventional solution. Zapier is unconventional, but it takes 30 minutes there for something that a development team would require a week or two. The limitations do exist, but it often takes some courage to understand that in your specific case you can ignore them.

collyw 6y ago

It was excel a decade ago,and those only work well up to a point.

ivan_gammel 6y ago
It’s still there together with the Google Spreadsheets. And that point is quite high :)
- collyw 6y ago
  I guess viewing the point as quite high is pretty subjective. Plenty of important business practices rely on them, so in that sense you are correct.