The Old Joel on Software Forum: Part 3 (of 5) - There's a requirement I don't completely understan

There's a requirement I don't completely understan

Out of a bulleted list of requirements, rather vaguely defined, I've been allotted one - for now only to study what it means. Once deciphered, we'll be acting on it. The bullet reads:

[BULLET]
A flat file based locking and unlocking mechanism for allowing separate processes to acquire exclusive named "locks", with contention prevention and management.
[/BULLET]

What would that mean? The one thing I could think of as a possible interpretation was that he's asking for a program that monitors resource (such as file) sharing to determine whether the resource is locked by a particular process or not, and to grant or revoke exclusive locks over the resource. I think he's talking about a program that monitors race conditions.

Does it ring any bells?

The obvious thing I know would be to ask for more information, which I did. But it is not yet clear even to the people who have delegated the responsiblity to me as to what it might mean. I hate to find myself in a situation like that, but I guess you all have lived through it.

Please advise me as to what might be the interpretation of the minimalist requirement.

Sathyaish Chakravarthy
Monday, November 24, 2003

Asking the "Why?" question maybe would work. When I get vauge technical descriptions from people that confuse the "why" they need a problem solved with the "how" it usually boils down to a specific problem they have.

Most people think that including technical sounding implementation ideas is really helpful. They are not. They are confusing at best.

Try to find the root problem they need solved, and I will bet on when you understand the problem you will find a way to implement code to meet that requirement, and you can forget about the "flat file based locking mechanism"

Patrik
Monday, November 24, 2003

It could be
- if a "lock" file exists, some application already uses a resource
- if a "lock" file exists, it contains and "id" of process that uses a resource
and so on.
In general that file is a point of synchronization access to a resource - only one process can obtain an exclusive lock to access that resource at a time.

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

You should read "it contains and "id" of process", too fast typing...

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

You should read "it contains an "id" of process", too fast, too fast typing...

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

Granted, I'm assuming alot, but...

Sounds like someone's trying to implement a flat-file equivalent of table-level record locking. Imagine a fixed-width file with simple records like this:

001 Jones Betty 120
002 Davis Fred 240
003 Davis Spammie 1200

It would be useful for one process/thread to lock record 1 and another to lock record 3 - such that multiple tasks could update records simultaneously in the flat file.

This is easily achievable using lock primitives in Win32 and most other OS's.

The key question to ask is whether pessimistic or optimistic locking is to be utilized, which would answer the contention management issue (perhaps).

D Ross - BadBlue com
Monday, November 24, 2003

We used to call them "application locks." If the system is run without a database, or even with a database, these are used to single thread updates.

Without a database it is used to ensure control. In a DB environment it is used to eliminate the need for database locks, which have a nasty habit of being upgraded when programmers least expect it. (Deadly embrace, or table sweeps).

BigRoy
Monday, November 24, 2003

The requirement is not sufficiently clear: it's a bad statement of requirements. The prior comments are interesting but still leave you with problem of figuring out which applies.

Your first job is to try to get the requirements to be improved.

Anyway, I read "flat file based locking" as "locking method implemented with flat files". That is very different than "record locking for flat files".

njkayaker
Monday, November 24, 2003

Here's another vote for the "locking using flat files" interpretation, though I do wonder why they'd specify "flat" in that case. (Maybe for full buzzword compliance it's necessary to design an XML scheme for your zero-length lock files.)

Anyway -- What's this doing in the *requirements*? Requirements are meant to be things like "It shall be possible to run multiple instances of the application concurrently without data corruption", not "... and this shall be achieved using lock files". Is there some reason why this makes sense that I'm missing?

Gareth McCaughan
Monday, November 24, 2003

From the "named "locks"" bit in the bullet point, it seems that some kind of record locking thing might be needed, maybe with a user name attached? Maybe flat files so the list of locks can be readable for some reason??

Dominic Fitzpatrick
Monday, November 24, 2003

The "named locks" bit could be "a locking system that can be used for locking multple resources at a time".

The requirements "suck". The first step is "unsucking" them.

Knowing what the intent is would help in figuring out what is meant. But, as they currently stand, the requirements are ambiguous.

njkayaker
Monday, November 24, 2003

"A flat file based locking and unlocking mechanism for allowing separate processes to acquire exclusive named "locks", with contention prevention and management."

A flat file based - not database, but a text file either CSV, tab seperated, or XML

locking and unlocking mechanism - permission system

for allowing seperate processes to acquire exclusive named "locks" - to allow a process to get exclusive rights to (something)

with contention prevention and management - so that process A and process B won't both request access at the same time.

----

Those requirement may or may not suck, I really don't know what the lines above and below it are. Who wrote them anyway, they seem pretty technical and not the requirements you'd be getting from your standard business drone.

www.MarkTAW.com
Monday, November 24, 2003

Is this a school assignment? Otherwise why can't you just ask your project manager what he means by this requirement?

I really wish if it's a school assignment people would say so and also name the school and name of the course... that can help us help you formulate an answer.

Dennis Atkins
Monday, November 24, 2003

Given the information provided in the original post (and avoiding speculation about what was ommitted), the requirement is not well written (it _is_ a bit of an exaggeration to say it "sucks").

It certainly is possible that the parts we haven't been shown might clarify the situation. Since it seems clear that the poster saw these other parts and chose not to include them in the post, the implication is that the the poster did not deem these parts as relevent or helpful. (Of course the ommissions might have been a simple mistake by the original poster).

The big point is that the requirements are not static "handed down from god" kinds of things (certainly, they should not be at an early stage of a project).

njkayaker
Monday, November 24, 2003

"Is this a school assignment?..."

Sathyaish is not a student. See the thread from last week asking "Why did everyone get upset went I sent a longwinded email to everyone in my company?" (Paraphrased. <g>)

Robert Jacobson
Monday, November 24, 2003

Thanks for the inputs, guys. The (prospective) client arrives tomorrow. The business guys at my end are complete buffoons. They've asked me to do *something* about it, like they always make hustle and bustle as soon as they receive any mail from a prospective client.

>Asking the "Why?" question maybe would work. When I get vauge technical descriptions from people that confuse the "why" they need a problem solved with the "how" it usually boils down to a specific problem they have.

Patrik, you have a point. I don't know the way other businesses function, but down here, we usually have prospective clients interviewing Indian software consultancy firms with their requirements. These set of requirements are, unlike a specification for a software project/product, I presume a test requirement only to measure the competency of the Indian firm. The process is business oriented with bulletized requirements, sometimes not clear, sometimes clear. If you ask too much, you're ruled out. That's not the way we engineers develop software though. Neither do companies like ours do it that way, but sometimes its important to bag the project and at this stage, although it might seem sensible to me to inquire for further elaboration of requirements, it cannot be afforded by the business managers above me. I cannot ask the "why" about the issue because I do not have direct access to the client, neither do I have access to the complete text of the mail he'd written. I was only given this bullet. This is ludicrous I know, but it doesn't happen with me like this. Never. This is the first time I am getting a vague requirement and being asked to deliver without being told what to deliver. But this is not the first time the business guys are doing something as ludicrous with something they have no clue about. Its their daily job. They don't understand any technical requirement and always assume we can do whatever is asked with whatever little information.

>Sounds like someone's trying to implement a flat-file equivalent of table-level record locking.

D Ross - BadBlue com, I don't know. It sounds like a lot of things to me. Could be a multi-threaded application where threads access shared resources and signal semaphores after locking a file. It could be what you're saying, a record-level flat-file based lock. I don't know what to think. One is free to think of a lot of things but not implement all of them.

>Anyway, I read "flat file based locking" as "locking method implemented with flat files". That is very different than "record locking for flat files".

You are right, njkayaker. I am confused as well.

>Anyway -- What's this doing in the *requirements*? Requirements are meant to be things like "It shall be possible to run multiple instances of the application concurrently without data corruption", not "... and this shall be achieved using lock files". Is there some reason why this makes sense that I'm missing?

Gareth McCaughan, business BS! I agree with you and I work very much with stiffly defined requirements whenever I have some decision making power.

>But, as they currently stand, the requirements are ambiguous.

Well, that's the leitmotif, and that's also the quintessence(pls. mind my spelling) of this discussion so far. You are right.

>I really don't know what the lines above and below it are. Who wrote them anyway, they seem pretty technical and not the requirements you'd be getting from your standard business drone.

Neither do I, Mark. I was just given one bulletized point. That's it.

>Is this a school assignment?

Nope

But I thank you all for your time and your inputs.

Sathyaish Chakravarthy
Tuesday, November 25, 2003

The joys of outsourcing!

Am I the only one who thinks the whole scenario you have described is barmy!

And at the end of this nonsense they will tar all Indian programmers with the same brush

Stephen Jones
Wednesday, November 26, 2003

:Am I the only one who thinks the whole scenario you have described is barmy!

No Steve, you have my company to be honest. But what would your turn be if you were pitchforked into a a soup of this kind_

Sathyaish Chakravarthy
Wednesday, November 26, 2003