The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Designing software equipped with intelligence

I developed a Ticketing and Reporting program for a government department a year back and it worked till date. Now the department is desiring some changes in such a way that I cannot modify the previous program. I need to write it from scratch. The officers asked me if I can make the new version in a dynamic manner so that it can be modified by the officers themselves as the change is required.

I am puzzled on how to design this new version when, neither I nor the officers of the department, know what type of need would arise after a year or so. They want the modifications in such a way that the program need not be re-written, but it can be customized at the front-end level.

I read an article on Oracle Magazine that discussed about Oracle Applications with Business Intelligence. Oracle claims that their applications can manage future business needs with intelligence. How this can be done when, in my case, there is no clear description on what can be changed and needed?

RK Send private email
Tuesday, July 04, 2006
Sounds like they want a scripting language of some sort. Look into LUA...
Tuesday, July 04, 2006
One of the principles I tell people is, if you can't do it, you can't program a computer to do it.

Thus, designing software to handle an undefined future is at best a crap-shoot, and at worst a prescription for failure.
Tuesday, July 04, 2006
"Oracle claims that their applications can manage future business needs with intelligence."

Well, now THERE'S a surprise!
NetFreak Send private email
Tuesday, July 04, 2006
Oracle once claimed that their database is unbreakable.
Tuesday, July 04, 2006
I know people make all sorts of wild-assed claims, but I had no idea that people actually believed that Oracle meant that they ship a database server that includes a sentient AI component running on a desktop PC when they use the term "Business Intelligence".

Tuesday, July 04, 2006
Well this is a bit of a tall order.

Might the business rules change?
Might they need to add extra fields to database entities?
Might they need to change reports?

It is very hard to accommodate unforeseen architectural changes, such as going from a desktop app with 10 users to web-based with 100 users or going from English to a multilingual application.

Some programs take a modular approach so that hopefully the more volatile components can be swapped out.
An example of this might be tax calculation.

Business rules can be scripted e.g with BPEL.

Extra fields can be added using metadata defined in XML.

If reports are written in MS Access then end users may be able to change these themselves.

I once worked for a company who created a nice domain specific scripting language with the expectation that the end customers would do their own customisation.
In actual fact this never occurred for several reasons.
1) Most end users are not good script programmers
2) You need a good understanding of an application prior to implementing a change
3) Applications need to be tested - unit testing can help here
4) Customers often have difficulty translating their high level "arm waving" requirements to a lower more detailed level.
5) And perhaps most importantly many feature change requests impact the entire system from end to end
> new configuration fields
> new database fields or tables
> new messages in a protocol
> new business logic
> new or modified reports

Be very careful that you don't end up implementing the mother of all frameworks in anticipation of some future change that may or may not happen.
Colin Sanson Send private email
Tuesday, July 04, 2006
Wednesday, July 05, 2006
Maybe a dynamic domain model is what you need.
You should read about this, it's not an easy way to go, but it's very flexible.
BT Send private email
Wednesday, July 05, 2006
You could investigate a Rule Engine (there is at least a free Java version, start from and google around a bit) for the core (logic) part of your application.

But I have to agree with most other posters: the idea of having an application which can be *maintained* by non-developers is pure fantasy.

In the past, COBOL, DBASE, 4GLs, Excel, Access, have been touted as (or have been transmogrified into) something allowing non-developers to automate their jobs.

In reality, the moment you move outside the "simplistic CRUD functionalities" area, you need to involve someone with development skills.

You really risk developing a lot of extra features/flexibility that will end up not being used at all, or requiring extra effort to mantain in the future.
Paolo Marino Send private email
Wednesday, July 05, 2006
You might look at the Adaptive Object-Model approach  I've gone the
route and it's been non-stop fun.  However, Not everyone
is wild about the concept and view AOM as a form of EAV
(Entity-Attribute-Value) see

good luck
Dan S Send private email
Wednesday, July 05, 2006
Now, Extreme Programming would apply the YAGNI principle -- You Ain't Gonna Need It.  By which they mean, implement the simplist solution that works for you now.  Too much focus on all the possible alternatives that COULD exist in the future results in a lot of code created that then never gets used.

This does not mean to ignore the lessons you've learned.  If you can in some way parameterize the issues that have led you to re-create your existing solution, so in the future your user "only" has to edit some configuration file to add fields, or add data elements, then go for it.

Just don't let them treat you as a magic wand.  Software Engineering can never be as simple as waving your wand and giving the magic incantation to achieve results.
Wednesday, July 05, 2006
I wonder if the new request to allow field officers to modify the application is an over-reaction to the need to rewrite the application from scratch on the part of the developer. Assuming the business domain is the same and the changes are evolutionary in nature, I suggest looking at how the application is structured and how it could be changed in the rewrite so the next time the same sorts of changes are needed, the application doesn't need to be rewritten. This is probably closer to a happy medium between the two extremes presented.

Things to look at are good separation of concerns between different layers in the application (business model and presentation) and different objects in each layer. Also, creating a DSL (domain specific language) to script the application can be helpful, even if it's not used by the end user. It can make development go faster, changes easier to implement and makes you think about what should be in the core engine and what can be abstracted out into a script.

Hope this helps.
Harley Pebley Send private email
Wednesday, July 05, 2006
>>Now, Extreme Programming would apply the YAGNI principle -- You Ain't Gonna Need It.

I know that developer's reaction to any change request is thinking in terms of code. That is, an application is a collection of procedures and variables (events and methods are only a different way to name procedures for my point)

Being in BI stimulates you to think differently. What counts most in BI is providing a sensible infrastructure to the user, and you'll never know how it will be used when users will build their reports against it. Modern reporting tools work well in this way.

So is the case of this post. What should be provided to the users is a framework of workflow management. BPEL for Oracle or Windows Workflow Foundations can provide it. The application should provide a mimic with process single steps. The application itself should be fragmented in many elementary applications all governed by a workflow framework
Sevenoaks Send private email
Thursday, July 06, 2006
Their request is ridiculous. Tell them that you cannot forecast the future, so make them specify in detail the exact behavior that they are looking for in this new program.
Thursday, July 06, 2006
==>The officers asked me if I can make the new version in a dynamic manner so that it can be modified by the officers themselves as the change is required.

To dream ... The Impossible Dream ...

Seriously, I've been involved in 3 such projects in one way or another over the last 15 years. All 3 were total, complete, and miserable failures -- despite loud, vocal, and documented protests on my part.

Something like this just can't be done to any reasonable satisfaction of their expectations of "can be modified". Essentially, each such system I was involved in got so mired down in the complications of configuration that, sure it could be easily modified with some config files, but it took a programmer to *understand* all of the configuration options as well as understanding the bastardized scripting/macro language that resulted from these abominations.

Ptui. I spit on your "can be modified by ... themselves". It's been years and it still leaves a bad taste in my mouth.

How come no one talks to the cardiologist and says: " Sure Doc -- I understand you have to build a new pacemaker and install it in my chest and all that, but ... couldja make it so I can change the settings on it when I need to ... maybe just a tune-up here and there that I can do myself"

It's always us computer guys who get shafted this way. No other professional that I know of has to put up with this kind of crap.
Thursday, July 06, 2006
+1 Sgt. Sausage

It took me a while, but I eventually realized that the logical outcome of this process is either a Domain-specific programming language or a general purpose programming language. In either case, it probably takes a programmer to run it, so why not just stick with the language you already have?

I admit that it is tantalizing. One of the biggest benefits to my now having another programmer to work with is that he helps warn me against the 'over normalisation' that leads the the development of an RDBMS system inside SQL Server :)
Ron Porter Send private email
Friday, July 07, 2006
+1 for Sgt Sausage, again.

I've been involved in this kind of thing twice.  Both times, the 'user modifiable' parts of the app scare the users so much we had/have to do the work for them anyway.

At my last job, we were requested to build a 'flexible' docketing system to allow the clients to update and change system functions by themselves.  Building it to do what they wanted took about 18 man-months that ended in a death march.  Only ONE employee at two clients (out of 600+) ever learned enough about how it worked to do anything without help.  When she retired, they brought her back at consultant rates to do the work.  Smart girl - training current staff was a separate, higher rate activity.

My current employer's product has 2 DSLs in it that allow the system to really dance with data & presentation.  Not surprisingly, we have a fairly sizable staff dedicated to configuring & modifying client systems.  Very few client staff want to know how to do anything with the languages; they want us available to blame.

If you really want to take this on, you should do it understanding that someone other than the designated 'officers' will most likely end up doing the configuration work anyway.  Or you can get some consulting money training the never-ending stream of new employees on how to configure the thing ;-).
a former big-fiver Send private email
Friday, July 07, 2006
This is really a business problem. Your clients probably do not want to keep a programmer around to make the changes as needed. And they probably do not want to pay a consultant to make the changes as needed, either. They want someone to implement this "user friendly" configurable interface that allows them to tinker themselves, and then the programmer disappears and stops billing them.

This is a fairly common desire. I've worked with quite a few organizations that think that "a simple config" can keep the programmer away, can be sufficient to adapt to changing circumstances, and is straightforward enough to allow an end user to "repurpose" the system. And they think you're holding back when you don't give them what they think they want.

As pointed out, there are two basic paths to take to accomodate them: 1) develop a grandiose shell that does what the client wants - which will never really be complete - which will take a programmer to control it anyway. Or 2) expose programming languages to them.

Either way, they'll be back and it will cost 5X or more what a hard coded system would cost.
Bored Bystander Send private email
Saturday, July 08, 2006

> It took me a while, but I eventually realized that the
> logical outcome of this process is either a
> Domain-specific programming language or a general purpose
> programming language.

What a great idea!
Obviously, we're all using a general purpose programming language to develop all sorts of apps for all sorts of businesses.

Your mention of a "domain-specific" programming language has a lot of merit. I need to think about, and type some more about it, but I have an idea for how a few statements for a local real estate agent could work....

Let me think about it...

Thanks Ron

Brad Thomas Send private email
Sunday, July 09, 2006
>>Your mention of a "domain-specific" programming language >>has a lot of merit. I need to think about, and type some >>more about it, but I have an idea for how a few >>statements for a local real estate agent could work....

Customer.FleeceForLotsOfMoney... ?

Estate Agents are not that popular in the UK...
Monday, July 10, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz