A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
Here is the story and two question below.
Lets start with a simple example:
There is an imaginary App which gives Users access to two database tables:
Departments(3 columns) and Employees(4 columns), which are related as one-to-many.
We have to create code to service widest set of possible operations upon those Tables: all the Inserts, Selects, Updates and such.
An App must generate generic UI and provide means to do comprehensive generic reporting.
An App has to be multi-client enabled, with real-time clients updates and to keep the Database ACID. Lets say, pessimistic locking is acceptable. Ideally the App collects stats of users activity, means there are some additional tables and roles: at least an admin and a user. And just in case there is API in place to program some custom magic beyond supported generic ops/reports.
Then there is another App, with again 2 Database Tables:
Warehouses(3 columns) and Parts(4 columns).
Requirements stay the same as in App One.
The question is:
is it possible to create code which will serve both Apps
in any given environment? The answer is obvious - it is possible.
Just feed the code the parameters with actual Tables/Columns names. Optionally feed more parameters to customize UIs.
And that code might look like that:
Table1(name)(3 columns[names, types]) -->> Table2(name)(4 columns[names, types])
so essentially a single declarative line + some possible UI mark up.
Now that exercise generates more questions:
what if there are different sets of columns?
what if there are different number of Tables?
what if tables relates in different ways?
where is the border to produce that generic code to serve all?
For many years I was building tools to extend variety of Tables,
their relations and their UIs. I was even trying to market those tools. That is actually another failure story on that Forum. I'll keep it for another time :-).
The point is:
looks like I've built an interpreter to directly execute database schemas, well maybe slightly modified schemas.
It is obvious that same schemas could be expressed in text form or as "boxes-and-lines" diagrams. I do prefer the latest.
So it works like that: as quickly as Visio-like schema[or part of it] is drawn, it is fed to an App server, which instantly gives access to eligible users to those newly generated tables. Further [re]development is possible on already deployed live App - the interpreter allows that.
There is a full set of admin functions to govern a new app and API and other stuff.
There are some limitations - my implementation is not an ideal one(but close :-)).
But again the point is: an App is generated as fast as one draws a schema.
I did a few Line Of Business Apps [50+ tables, pics, PDF, HTML supported], they work fine, it proves the concept.
The First Big Question is: Have I reinvented the wheel?
Some subtle attempts to automate Data relations I've heard about is FileMaker with the concept of a portal. Drop-down lists are another example. Too little, too shy.
Still my interpreter is very generic and can run very generic schemas.
And you would not believe how much imperative SQL could be replaced by a few declarative lines.
The Second Big Question: What do I do know?
It is just not a task for a microSV: too many platforms to deploy to, too much to code.
And I'm a [very]bad marketer in the first place.
OpenSource? Let it go? - I do have another sources of income.
6 months ago I have shut down my "production" server - zero traction syndrome - and took some healing in doing physical work. So that FancyData.com I used to run my servers is offline now - do not blame me for that.
Waiting for your input here,
with respect Alex Semenov.
Sunday, November 03, 2013
I believe you have invented UML
Monday, November 04, 2013
This idea has been around since the dawn of computerdom and it seems like it never really works. I think this is because one of two conditions exist:
1. The business need is so simple that they could just use Excel or something similarly even MORE generic.
2. The business need is complex enough that implementing the many and various rules defies a generic solution. For a while you try to shove increasingly complicated rules into the framework as plug-ins or whatever, but eventually you realize that the framework is more trouble than it's worth.
Maybe this time is different but I doubt it.
+1 to GregT for too-trivial/too-complex analysis.
This is indeed the issue with many of the solutions that claim to work in this way.
I have seen a middle way, where it is easy to make applications that are arbitrarily complex, without reverting to more traditional means (teams of developers, long projects, etc). That was so easy to use that anyone could build anything they needed and start using it right away.
Of course, the difficulty with this is that everyone seems to believe that it won't work, due to inertia and vested interests.
Sorry, was on a business trip, just back.
@Sergey: UML a) is more general then DB schema b) used as supportive diagrams to manually produce source (UML does some limited automated code generation) - my code is prewritten, the schema is interpreted, and it is 100% automated. Although two approaches reside in declarative camp - that's a similarity.
@Greg: "Maybe this time is different but I doubt it"
well, Scorpio put it elegantly:
"difficulty with this is that everyone seems to believe that it won't work, due to inertia and vested interests"
I'm recalling Scorpio has mentioned in the past that magic-development-system, so he has some little bias to beleive it is possible :-)
The proof is there - sources, executable, screens, "how-to" casts - for those who doubts. Greg described in his replay(thank you Greg!) typical approach - it is not possible because it is not. What, should I rent a server again to put all that stuff for observation? Dare me :-) if it makes sense...
The challenge is pretty serious - if somebody declares in the area of my expertise that there is a way to cut my labour time(not very English, sorry) like, in 100 times - that looks pretty desruptive to me. I'd have hard time to ignore it. It could be Heaven or it could be a Hell, right? Like "Hey guys, there is an alien here!" - and that answer back - "Whatever..."
Well, thank you for your time, still have to figure out - whether to do something about it or just to reward myself with a nice icecream sandwich and forget about it...
I'm often away now, so - just in case - it is email@example.com
Nice talking to you guys, later
Tuesday, November 05, 2013
Yes, as I've mentioned here previously, it is certainly possible, as I've created such a system and seen it being used.
I've also seen so-called "professional" developers deliberately sabotage the system, because they were worried that it'd replace them (an example of the vested interests I mentioned). In the end, they did all lose their jobs, as they were fired by the CEO for their clumsy attempt at sabotage, not because they were replaced by the system that I built.
Ironically, the intention was for them to embrace and extent the new way of working, but they were undone by their own fears before they could grasp the big picture.
@Scorpio: how your story is ended? can you share principles on how your system was designed? my similar story 20+ yo:
I led a team of 15 engineers on a classified plant making classified equipment for classified Sukhoys (Su) interceptors. Made a piece of software which could replaced them all - I was fired in my case
:-) - my boss did not want to lose a quorter of his department. Small world.
So no way to move something's not backed by big guys?
Wednesday, November 06, 2013
In my case it was born of necessity, as my client was sick of dealing with incompetent developers who over-promise and under-deliver. I had been hired as a consultant in a different department, but got talking to the CEO and he said he wanted someone to build him a system to run his business on, but it had to be possible for any of his business people to modify it after it went live, so that he wasn't reliant on developers for changes and enhancements.
I had been thinking about the idea of "anyone can build applications" for a long time and was getting more and more convinced that this was the future, so I agreed to build a proof of concept for him, even though everyone in the IT department said it was impossible, etc.
It was an interesting challenge, technically, as it had to be completely generic, to support any "line of business" application that they could dream up. It started as a single system, but as soon as I hinted that it might be possible, the CEO insisted that it be generic enough to support any application, on any platform, that they might need, then and in the future. Many of their existing IT systems were old and needed replacing, so he saw this as a great way to save millions of dollars, by getting his own people to build what they needed, rather than paying outside contractors or hiring more in-house developers.
There was a lot of hostility from the in-house IT people, but I had the full support of the CEO, so I ignored them and just did my job. They were fired anyway, as mentioned above.
The project was a runaway success - way more than I imagined it would be. The business people built a lot of systems with it, with zero time/cost on developers and now support the systems themselves, including managed upgrades, testing, rollouts, etc.
For me, the most interesting aspect of the whole thing was how productive they were. Even with quite rudimentary tools to build applications, they were way more productive than any team of developers I've ever seen in thirty years of working on a lot of cool projects with a lot of very clever people. They built what they needed and started using it much faster than they could describe their requirements in the traditional way, so they saved a lot of time, as well as money. This gave them a real competitive advantage, as they could build something and use it on day one.
Last time I had lunch with the CEO, he said that they planned to run their whole business on it (hundreds of millions of dollars a year) and were retiring all their old legacy systems.
The project was a great success, but even now, when I've proved that it can work, some people still assume I made it all up, or that it could never work, or some other lame excuse why it'd never take off.
In any case, I was well paid for that assignment and pretty much retired, but I do wonder if I should launch a new version of it, as it is certainly very disruptive and would empower a lot of people and potentially save billions of dollars for business and government. It'd certainly be nice to help save the government some money, as it might stop our taxes going up so much.
I agree with Greg.
I have written a number of utilities over the years for helping me on a Visual FoxPro app. They would have been a lot more complex if I had to deal with all of the possible permutations. I wrote them to deal with the straightforward cases. This would not be enough for a product that I sold, but they work fine for me.
Wednesday, November 06, 2013
The idea of building programs which allow you to maintain a database table without the need to write code is not such pie-in-the-sky as some people think. I built my own web development framework 10 years ago which does just that, but not directly from the database schema but indirectly through my custom-built data dictionary. With this framework I can build a standard family of user transactions - List, Create, Read, Update, Delete, Search - in 5 minutes without the need to write *ANY* code. For anything more complicated a developer is needed in order to add extra code into the right place. These user transactions are automatically covered by the framework's Role Based Access Control system so that the administrator can decide which user has access to which transaction, and automatically covered by the audit logging system so that you can track any changes made to the database.
I am not convinced that it is possible for non-developers to build complicated transactions with complex business rules, at least my framework offers a huge amount of standard processing and boilerplate code "out of the box", which leaves the developers with more time to concentrate on the processing of business rules.
I have used this framework to build an Order Processing/Supply Chain Management package which contains over 2,000 transactions and which has been used by live clients for over 5 years, so I am not blowing smoke.
BTW, I released my framework (http://www.radicore.org) as open source over 7 years ago, so you can see it for yourself.
Sunday, November 10, 2013
Thanks for your encouraging post Tony.
I think you may be surprised at what is possible now. I never found any coding construct was too difficult for everyone to understand. Most languages are stylised English anyway, so as long as it is taught in a sensible way, most people get it right away.
I had assumed that it would fall apart when dealing with complex business rules, but I actually found that the business users I worked with enjoyed it, as it gave them a chance to collaborate and really ensure that they all understood it properly. They enjoyed the fact that they just did it, rather than the boring way, where it would be documented, then signed off, then tested, etc.
It almost became like a game at my client sites, where people became competitive about easily they could code up their business rules, however complex and archaic they seemed. Working on the team building the applications even became desirable, so as word spread about how much fun it was, more and more people volunteered to be part of it.
To be honest, I was pleasantly surprised at how easy it was to get the business people to build their own applications. They did all the work and I got all the credit for creating such a fantastic system, even though all I did really was give them a blank canvas and point to the brushes.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz