5 ms·

> 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

> 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.

icebraining 7y ago
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)
ehnto 7y ago
> 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.
- TeMPOraL 7y ago
  > 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.
msla 7y ago
Excel is programming. I have to quote rms now, because it's just too perfect: https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html > 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. https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming
- TeMPOraL 7y ago
  > 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.)
wolco 7y ago
Have you tried 'remedy'?

icebraining 7y ago

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)

ehnto 7y ago

> 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.

TeMPOraL 7y ago
> 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.

msla 7y ago

Excel is programming. I have to quote rms now, because it's just too perfect: https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html > 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. https://en.wikipedia.org/wiki/Dataflow_programming https://en.wikipedia.org/wiki/Dataflow_programming

TeMPOraL 7y ago
> 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.)

wolco 7y ago

Have you tried 'remedy'?