Web Development

General discussion


Control Assurance in the IT department

By DanLM ·
In my previous job, we had spent a huge amount of time developing our Control Assurance section. IE: All code had to be checked out from them, all names for code was assigned by them, review of standards was done prior to them even seeing anything including a test plan.

Now, our control assurance section had home grown applications(clist's) that they used for performing a lot of these functions. But the fact is, that this section insured that standards were being practiced and that there was a documentation trail as to the development and deployment of applications.

I am currently working for a publishing business(contract) that just split from a major cell phone company. And they have none of this. No naming standards, no procedures for moving things into production. Shoot, there run time documentation is the worst I have ever seen. And I haven't seen a test plan yet. Except for the one I prepared on a crappy little monitor shell script I wrote.

They are now trying to put in CVS for any future development. But, I am unsure if they know what they expect out of this. I am trying to gently push them into using nameing standards, required documentation and other things like this when they start using CVS. I tell them, they are the best people to develope this because they know the buisness which is what I beleive the nameing standard should be based around. Ie: Code dealing with publishing has a leading qualifier of pl.

Now, I do not necessarily think my previous was job was perfect with regard to this type of function. But, this check and balance is a needed function in any IT department. Documentation trail, standards are adheared to, application development does not step on production.

I'm curious, I know there are alot of contractors on TR. What is your experiences with these types of controls???


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

The best places I've worked

by Tony Hopkinson In reply to Control Assurance in the ...

at were appalling failures.
One place had paper coming out of it's ears for a documentation trail, but if you were too busy you could fill it in after the fact. Worse still you had to, so the could survive the audit.

At, another developer's weren't allowed to breathe near the production servers. Everything had to go through UAT, get signed by off by the entire managemnet team etc. All went nipples up, because they couldn't be bothererd to make the UAT and production environments match.

As for naming standards. I saw one put into action once, when I was a one man shop.

Collapse -


by DanLM In reply to The best places I've work ...

See, maybe its because it was so beaten into me. But I seen naming standards as a good thing. I could look at any peace of code, and know right off that it was accounting/policy/... I could look at any batch code and tell you how often it ran. Ie, daily, weekly, bi-weekly, annual.
Naming standards were understood by everyone, and just made things very easy for everyone.
The production code, well. Us not being able to touch it was a good thing. Problems occurred, you was able to go back to your documentation/Control assurance and find out what was the last change and when it occurred. If that wasn't the problem, which a lot of the times it wasn't. Then you searched further.
Ok, I guess I need to take off my rose tinted glass's then.



Collapse -

I believe in it as well.

by Tony Hopkinson In reply to wow

As soon as you introduce a short term loss into the equation, the whole thing goes in the bin.

Most places I know use source control as back up not for versioning, others used back up for versioning. Documnentation trails are lovely to find out where you might have gone wrong. Filling them in three months after you've finished because an audit's coming up. Might as well do them on soft paper, they could come in handy for something then.

As for standards I'm blogging on them at the moment, you should see the crap code base I'm dealing with now. Apart from one letter procedure names it just about violates every sensible standard a village idiot could come up with.

Collapse -

Naming Standards - Can't Think for Others

by Wayne M. In reply to wow

Yes, people will do stupid things, but I do not think it is effective to try and do the thinking for them. Create an environment where the people understand the problem, make them responsible for correcting issues, and give them the authority to correct prior mistakes.

I have usually found that if the developers are closely connected to the users, the developers will adopt the users' language and will use it within the code. From personal experience, I know I am not going to check some sort of naming convention every time I need to create a new class, method, and variable; I need the inherent knowledge to create these names on the fly.

This is not to say that developers will always choose the best or even an adequate name initially. There are multiple reasons why a developer will select a poor name. When someone runs into a poor name in software code, we need to grant that person the authority to correct it and expect that the correction will be made.

I understand the difficulties that poor name selections can cause. I just differ in my belief that a document listing all possible "correct" names is useful or practical.

Collapse -

There are only two ways to go well

by Tony Hopkinson In reply to Naming Standards - Can't ...

No standard.
Full Monty Data dictionary, all that does is move the naming problem really.
Or you come out with a co-operative document. All routines that get data from the database are prefixed with LoadFromDB or some such. 99% of naming problems are down to poor design anyway

LoadInvoiceCalculateandStoreandReturnTotal for instance, this is not a naming problem. If you have to get a thesaurus out to come up with yet another variant for 'Get' to imply the extra functionality, you went wrong ages ago.

I'm just finishing off a blog on this very subject, it's called How to get right up Tony's nose.

Collapse -

Did you blog that here Tony?

by DanLM In reply to There are only two ways t ...

I ask, because I seem to have a strong voice in how things are going to be set up here with regard to version control and other quality control methods here. I have only my experience to go on, and this is narrow based on where I worked for 22 years.
Point is to try and provide the best solution, not just the one I know.



Collapse -

Will arrive soon

by Tony Hopkinson In reply to There are only two ways t ...

Article started sprawling all over the place and was getting way too big, almost a white paper or a novel.
I'm hammering on about quality as an approach to software as opposed to some sort of after the fact bolt on.

Breaking it up into styles which includes naming.
Logic, basically coupling and cohesion, and design which will be layering and modularity.

Part I should be on this weekend.

The stage setter is already in TR blogs under the programming tag called "Is quality a casualty of doing business".

Gone down pretty well. Though I don't seem to have emphasised how much more impact we could easily have on it with a bit more self discipline.

The business types keep making it easy for us to blame them. A get out of jail free card is nice, but I'd prefer to not to be involved with criminally bad code anymore.

Any comments will be appreciated.

Related Discussions

Related Forums