May 1, 2021 at 12:00 am
Comments posted to this topic are about the item No-code Software Engineering
May 1, 2021 at 11:22 am
Agree, no-code works for me pretty good for last 7 years. I sticked with KNIME free analytical platform.
May 1, 2021 at 2:50 pm
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
May 2, 2021 at 7:35 am
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.
May 2, 2021 at 2:29 pm
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.
May 2, 2021 at 5:18 pm
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.
May 2, 2021 at 5:56 pm
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.
May 2, 2021 at 7:23 pm
I remember using an early RDBMS called Interel from Honeywell Bull. Never seemed to scale beyond single user.
May 3, 2021 at 2:40 pm
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.
May 3, 2021 at 3:18 pm
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.
May 5, 2021 at 7:48 pm
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.
May 20, 2021 at 2:06 pm
I've seen our CMS mistakes made with various ETL tools, web frameworks, ORMs. Don't fight the tools, learn how to use them.
Fighting the tools is futile in most cases I agree. However, ORM is a strange case. ORM = "Object Relational Mapping". Why is such a mapping necessary? Imo the practical reasons for its existence are due to old language/framework omissions and constraints which don't exist anymore. Those omissions were talked about at the time as limiting factors to automating data access. At least that's my perception.
Suppose there were a new framework built on the ABSENCE of omissions. How would it compare to existing solutions? Imo it wouldn't compare at all. If it existed it would be as a counterexample to existing ORM approaches. A counterexample doesn't need an explanation. If it works then q.e.d.
What are the constraints/omissions which have been addressed? There were big ones. First, the database (SQL Server) could only recognize its own native data types. This was first addressed with XML in 2012. Then in 2016 JSON was added. Every major application platform currently being used (iPhone, Android, Windows) JSON is the first rank data interchange format. Two, server code (C#/VB etc.) could not programmatically access route value information from data requests. In the .NET (Full) Framework if a request is received from the URL "https://someserver.somedomain.xyz/5/123/details?this=26&that=string&date=12-43/4730" (goofy invalid date) the only way to get the components would be to assign them to variable(s) which would be readable within the context of a Controller. So to automate the delivery of data services would (theoretically) REQUIRE type conversions between (two ways) application (JSON) and database (nvarchar) as well as REQURE the explicit assignment of request URL components to Method variables (or write a parser yourself). There were other issues too. Prior to about 2014 there was no native SQL Server type library for C#. There was a warning on Microsoft's website for developers not to convert SQL Server integers into CLR int32's without considering NULL values in your program. The warning was there for like 15 years.
How could a system that actually makes sense work? If SQL Server is capable of reading/writing JSON then (for many requests) there's no reason for (de)serialization and type conversion on the inbound/outbound request(s)/response(s). This could be completely automated by just letting SQL Server handle JSON. If .NET Core MVC makes request route values available as a "pre-parsed" dictionary object, then all of the possible inputs to any request could be serialized automatically and routed to SQL Server. All inputs possible (headers, route values, and message body) could be sent as early as possible and with as few type conversions as possible (zero) to a SQL Server stored procedure designed to receive JSON and return JSON using a standardized set of input/output variables.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
May 20, 2021 at 6:36 pm
How could a system that actually makes sense work? If SQL Server is capable of reading/writing JSON then (for many requests) there's no reason for (de)serialization and type conversion on the inbound/outbound request(s)/response(s). This could be completely automated by just letting SQL Server handle JSON. If .NET Core MVC makes request route values available as a "pre-parsed" dictionary object, then all of the possible inputs to any request could be serialized automatically and routed to SQL Server. All inputs possible (headers, route values, and message body) could be sent as early as possible and with as few type conversions as possible (zero) to a SQL Server stored procedure designed to receive JSON and return JSON using a standardized set of input/output variables.
The issue isn't so much that SQL server can't parse and format json it's that the data is represented in fundamentally different ways. And what your translation layer is supposed to be doing is interfacing between the two.
May 20, 2021 at 8:32 pm
The issue isn't so much that SQL server can't parse and format json it's that the data is represented in fundamentally different ways. And what your translation layer is supposed to be doing is interfacing between the two.
For reasons already stated I disagree. The type library exists. the SQL language extensions exist, and the .NET pipeline routing exists so that in most cases an "object relational mapping" is completely unnecessary.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
May 20, 2021 at 8:49 pm
The issue isn't so much that SQL server can't parse and format json it's that the data is represented in fundamentally different ways.
In which case why bother with JSON? Isn't representing the data in two different ways creating redundancy and therefore potential inconsistencies?
Wasn't overcoming the limitations of hierarchical representations like JSON, XML or in the old days IBM's hierarchical DBMS IMS one of the most important reasons that the relational model exists?
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply