

Ask HN: Seeking Comments: Holy Grail of Software  - srid68

I have created a test of my below Hypothesis @ www.arshu.com. Please note it is 0.1 version and
tested using Firefox only. Download if have .NET to run the whole site in your PC.<p>Hypothesis :<p>Complex software has to be done by assembling reusable components to have the following advantage. 1) High Productivity 2) High Flexibility/Changeability 3) Low Cost. This is how other Industries have managed complexity/productive and cost. Even Fast Food industries like KFC etc, assemble food instead of making food.<p>This is not my original thought, but I found this approach has been discussed even in mainframe era. I consider this as the Holy Grail of Software.<p>Loose Coupling/SOA/Struts/Spring/Dependency Injection are various approaches to acheive the above. I have seen Mashups/Popfly/SharePoint WebParts Framework implementing this type of approach even though it is not fully separating assembly and coding.<p>In connection with testing the above Hypothesis, I started working on a Framework where I can clearly separate Assembly and coding.<p>I have recently started work on mini ERP like workflow and document management product for Architecture Industry and going to use this Framework to really find the benefit.<p>In the mean time I would like to hear any comments from others. Do you think this Hypothesis is valid. Have you come across any other way to separate assembly and coding.
======
michael_dorfman
The "Holy Grail of Software" is an illusion. Sorry to burst your bubble.

How are you distinguishing "coding" from "assembly"? What is code, if not a
series of instructions assmbled together in a sequence? What is the assembly
of components, if not writing code using designated primitives?

Turing showed that it's possible to write almost anything with a tiny number
of primitives. If you have some kind of means of combination and means of
abstraction built into your language, you can generate new objects from the
primitives, which can then be combined and abstracted, ad infinitum.

In other words: you're doing nothing new.

The problem you are going to run into is that there is no magic set of
components which will meet all needs for all purposes, at the appropriate
level of abstraction.

If you want to build a Domain Specific Language for creating ERP systems, more
power to you. That's a worthwhile project.

But don't go mistaking that for "the Holy Grail of Software".

~~~
srid68
Agreed it is a illusion till date.

When Ford what to separate assembly from manufacture every one critized it but
today that is the method used by major industries.

Why is software still not done like that. Why we mix assembly and coding. Why
can these two things be separate and distinct steps. Since this is a
fundamental problem which has still eluded for so long, which is why i call
this as the Holy Grail of Software.

I am not tring to create a magical components as the building blocks for
creating any software, if that is the case the binary number 0 and 1 is
currently used to build everything in software.

I am just saying that separating assembly from coding cleanly similiar to how
assembly of a car is different from the manufacture of components of a car,
then we will be able to achieve high productivity/high flexibility and lower
cost.

This is a hypothesis, it can be used for doing a ERP type of system or even a
single web page. It does not matter.

My question is not whether it is a illusion since i have achieved clean
separation, but will there be a benefit if this hypothesis can be implemented.

~~~
michael_dorfman
You're still not getting it.

You constructed a set of components, and are now assembling them together to
create an application.

That's great, as long as all of the functionality that you want to include in
the application is exposed in the components, in a way that is intuitive to
assemble, and flexible enough to handle future changes/debugging.

The car analogy is not appropriate; once you create all of the components of a
car, you can make as many instances of that particular car as you like. But
only that car. You can't reassemble them to make, say, a pick-up truck, or an
airplane.

If you want to create a bunch of applications that are all very similar, and
only superficially different, you can create a Domain Specific Language. And
it appears that that is what you have done. But this is different than a
General Purpose Language, and there still will likely be times when you need
to go back and create new components, so the separation between coding and
assembly is far from pure.

Just out of curiosity, where did you study Computer Science?

~~~
srid68
Sorry I am a Mechanical Engineer.

You are right that is similiar to a Domain Specific language without any
Domain dependency. It is basically a simple language of assembly which can be
used to build complex software as long as you have components.

Regarding my analogy of a Car which i illustrated to show having assembly as
part of product development is how they have handled complexity of the car
manufacture and this has been followed by every industry other than software.

When a specific product is development, specifically to handle complexity and
productivity, other industries separate manufacturing of components from
assembly and assemble to create a finished product. Here assembly and
manufacture is different and can be done by separate teams/companies without
any problem even when both are clearly dependent.

In software this is still not the case. I have handled Outsources
teams/Insourced teams for development of enterprise software and allways found
it is not easy even when my projects have been very successfull. Basically it
involved too tight control and sleepless nights. That is why I have to still
learn and code instead of concentrating on managing projects like typical
project managers.

If we split software development into software assembly and software coding, i
thought i should have higher order of productivity and separate domain from
code. Any way i will try this on a new project and find out whether it works.
May be or May be not.

Anyway thanks for your comments.

------
icey
Charles Simonyi (the guy that caused us all to use Hungarian Notation in the
90s) seems to think it's a big deal:

<http://www.intentsoft.com/>

Martin Fowler on the subject:
<http://martinfowler.com/bliki/IntentionalSoftware.html>

And a wikipedia entry on the concept:
<http://en.wikipedia.org/wiki/Intentional_programming>

It's certainly an interesting approach, but there will always be edge cases...
How will you handle them?

~~~
srid68
From my research in Software Factory/Domain Specific Languages/Frameworks i
crystalized certain rules for assembly and the funny thing is it is simple and
not domain specific and should be implementable in any language.

Rule 1 - Define a context - Give it a name Rule 2 - Add Components into that
context Rule 3 - Configure those Components in that context Rule 4 - Link
those Components in that context

If i create a assembly framework which understand the above 4 simple rules, i
should be able to assemble components into applications thereby separating
assembly from coding.

Assembling components implicitly gives meaning (domain) functionality to an
application where the components may be generic or specific and can be rewired
to give different meaning.

The edge cases will be that the components are very specific for a very narrow
functional area which is like a single large component. Even in these case, no
component is standalone and can provide all the functionality, even specific
components will need to link to generic components to provide all the desired
funtionality.

To prove to myself this is possible is why I created my website www.arshu.com
using an assembled approach. If you visit my site and move the cursor to the
top right hand site [red mark] of a page, i will tell you how many components
this page uses, how many properties is being set and how many links i am
creating.

Thanks for the links

------
mbrubeck
Your "Holy Grail" is what Fred Brooks called a "Silver Bullet":

<http://en.wikipedia.org/wiki/No_Silver_Bullet>

~~~
srid68
I have seen this before and this is what i have tried to solve. Cannot today
say i am successfully but I can see some light.

As Fred Brooks noted Software has to be Organically grown through Incremental
development.

Currently this leads to most software becoming a Ball of Mud through
continuous change/fixes.

It is allready well established that loose coupling between components will
lead to better systems, then it means that no coupling will also lead to
better but useless systems since a single component may not have all the
features required.

If I can take the coupling and abstract it out from the component, then i
should be able to build a framework which uses a meta data of coupling to
create useful functionality from zero coupled components.

This way i can grow the complexity of the component organically and replace
components.

This is what I have achieved using my experimental rudimentary framework by
taking a simple domain as a web page, but hoping to extend it for building a
new contract job work which involves building our own simple document
management system/simple workflow management system for the Architecture firm.

My question is why is tough? sorry for being Naive.

Then how

