No-code Software Engineering

  • Comments posted to this topic are about the item No-code Software Engineering

  • Agree, no-code works for me pretty good for last 7 years. I sticked with KNIME free analytical platform.

  • Where do you draw the lines between languages, applications, and tools?  In the SQL realm imo Redgate, Quest, etc. are "no code software" tools.  The output (if used properly) is faster-to-write/higher quality code versus what you could do otherwise.  Tools like Redgate Compare (we use Apex Diff) have saved countless hours of high-level toil.  Imo the lines get crossed and the whole approach goes downhill when the tools are inappropriately generalized.   In IT there are 2 great eternal myths (which are related to each other like 2 sides of a coin): 1) the computer/server which is so fast it makes inefficient code sufficient for production, and 2) the database which is so smart (or simple) dumb people can use it effectively.  Countless software products have come and gone which appeal to one or both of those myths.  NoSQL falls in this negative category.  ORM/Entity Framework also fall within the negative category imo.

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • Some thoughts on the subject.

    Axiomatic reuse. Software methods that apply to all possible applications. The relational model replaced every application needing to devise its own approach to data management.

    Application derivation. Code generation always leads to discrepancies between components. Derivation always keeps everything in step - an interface that is derived from the database metadata will adjust automatically to changes in the database structure.

    Relational programming. All functions are relations, not all relations are functions. Functional programmers could drop the other foot. Functional programming, plus is a function  1+5 = 6

    Relational programming, plus is a predicate 1+? = 6 returns 5 (making minus redundant), ?+?=5 returns {(1,4), (2,3), (0, 5)}

    Remove syntactic redundancy "select * from sales" is replaced with "sales" - the "select", "*" and "from" are all syntactically redundant.

  • Low code/no code really interests me. I like Richard Campbell's quote, "Ignore them [low code/no code] at your own peril". I believe there's a lot of truth there.

    The proponents I've seen for low code/no code encourages allowing the "citizen developer" to write low code/no code applications. They are the domain experts. They understand the problem. Under normal business practice the domain expert (user) has to explain the system to the developer (me). But if the citizen developer is allowed to develop a low code/no code solution, that frees up the developer to focus upon harder problems that low code/no code isn't appropriate for.

    Of course, I'm not saying that all non-developers or IT people must be given low code/no code tools to work with. Instead see who has the aptitude for developing low code/no code applications, show them how to use the tool(s), then let them solve some of their own problems. It's been my experience that the percentage of people who really want to use something now called low code/no code, is small. The majority of people just don't have the aptitude nor desire to write something that's low code/no code. Which is fine. But those who want to, let them have at it.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • The proponents I've seen for low code/no code encourages allowing the "citizen developer" to write low code/no code applications. They are the domain experts. They understand the problem. Under normal business practice the domain expert (user) has to explain the system to the developer (me). But if the citizen developer is allowed to develop a low code/no code solution, that frees up the developer to focus upon harder problems that low code/no code isn't appropriate for.

    Maybe we need to start thinking of the development process as an enabling one. The developers provide the necessary tools for business users to do as much of the work as possible in as flexible a way as they need.

    Perhaps this way we can maintain order and integration while providing as much self service as possible.

     

     

  • I worked for a documentation company that used Content Management Systems to build web sites.

    The vendor documentation was so poor we ended up overusing the component that allowed us to write traditional code and wrote a lot of stored procedures to interact with the underlying database.

    As developers we chaffed against the restrictions by what we perceived to be the limitations of the CMS.

    Our bespoke code ran 6x faster than the inbuilt equivalent. At the time I was proud of that. Looking back we'd made it go 30x faster than it needed to. What we had done was of no benefit other than to our egos.

    We eventually found there was a CMS way of thinking and a CMS way of doing everything our bespoke code did. Our 1st project took 9 months to deliver. Our 2nd took 6 weeks. The 2nd project was also much bigger. The difference was purely in ceasing to fight the intended way of doing CMS work.

    I think developers will always chaffe against frameworks though they are doomed to spawn more of them.

    I've seen our CMS mistakes made with various ETL tools, web frameworks, ORMs. Don't fight the tools, learn how to use them.

    Optimizing stuff is good and the running costs might be lower. Just make sure your business considers that optimization worth it.

  • I remember using an early RDBMS called Interel from Honeywell Bull. Never seemed to scale beyond single user.

  • will 58232 wrote:

    The proponents I've seen for low code/no code encourages allowing the "citizen developer" to write low code/no code applications. They are the domain experts. They understand the problem. Under normal business practice the domain expert (user) has to explain the system to the developer (me). But if the citizen developer is allowed to develop a low code/no code solution, that frees up the developer to focus upon harder problems that low code/no code isn't appropriate for.

    Maybe we need to start thinking of the development process as an enabling one. The developers provide the necessary tools for business users to do as much of the work as possible in as flexible a way as they need.

    Perhaps this way we can maintain order and integration while providing as much self service as possible.

    I like your suggestion. It enables collaboration with our co-workers as well as helping IT to know what's going on in "shadow IT".

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I like no/low code tools, like Power BI and others. Let some people start to solve problems, and when they find them working, take what they did and improve it or tweak it to avoid issues. Lots of things like Power BI, Access, etc. can work well, if they're tuned for the work. I'd like to see more developers ensure they learn how to use tools and then also help others improve the way they use the tools.

  • I think there are two topics here:

    1. Low code / no code development.

    2. Citizen developers.

    As Steve says, there is plenty of mundane, plumbing-type code that should be simplified and "black boxed" where possible, making developers more productive and not even taking up room in the business logic.  Everyone should be in favor of this.

    Citizen developers are more controversial.  Professional developers resent and disrespect them, because their solutions are often narrow and not scalable.  On the other hand, their results might still fit the business requirement and get there faster than going through official IT.  If we fight them too much, we lose.

    A tool that gives a "good enough" solution quickly is a good tool, especially when maintainability is not the top driver.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply