Using a lot of Maps

[Tom Anderson]

Hmm.

So immutable then just means immutable in the documented
state.

That is flexible usage of English.

You could consider it 'logically immutable' rather than 'physically
immutable', or perhaps 'interface immutable' rather than 'implementation
immutable'. The concepts are related, but different, and both useful.

There's a similar idea even in C++'s const - you can declare an instance
variable mutable, meaning it can be changed even in a const object!

tom

 

[Tom Anderson]

Perhaps you'll want to include Muphry's law, the editorial counterpart
of Murphy's law:

<http://en.wikipedia.org/wiki/Muphry's_law>

That is a good law, but i'm constraining that list to laws directly
related to the manufacture of software.

There are some gems in this list, particularly the last one:

http://www.devtopics.com/21-laws-of-computer-programming/

Hmph. Humorous aphorisms, rather than laws. They haven't even got names!

tom

 

[Martin Gregorie]

That is a good law, but i'm constraining that list to laws directly
related to the manufacture of software.



Hmph. Humorous aphorisms, rather than laws. They haven't even got names!

True of most, but "a user doesn't know what he wants until given the
program he asked for" is spot on. The only good way round it, which I've
been lucky to be involved in 2 or 3 times, is to have an interested and
experienced user on the design team.

 

[markspace]

I can not see that quote in the thread!?!?

Well, no. The operative phrase being "to me said." It's an interpretation.

I did look up thread to see if there was any actual quote that would
have given me this notion, and found this in the OP: "but it seems a
more effective tree like structure than using a custom data structure
and having to iterate over it"

"Tree like" I suppose being the phrase that my brain latched onto.

 

[Tom Anderson]

True of most, but "a user doesn't know what he wants until given the
program he asked for" is spot on. The only good way round it, which I've
been lucky to be involved in 2 or 3 times, is to have an interested and
experienced user on the design team.

Iterative development, with frequent releases to the end users, is the
traditional solution to that problem, i think. It's fiendishly hard to
realise in practice, of course, because a user who doesn't know what he
wants usually also doesn't want to spend time finding out. He just wants
you to make it for him.

tom

 

[Arne Vajhøj]

Well, no. The operative phrase being "to me said." It's an interpretation.

I did look up thread to see if there was any actual quote that would
have given me this notion, and found this in the OP: "but it seems a
more effective tree like structure than using a custom data structure
and having to iterate over it"

"Tree like" I suppose being the phrase that my brain latched onto.

Anything is possible, but it does not sound that likely to me.

Arne

 

[Arne Vajhøj]

Iterative development, with frequent releases to the end users, is the
traditional solution to that problem, i think. It's fiendishly hard to
realise in practice, of course, because a user who doesn't know what he
wants usually also doesn't want to spend time finding out. He just wants
you to make it for him.

Even with iterative users still first know what they want
when they have gotten something else.

But with iterative the developers get the feedback sooner,
so instead of having to rewrite 100 screens they can just
rewrite 10 screens.

That argument of course assumes that the users are
consistent, but we can only do what can do.

Arne

 

[Martin Gregorie]

Iterative development, with frequent releases to the end users, is the
traditional solution to that problem, i think. It's fiendishly hard to
realise in practice, of course, because a user who doesn't know what he
wants usually also doesn't want to spend time finding out. He just wants
you to make it for him.

If the users are not complete numptys, seeing the first few screens and
sitting down to talk about it often sorts things out.

But, as I said, having somebody who's familiar with the target processes
in the design team works super-well. The best example of this I know
started when four of us (PM, designer, designer's mate, user rep) locked
ourselves in a room with a white board and drew, argued and discussed for
6 weeks, having spent the first two days making sure everybody could read
and understand a simple ERD. At the end of this we had a data model
nobody could poke holes in and that we knew was a good match with the
subject area. In parallel with this the pair of us techies had designed,
presented and had sign-off on a consistent screen design, a control
dialogue that both casual and power users could use easily, and we had a
system structure sorted out as well.

Its true that we released a small part of the system as soon as it was
running to get feedback. That was accepted without incident.

There were also two complex database search routines and a date parser
which nobody could predict the acceptability of until there was a fairly
large amount of data to scan. We put all three in self-contained modules
and explained to the users that we weren't sure how good they'd be, so
we'd written the simplest code we thought would be acceptable and asked
for feedback: that was exactly the right approach. In the event one of
the searches was exactly what was needed and the other needed two
rewrites. The date parser was also good though we later added a couple
more formats that nobody had realised we needed (BC dates, two and three
digit years for dates before 1000AD).