Fog Creek Software
Discussion Board




How to decide on sw behaviour?

I have the following problem, but let's say you have it as well, so you can think about it :)

The Problem:
------------

There is a simple web application, an intranet of a company. Every employee can login to this site, and can register for one or more of the company's internal trainings. The user can also cancel his registration later, at that time the trainer received an email about the cancellation and confirms that he received it.

The company pays the trainer $50,000 for every people who attend, or pay $30,000 if somebody is registered but not attend. The $ rate is so high so you can see the problem better.

There is a rule that only female employees can register(!), and attend the training.

The Questions:
--------------

- How do you handle if somebody changes her "gender" field on an employee profile update page? The rules says that only females can register, so probably you need to revoke registrations for this employee.

- But which has bigger priority? If the user is already registered on a lesson, does it means that he cannot change his gender to male? Or does it mean, that if he changes then his registration should gone?

- As only females can register, if somebody changes his gender, would it mean that a cancellation is not possible because: if only females can register -> then only females can deregister from a course).

WhatEver:
---------

Do you see my problem with these "business logic"? In this example I only played with 2 or 3 field. If we have 150-250 fields in a database how can somebody answer all of these questions, but more importantly how can someone know that he covered all of these?

Or I'm simple too anal retentive?


Wednesday, August 04, 2004

+1: My real problem is that most of these "rules" are consequences. I can simple change the gender field and go home, but the DB would be in a wrong state.

The real question is how can you calculate these consequences if you cannot write formal rules in software.


Wednesday, August 04, 2004

Yes, let's throw out business logic and rules from our applications, and let the developer's whims become law.

Yes, it's a PITA - that's life.  What are you really asking here?

Greg Hurlman
Wednesday, August 04, 2004

>>>How do you handle if somebody changes her "gender" field on an employee profile update page? The rules says that only females can register, so probably you need to revoke registrations for this employee<<<<

Come on how many times does the gender field change....unless all your user are really in San Francisco :-)

>>>But which has bigger priority? If the user is already registered on a lesson, does it means that he cannot change his gender to male? Or does it mean, that if he changes then his registration should gone?<<<

I think the possibility is so rare that you need to do nothing!  Just have the facility for the trainer to cancel registrations manually for anyone and that should do it!

>>>>As only females can register, if somebody changes his gender, would it mean that a cancellation is not possible because: if only females can register -> then only females can deregister from a course)<<<<<

Look be sensible here....if this is something rwally specific to  female's men will not register anyway....why go to extreme lengths to prevent that from happening? Just allow anyone to register male and female...that way no one can accuse you of sex discrimination also!

Code Monkey
Wednesday, August 04, 2004

I got the feeling that female/male was an example and not the actual criteria, but I could be wrong...

muppet
Wednesday, August 04, 2004

yes, f/m is just an example. the issue here is how can we keep the DB consistent with the rules as well as how can write functions which can track all of these rules and consequences.


Wednesday, August 04, 2004

Yours sounds like a very basic and elementary question, the type that a year or so of training in computer science would address.  You're asking something very very general and foundational to a good understanding of software development.

How is it that you were hired as a developer if you lack this sort of training?

muppet
Wednesday, August 04, 2004

muppet, go and f...k off man :)


Wednesday, August 04, 2004

if only 'females' can register, then the gender field should not be changeable on the form.

OR

if they change their gender, just automate the system so that they immediately get de-registered.

...or am i missing something here?

Kenny
Wednesday, August 04, 2004

You're missing that the OP seems to want a complete crash course in application logic design?

muppet
Wednesday, August 04, 2004

If only female employees can register, that doesn't say that all female employees MUST register.  If a woman wants to avoid the seminar so badly then she shouldn't register.  If she changes her gender to avoid it then the result is the same.  Are you worried that people put down the wrong gender in the company database?    Who's tasked with verifying that data?  Probably not the person writing the business rules of the web application.  So, take a "not my department" view and assume that the company database is correct, then base your business rules on that and let the "woman"'s manager worry about the gender entry and whether "she" attended the seminar.

Barry Sperling
Wednesday, August 04, 2004

>yes, f/m is just an example. the issue here is how can we keep the DB consistent with the rules as well as how can write functions which can track all of these rules and consequences.

Ah...then why did you not say so right away!

If you want to keep the DB consistent with everything else the simplistic way of doing it is to employ database triggers presuming that the consistency has to be maintained only in the db.

If you want to keep the outside views consistent your external  views have to poll for changes and adjust their views or better still have a separate process look for any changes and then send messages to all your views to update themselves with the latest info. In this case this process will watch for any gender changes and then send a message to the registration process so that it can have a look at what changed and act accordingly

Code Monkey
Wednesday, August 04, 2004

You miss the _philosophy_ here. The true meaning of the problem. Which is the following:

How do you identify and keep track all of these rules in a DB which has 300 tables and 3,000 columns?

The problem is not with 2 tables and 2 fields, but with 300 tables and 3,000 columns.


Wednesday, August 04, 2004

Well I suppose the solution would be to create a trigger on your user table that either rolls back the sex change and returns an error or commits the change and invalidates the user's seminars.
 

Captain McFly
Wednesday, August 04, 2004

"How do you identify and keep track all of these rules in a DB which has 300 tables and 3,000 columns?"

The same way you'd do it with one table, just more of it.

Captain McFly
Wednesday, August 04, 2004

A much more likely case is where the person who's registered actually leaves the company, or changes departments so that the internal billing is all wrong.

It's not Databases 101 stuff, but Databases 201 yes.

Stephen Jones
Wednesday, August 04, 2004

OK, so make the problem more complex: How do use design the UI?

- Do you disable the gender field if the looser-user has an *active* registration?

- Do you offer him the registration page if he is a male? Why? You know at the beginning that he won't be able to register.

*again*. think about for 300 tables with 50-70-130 dialogs.

That's why I hate web projects.


Wednesday, August 04, 2004

i'd probably plot everything out diagramatically.

i'm better with visuals.  :)

Kenny
Wednesday, August 04, 2004

Create unit test for each rule and you'll see if you break something.

Communicate often, so your team will know all changes and help You to detect violations

Keep rules as clean as possible and as small as possible.

Max Belugin (http://belugin.newmail.ru)
Wednesday, August 04, 2004

HEY GUYS. I ASKED HOW CAN YOU IDENTIFY THESE RULES AND NOT HOW TO TEST IF I ALREADY WRITTEN IT. COME'N GUYS. READ IT.

:)
Wednesday, August 04, 2004


How do you identify these rules?

ASK THE USERS.

I see this way too often, where a developer goes into vapor lock trying to handle every scenario, however unlikely.

You have to have a very strong relationship with the people who will actually use your software, and the people who thoroughly understand the business environment in which it will be used.  (These are not necessarily the same people.)

Sometimes it is acceptable to allow some nonsensical situations to occur in a database because the likelyhood of them actually occurring is extremely low, or the consequences are trivial, or they are easy to manually identify and correct.

All the other posters - even muppet :-)  - are correct in advising that you learn the basic concepts of software development.

Craig
Wednesday, August 04, 2004

First rule...make sure your caps lock key is not stuck!

As to how to identify the rules....why don't you friggin listen to what your users have to say about how they want to use the system in the first place.  Did you ask the trainer? Did you weigh the devlopment time you have to implement this? Is  this is a mission critical application that you have to absolutely take care of every contingency?

What do you think? That there is some secret formula which will help you bypass all this?

Code Monkey
Wednesday, August 04, 2004

Not really sure what you're asking, but here goes...

The gender thing is surely a no-brainer - just add some code into the profile-editing UI so that if they try to set their genre to male, it first checks if they're registered on female-only courses, and if so, pops up telling them that if they want to become male they must first go unregister themselves from female-specific crap. Or be automatically unregistered. Or whatever.

If you want some kind of system that 'knows' about these kinds of rules and constraints and builds appropriate checks into the UI automatically - well such things would be possible (say you could use some kind of declarative mini-language to express the rules/constraints and have the system make logical inferences from them when contructing the UI behaviour). But most cases you'd want very customised user interfaces and customised errors and dialogs and what have you for the different situations and so you'd just have to build the relevant checks into your code yourself. Perhaps using a similar kind of 'smart' system to keep track of the rules for you as you program the UI.

Either way, triggers, stored procedures, constraints etc in the database are your friend. To maintain data integrity behind the scenes.

Matt
Wednesday, August 04, 2004

>> all the other posters - even muppet :-)  - are correct

Jesus! Hell HAS frozen!

KayJay
Wednesday, August 04, 2004

Infact you can just use the contraints in the database to keep track of these things when writing the UI. Whenever your UI (say) updates a table, you check to see what contraints in the database that table must obey, and build in relevant checks into your code to make sure the query will never cause an error because it doesn't fit some constraint in your data model (such as the sex example you gave).

With lots of tables you'll have lots of constraints, so you could maybe write some special tool to help you enumerate the relevant ones to a particular table / module of code easily from the database schema. I expect such things already exist in some data modelling tools and IDEs, although can't say I've worked with any DB's bigger than ~50 tables myself, so it's not been an issue...

Matt
Wednesday, August 04, 2004

+++All the other posters - even muppet :-)  - are correct in advising that you learn the basic concepts of software development.+++

Hahaha. If this would be true this problem would be solved 10+ years ago. Look at today's problem and you can see that basic concepts cannot help here.

:)
Wednesday, August 04, 2004

:) -

when /everyone/ is telling you that you're asking an elementary question which demonstrates your lack of understanding of key concepts, you should probably begin to suspect that they are right.

muppet
Wednesday, August 04, 2004

muppet: it could be true, but when you're in a mental hospital and everybody there says that you are stupid, then you should ask the question: who is the doctor, them or I?

:)
Wednesday, August 04, 2004

So is the scenario of registering for a seminar also just an example?  Because 300 tables and 3000 columns is way over complicating a friggin' registration form.

If you know what you are doing, and you are just stuck on one part of it, be more specific and maybe you'll get more specific help.  Otherwise, it sounds like you are asking the forum to do your job for you, and then you even break out the ALL CAPS and yell at them for not reading your mind.

Either way, you are asking the wrong questions.

Clay Whipkey
Wednesday, August 04, 2004

I think A solution to this problem, as many have pointed out is obvious.  However, I think the OP is looking for a better solution than the common rule gauntlet for input validation and trigger monitoring processes.  Similar to the constraint suggestion. 

Jon Lindbo
Wednesday, August 04, 2004

But the OP is not asking any specific questions.  He is vaguely defining a nebulous problem made of (presumably) all subset examples of what he perceives to be the issue and none of his actual scenario, and then asking the forum-at-large to design a solution for him based on his nearly non-existant requirements.

muppet
Wednesday, August 04, 2004

A better suggestion like the constraints for posting to the forum where no message is allowed unless it's clearly explained with caps lock off?

Woops, doesn't seem to be working.

Stephen Jones
Wednesday, August 04, 2004

I never said he asked the question properly ;P  Is this a real world scenario or just a poor example for a bigger question?

Jon Lindbo
Wednesday, August 04, 2004

Similarly to what somebody else said ...

As a pedagogical example, consider a global trigger for insert/update/delete on any table in your database.  This trigger would open a recordset on another table called "rules" (selecting just those rules which apply to the trigger table).  These "rules" records would identify constraints that must be satisfied in order for a record to be inserted or updated or deleted (and maybe some helpful information like an error message to display if a rule causes an operation to fail), or they'd allow the operation with a few necessary changes to other records.

You can use an existing language for these rules, or you can craft one that fits your particular domain.  An example of a possible type of rule for the example you gave would be:

Rule: Update (old-record: olduser, new-record: newuser) { if (olduser.gender != newuser.gender) revoke_user_deal(olduser, special_gender_deal); }

That's a simple kind of system but you can go in a number of different directions with it depending on what you need to do.  It could be much simpler, for example, if you just say yes or no about creating/updating/deleting records (this way your rules can be smaller and more easily analyzed for inconsistencies and so forth).

Kalani
Wednesday, August 04, 2004

it's a poor example of a bigger, so much bigger question.
I admit english is not my native language, that could be one of the reason of you and I talking about 2 different things.

:)
Wednesday, August 04, 2004

I guess this an example of the problems caused by current SQL DBMS products' inability to correctly implement the relational model.

I suppose relationally speaking you'd define your set with certain conditions; that way it would reject an update to set the sex = 'M' if reservations exist. You would then report that error message back to the client. Your client would catch a return value of -1 (or anything non-good) and display the error message and show the form again.

Captain McFly
Wednesday, August 04, 2004

I don't see how the software can prevent anyone from attending the training (a bunch of electrons blocking the door?), but it can certainly prevent a man from registering for the training. The rest is manual enforcement of the "no men allowed" rule.

What about people born with ambiguous genitalia?

Derek
Wednesday, August 04, 2004


:) wrote "Hahaha. If this would be true this problem would be solved 10+ years ago. Look at today's problem and you can see that basic concepts cannot help here. "

You've completely missed the point that we've been trying to teach you.  There is currently no global solution to this problem.  If there was, we wouldn't all have six figure incomes building the same classes of applications over and over.

The essence of business software development is the details.  Heuristics and patterns help you to fit your details into an appropriate framework, but there is no framework you can apply blindly to solve these types of problems.

As for your attitude,  since when is it appropriate to cast insults at people who are wasting their valuable time trying to help you out?

Craig
Wednesday, August 04, 2004

Along with a great many other types of people I'm quite happy that the half of the world the other half could do without existing I can now include those that ask specific questions about a specific problem using entirely different facts than within the real problem domain.

Why?

Is the real attribute terrorist/non-terrorist?

Or perhaps Bush/Kerry?

Or Republican/Democrat?

It can't be that sensitive otherwise they wouldn't let you play with it.

Simon Lucy
Wednesday, August 04, 2004

But to be more helpful.

Run, don't walk and go find a copy of  Terry Halpin's book on Database design, using ORM.

http://books.elsevier.com/us//mk/us/subindex.asp?maintarget=&isbn=1-55860-672-6&country=United+States&srccode=&ref=&subcode=&head=&pdf=&basiccode=&txtSearch=&SearchField=&operator=&order=&community=mk

Learn how to interview users and record the facts about the problem domain before you worry about the implementation.

If you get all the facts right (and talking to the domain experts, that's the users, is the only way to get them) then the implementation will fall into your lap like a ripe peach or a cuddly girl, whichever is your preference.

Simon Lucy
Wednesday, August 04, 2004

Is this a new web application or is it something you were tasked with maintaining?

Sounds to me like there wasn't a lot of thought put into the application architecture of this system. What you are designing or maintaining is not a simple web application. It is a web-based software system since more than one application can modify your database tables.

 
Thursday, August 05, 2004

any new comments?


Thursday, August 05, 2004

I would say:
Provided your DBMS is capable of expressing the business rules that you seek it would handle all of this. Namely you'd define a business rule saying that people with Sex <> 'F' are not allowed to register for classes (or whatever an equivalent expression would be). Then when the user would try and update sex = 'M' it would die because it conflicts with that rule.

It all depends on your DBMS but if yours is capable enough it should take care of the problem.

Captain McFly
Thursday, August 05, 2004

>What about people born with ambiguous genitalia?
They tend to get operated on immediately at birth. Sometimes without the knowledge or consent of the parents. About 1 in 25 infants are born with ambiguous genitalia: where you can't immediately say "its a boy" or "its a girl" but instead say "its a ummmm..... errrr...." Hostpitals won't let you out of the place with an infant with ambiguous genitalia, just as they won't let you out of the place if you don't already have a name to put on the birth certificate.

When doing some database cleansing (I was looking for FIPS lists/coding for states and counties to clean up the address tables), I came across the FIPS codes for gender/sex and the FBI codes for gender/sex and they added 5 more to the mix: unknown, pre-op m->f, post op m->f, pre-op f->m and post-op f->m. They did not have a code for hermaphrodites (which I thought was fascinating, since true herms are ultra rare, but do exist).

>As only females can register, if somebody changes HER gender, would it mean that a cancellation is not possible...
Nope. Your rules should cancel the reg. But you should talk to the domain experts to find out what the real rules are in your business.

Interviewing users to find out the real rules of a company is one of the skills you will need in order to stay in the business. You may find out that the written rules have not been followed for years, and the unwritten ones are how things are going on. It can be a real eye opener to try to automate a process when no one has a clue what is happening. I suspect that the reason that so many programming projects "fail" has more to do with the gap between what is said and what is done in a business. If you automate what is said, you fail. If you automate what is done, the managers (usually) flip out at you.

As for the original poster, one can either use triggers to implement the business rules, or have some process that runs hourly/daily/weekly/monthly that looks for violations and brings them to some human's attention. Which is better? It depends on what DB you use, what the rules are and what sort of work you are comfortable with. If most of the stuff is code that runs daily, then you may as well put some sort of rule checker in that kind of code. If you are looking for an online/instant transaction system, then you want things in triggers.

Peter
Friday, August 06, 2004

*  Recent Topics

*  Fog Creek Home