Comments on CLOSED-LOOP: Phrases that should set off an alarm in every soft...

I have heard many such requirements as well 1) sys...

2010-03-06T11:15:59.849+01:00

I have heard many such requirements as well
1) system should have optimum performance
(no note on whats the criteria for optimum means.)
2) SHould be user friendly
(most generic statement I watch for)
3) If condition statements (in requirements) without else :)

@jonas @anonymous Completely agree on this. Ecli...

2010-02-28T10:41:20.685+01:00

@jonas
@anonymous

Completely agree on this.
Eclipse cdo (the thingie I commit on) has this versionability in its core too (@anonymous: its used in pretty large apps far beyond toy examples). The solutions for the standard JEE world sound like they bring proven solutions too.
Things are implementable. But even with standard frameworks the work ahead is still very large. IMHO this is mostly due to 2 additional factors (that generic solutions cannot bring in - this matches your arguments):

1) versioned entites have to be dealt with in every other layer (from UI down to the service etc.). A lot of extra work.

2) the business mostly has even more specific criteria that matter on the timeline (ex. special states: 'to be committed', 'active', 'inactive' etc.) If you have these, getting a consistent timeline for graphs get even more complicated and tedious.

Everything should be customizable by users e.g. fo...

2010-02-27T18:31:21.270+01:00

Everything should be customizable by users e.g. form fields can be "user defined" and look and feel should be customizable by the user, who can even insert images and text. But we can't afford a proper content management system.

We need an UnDo function - and not just for a sing...

2010-02-27T03:38:53.671+01:00

We need an UnDo function - and not just for a single action, but for multiple actions.

The system must be able to import data in bulk from some "standard" format (as yet undefined).

Leave room on all buttons and labels to account for translations into other languages.

Must support non-arabic character sets.

508 compliance required (without defining what exactly this means in this case).

iPhone interface to the system.

I heard that during my career as consultant/dev: ...

2010-02-26T23:28:38.448+01:00

I heard that during my career as consultant/dev:

"The system must be multilingual" (Think about encoding, left to right, right to left, up to down, down to up writing.)

"It should behave like Google" (Users are used to A++ products and want a same level of quality with a very limited budget/time and a team smaller than 1'000 of Phds developpers)

"The system has been maintained by genius (junior) developers, now we would like modifications." (=> Crappy code, spagetti, useless documentation, sum of as many architectures as they were developers, ...).

"We cannot help you, only the (main) developper had the knowledge." (Arrfff solo developers who write "shortcut code" only to deliver fast without maintenance or readability in mind)

(In a cascading dev. organisation) "The specification are not done. You will developp while we decide about what the application must do." (This works only in "mature" teams using the right tools and being used to TDD, continuous dev, etc.)

The historisation thing doesn't have to be a probl...

2010-02-26T22:02:26.073+01:00

The historisation thing doesn't have to be a problem. That's not to say an alarm bell shouldn't go off at a nonchalant mention of it - but - if it's recognised it's a large and complicated task, and the entirely automated solutions typically do not work beyond toy examples - it's still a slog, but you /can/ get it right, or at least adequate. It's just incredibly boring and finicky to deal with the inevitable wierd exceptions about not storing hashes, anonymising such and such a historical record when viewed on a tuesday by a man in a hat, etc.

There is an excellent book on storing time-varying data in RDBMS:
http://www.cs.arizona.edu/people/rts/tdbbook.pdf

@andre I had the same experience, twice... Histo...

2010-02-26T21:42:29.177+01:00

@andre

I had the same experience, twice...

Historisation seems to be solvable quite neatly and easily with a generic technical solution. There even exist out-of-the box solutions (Hibernate Envers, Genome Historisation Support ...).
These solutions bear the danger that developers/stakeholders think the problem is solved, but in usually the problem must be really solved on a higher level else the solution just becomes unusable and over complicated...

I specially like this one: "The system must supp...

2010-02-26T21:28:10.435+01:00

I specially like this one:

"The system must support historisation"

I once worked on a system that had the marvelous idea to have most entities historisable (know that big state owned company with red logos?). We did it for a few months and removed most versioning capabilities afterwards. And it was not about budgetm but a matter maintainability. Just imagine how great it was to build consistent revision histories of object graphs...

This product will use 80% of the platform, and hav...

2010-02-26T19:55:13.556+01:00

This product will use 80% of the platform, and have 30% new functionality. Defining in percentages is a surefire way to blow a project.