Hi guys,

Sorry I just had to vent after a tough days work.

I'm a coop at an international paper-making company. My job is pretty much to make web applications in ASP.NET for various users throughout the company (like Sales, Accounting, etc.) to do their job better, for instance a site where they can retrieve reports and such.

My most recent assignment was to develop an addition to a web application created by a senior systems analyst in my department that allows him to quickly add users and such and to handle assigning privileges within the system to them.

Essentially these privileges fall under "privilege groups", which means in the database each "privilege" links to a "privilege group" record.

I decided that while I was at it making him a page where he can create new privileges I might as well allow him to make new privilege groups too.

After I did this, he told me to remove that functionality. I wondered why, and he told me it was because if a privilege group was added to the DB the program would require modification.

I looked at the rest of the application and saw what he was talking about.

--> HE HARD-CODED THE ID OF EACH PRIVILEGE GROUP IN THE DATABASE INTO AN ENUM.

As in like:

Public Enum Privilege_Group
Sales = 1
Accounting = 2
...
End Enum


Do you think it is good programming practice to hard-code the ID's of certain records in the database into your program? Whenever you add a new group to the DB, you have to add it to this Enum. Sure, it's easy for him, but I strongly doubt the next guy will know this. Did I mention his documentation is lacking too...

In my world, a database stores *data*. You should be able to add/remove data without having to recompile your program and change hard-coded ID's!!!

The only thing this enum is for is so that he can pass a "Privilege_Group" type between functions (it basically is a narrowing conversion on Integer to only allow Integers that exist in the Privilege_Group table).

However, if type-checking is what he's worried about, I had a solution.

Make a Privilege_Group class!! I've found quite often it's nice to make a class for each database table. Then you can make a function where you pass it the ID of a record in that table and it returns the record as that type.

For example,
Public Class Privilege_Group
Protected ID As Integer
Protected Description As String
...
End Class

You could then alleviate a lot of parameter passing because all fields are encapsulated in this object.

I told him I had come up with an idea for how he could change his project so that changes could be made to even the privilege group table and the application would behave just fine without requiring changes to his little Enums (which could be eliminated). He simply said "don't worry about it" and showed considerable discontent with me even suggesting I could improve his code in any way.

I know I am simply an intern, but I am a software engineering major. Some (including him) feel we *are* Computer Science majors, but trust me; there are differences. Mainly, software engineers (at least at my school) focus FAR more on how to DESIGN software in an OOP environment and less on actual implementation. This makes sense, because engineering in general is largely based in design.

I feel many senior programmers who were based in the days of spaghetti code have difficulty truly making the switch to OOP. I feel because that he thinks because he skimmed part of an OOP book or two and picked up a few things in industry that he is an expert. I feel you need to undergo programming challenges that specifically encourage strong OOP to pass to really understand how to make it useful.

In former and likely future programs, he has and will continue to hard-code several elements of his programs to the database. It would have taken merely 5 minutes for him to listen to my solution and fix what I see as a terrible programming practice, and I was quite offended when my suggestion was dismissed likely due to lack of corporate stature. As one of the top students in my class (top 2%, and I am an engineering major) I am not used to having my ideas blown off like this.

Have any of you ever run into some seriously-stubborn IT people? How do you get through to them when they quite often become quite perturbed if you even mention something in their code, such as a global variable, could be done better if done slightly differently?

**end vent**
thank you for reading.

Ride with the flooooow....

thats all you gotta do to survive..

it is not a good idea to show someone that you are better than them... not human beings

Peace,

Good point... I guess as an intern that's probably going to be the toughest thing to learn. Thanks.

You'll run into these things in software development -- where those with seniority will exert their will on you.

Its always best not to let these things bring your temperature up. Since you are an intern -- best to learn from this and move on. I don't think you will get much far if you start bumping heads with your supervisor.

Also, you never know -- there might be another reason why the id's are hard coded. Maybe for security? You could ask the senior programmer (politely) why are the ID's hard coded. He might be nice enough to explain it to you. Its all in the way you ask.

You'll have to also learn that software development -- regardless of your major -- involves people. Which means all the nice logical things your learned in data structures -- won't apply once you mix in one dose of an ego ;)

Engineering is a creative process and like many artist, developers can have a hard time dealing with criticism, even if it is constructive.

Like fyrestrtr said, its all in the way you ask. It is also a good idea to create an environment that allows colleagues to listen to you when needed.

I often find myself working with people who do things that I consider to be in poor judgment. However, I try not to air my thoughts unless it is absolutely necessary. I also always welcome other's input and find myself constantly bouncing ideas off people. This shows them that I value their opinion and since I'm not constantly trying to change their ideas, they are more perceptible to mine.

Do whatever your "boss" tells you. And NEVER show that you are smarter then them. Ever.

Simple as that.

If you want a job where you are "entitled" to think for yourself, then you have two choices:

1) Work for yourself.

2) Play the "game" until you are at the top of the corporate chain and then you are the boss.

If you can do #2, then good for you. But if you're like many of us.. you will be so frustrated that you will eventually quite and do #1.

:D

You should tell him he's wrong. Then quit and start your own company.

With regards to having the privilege IDs inside both the database and source code, its probably there so that parts of the application can check privileges. You need a way of knowing whether or not someone is an admin user, in which case the best programming practice is to use a constant that matches the database value.

Using this type of approach has important readability and (perhaps more importantly) maintainability benefits -- if you need to change the ID its better that the source code always checks through something like TestPrivilege(PrivilegeEnum.ADMIN_USER) rather than TestPrivilege(3).

To be honest, I don't see how you could develop a system without taking ID numbers etc. from the database and putting them directly in the code.

Did the senior analyst dismiss the ideas straight off? If I've ever disagreed with the approach someone's taken I've always explained why and put forward my arguments, normally a better way has come out of whatever's been said (and it's occasionally been fairly heated!).

Once you get his job you can do it the way YOU want it done.

But at this moment he has that privilage. Being boss is cool :D

*wanders off trying to find his medications for heart problem, high bloodpressure insomnia and eternal migrane*