IT in a small company... OH !MY! GOD!!!! 1

[Klari]

Hello

I am at this moment programmer/database administrator/system administrator... (everything that has to do with computers) in a small company (we are running a shop). The idea of programming and administrating before I was here was: just get it done, fastly. we don't care if it is not the right way to do it.
A few examples:
* In our sql database we have a customer table with name, address, telephone and everything... we also have an article table (No, descrip, price, blabla...). In the table where the sales are kept every data is present. Per sale you can find the customer's name adress and so on, the same thing for the article data... There are no kind of relations at all. When I asked why this was done, the answer was that queries were faster that way. Of course all the programming is based on this database and I can't just change everything.
* There is no data whatsoever on the years before 19**. 'The database was getting to big so we deleted all the records before that year'. And then of course the question 'Can you run some queries that will tell us when customers came here for the first time and all?'.
* The guy wo was here before me didn't keep a system logbook or nothing of that kind. All the programming had ofcourse absolutely no comments or nothing.
* When I want to make some improvements to some programming that was done before, i get the comment 'It doesn't realy need to be done, just let it the way it is'
* Our mail server has very very little free space left on it (something like 2%). Of course I tell my boss about it (I say that we just need a bigger drive, and we really really do), and the answer I get is 'Well..... yes..... eurmmm....... keep monitoring the free space left....... and.... eurmmmm..... I'll think about a solution'. Translatoin to normal people language: 'Just do nothing about it, we'll see when things get realy bad'. I just gave the guy a solution!!! a new drive!!!! g*dd**ned!

There are more things like this....

What's the deal here? Am I worried to much? or are thing realy as bad as I think they are?

greetings

Klara

 

[JGirl]

God, I think it sucks everywhere. Where I work, I am in a team of 6...A boss, her best friend, a couple of other ring-ins and 2 "jacks of all trades" who actually do work.

Every time I go to make a change to a program, there is no doco, no comments, no nothing....and not even good code. So I take the time to fix it up so it doesnt take so damn long the next time it needs to be changed, but get in trouble for using more than the allocated time. I'm living and breathing spaghetti code!

We also have a particularly nasty database containing customer transactions and general activity logs, and within this database, the date is stored as plain text (for starters), and in about 5 different formats. Then Im expected to try and get some useful information out of it.

Dont worry too much, you'll get use to dealing with other people's stupidity.

 

[TomKane]

It's probably going to have to be a bit of a trade off. If you have to change a program because of a business requirement then I suppose you'll probably be able to put in your comments and maybe write a page or two on what you are doing and why.

But if you change code, just because there is a "better way" then you'd better make sure it's right first time of asking because a lot of people use the phrase "if it ain't broke don't fix it".

What I'm trying to say that while you think maybe the system is a bit of a joke, the users probably think it's doing the job asked of it.

I think you may have to consider the perception of the system as well as the reality of it.

A problem we're trying to put right is that we spend too much time preparing specifications that the programmers only half-read. Why are they only being half-read? Probably because the documents are boring or overly lengthy/wordy and it's only too easy for the mind to wander while reading them.

What I'm trying to say is that you should try to make sure that if you go about putting a proper procedure in place for doing IT work that you don't put too much emphasis on the documentation to the detriment of the deliverables.

 

[Kjonnnn]

Well dont feel tooo bad. I know a place where a 'company' had staffers put the network together ... THEN they hired an IT guy after it was done.

They told him to fix it ... but don't spend any money.

 

[Klari]

Hi everyone,

thanks for the reply!

JGirl, I think we're more or less in the same situation... Picture a visual basic (6) program written in code that could have been written for COBOL or DBASE. Visual basic has so many usefull tools and my predecessor didn't use any of them! oh well..... at least I know what to do with my spare time at work

TomKane, I recognize that "If it ain't broke, don't fix it" thing... At my company I'm also intern helpdesk and I see people struggling with some of our program's. It's not only bad code, it isn't user friendly either. But people eventualy live with it and get used to it. When I see this, I can help but want to improve how these people have to work... I also get two kind of messages from my boss(es). I'm told that the program's don't realy need to be rewritten, but also that I have to show more initiative... I find it hard to write new program's if there is still work with the old ones...

Kjonnnn, I smiled when I read your post... I'm lucky I've never been in a situation like this (yet?). Did the guy (you?) actually stayed with this company? Did the network turned out allright?

greetings
Klara

 

[DonQuichote]

If you haven't heard of "refactoring" or "extreme programming" already, do an internet seach on those terms. It clarifies a lot, but alas it is not a cure for uncooperative or dead-stubborn people (I wish there were a cure for that!).

My opinion: if a piece of program code is so spaghetti that it is not maintainable, is IS broke and need to be fixed.

Best regards and good luck fighting the "windmills".

 

[TomKane]

All I was trying to say with the "if it ain't broke" thing was that a trap I have fallen into (in my youth) was that in an attempt to make a program better I have affected the business logic and which caused problems and got the users on my case.

I was trying to warn you that if you go about changing programs that technically improve them but don't have an "obvious" benefit to the user (I'm talking perception here) and you introduce problems that weren't there before you may end up hurting yourself. Who needs the hassle?

I worked with a guy who rewrote reams and reams of code to the point where the programs no longer worked - he claims what he did was find a "better way" to do things - my opinion is that in order for it to be a better way the program has at least got to work as well as it did previously.

Maybe I'm letting that colour my opinion. Just out of curiosty, what sort of a setup do you have at your workplace?

 

[Klari]

Hi TomKane, I'm working in a NT network (one main server, one mail server, one web server). My workstation is a W2k. Some of the people here have W2k and the others NT4.The programs are written in Visual Basic 6. A few are still written in Dbase but these are realy small programs.
Of course I think you are right when you say that the program should at least do what it did before... I don't think I'm a bad vb programmer so I always succeded in that (I mean, for the little changes I was allowed to do). I have the advantage that I'm always around my users, so I can ask them anything, anytime. So when I am programming and suddenly I have some sort of idea, I ask the users what they think about it. They say it's good, or they say it isn't good but and tell what would be better for them. Also when the programming is done and the user still has some things he'd like to change, I can do it right away. I think it's a whole lot different if you work for a company that sells software...

DonquiChote, I went for a search in google and foud a website

http://www.refactoring.com...

There were a lot of links to 'code-cleaners' for all sort of programming languages. I'm downloading a version for vb right now... Wonder what that will give.

 

[TomKane]

Klari,

I'm sure you're a very capable programmer. I was just giving my opinion as though it was me in your situation. Incidentally, I think it's good that you have such an open channel of communication with your users.

When you're in a situation such as yours and you do a little bit of everthing I imagine it must be very demanding. I suppose the trade off is that you get a very varied experience in different IT disciplines.

I think I have become very lazy in that I work for a fairly big company and we have a networks dept, a support help desk, and even an operations dept to handle the overnight batch runs. I think I've become far too comfortable and idle to ever go back to a small company situation.

Best of luck,
Tom

 

[DonQuichote]

Dear TomKane,

Refactoring is just tackling that problem. When refactoring, you write unit tests (small automated testbenches for a piece of code) so you can see if your modified code still works.
What you do is basically this:
-Test the existing code
-write some form of bypass code, leaving the original intact
-run the test for the bypass as well
-reroute the program to use the bypass
-delete the original, no longer referenced code.

Best regards

 

[Klari]

We are running out of disk space for our database. Again. (sigh)... I can almost hear my boss say 'just delete some records, that should do the trick...'. So should I or shouldn't I? I personaly prefer not to delete any records, but maybe I have a wrong perception of things....

 

[TomKane]

You could do a backup first at least then if you have to refer back at least you have the data saved somewhere. I don't know what is on your database but I'm almost sure that you're supposed to keep historical information of your accounts data for auditing purposes. Maybe some kind of a procedur will have to be putin place...

 

[swm58]

Klari,
I feel your pain. I've been in the software industry for 22 years and I've got the T-shirt just like yours. Since I am now in management I am in the unfortunate position of seeing both sides of the coin. There are some bosses who are just plain unreasonable. If that is the case, post your resume and do the best you can in the meantime. It could be, though, that the boss doesn't understand the ramifications of the problem. Why not try this? Cost out replacement storage. Disks are really cheap these days. Do you have an operating budget? Budget the replacement in to next quarter's budget. You really should do this because disks fail. In my shop we have a "hot spare" for all of our system drives and spare data drives. Do you monitor mailbox sizes? This can be done automagically. Lots of people are packrats. Write up a procedure so they can save their mail to their C drives. I've used "We are going to inspect the network drives including e-mail for unauthorized mail and attachments" It is amazing how quickly mailboxes are emptied:=) You'll need to get the boss to spread the word - more teeth in it that way. It's cheap and effective.
One last thing, do you have any helpdesk software to track your jobs? If not, you REALLY need to get some. There are several available on the internet that are cheap or free. I use a product called BugCollector that I bought at a nominal fee, but there are lots of others. You want to be able to describe the problem, put a priority on the problem, in your case state what kind of problem (hardware, software, etc, the time/date the problem was reported, the time/date the problem was fixed and a place to describe the fix action. This helps in three ways. First, you can prioritize your day based on the inputs. (Add creation of the hot spare as a priority 1) Second, you can use the inputs to show your boss how valuable you are, and third, you may be able to justify getting an assistant - then you'll be in management too
Make your bosses job easier - give him/her the solution when you present the problem.

 

[Griffyn]

Hi Klari,

I'm a one man team for a company with 50 users. I started out as a casual helping the accountant with spreadsheets (IT people were called in when help was needed) and slowly started doing more and more. 8 and half years later I am in total control of everything here, except for purchasing. I don't mind - it means I'm not responsible for budgets and stuff, but if I need something, I just need to prove it.

Anyway, I totally agree with swm58's thoughts, but wanted to add my own as well. Your boss is sitting on the fence because either money is a big problem for him/her at the moment, or he/she doesn't trust your expertise.

It's hard to deal with the money, because your boss will have the final say on expenses, and IT is the least of his/her worries. Keeping the business alive is what counts.

But with the trust aspect, that's much easier. The easiest way is to show collaboration with people your boss already trusts with IT matters, or who they have spoken with people *they* trust. So, rather than say to your boss 'The new harddrive will fix these problems', instead say 'I spoke with Kevin and he agreed with me that the new harddrive will fix these problems'. Or, 'I had a chat with Kevin's IT friends, and they agreed......'.

Of course, you have to be telling the truth, or you'll get screwed.

Take this approach often enough, and your boss will begin to trust you without you needing to speak to others, because any suggestion you make will automatically infer to him that you have consulted with others he trusts.

That's my two cents anyhow.

 

[tanderso]

So, we've been presented the IT side and the management side, now how about the spaghetti coder side! I'm wrapping up a contract where the client allotted 40 hours budget for a job that requires 40 hours for the bare minimum. So I delivered the bare minimum -- poorly commented, undocumented, buggy code which does its job 95% of the time (basically alpha code), but then they won't pay until they have error handling, documentation, code review, etc.! I ended up putting in an extra 100 hours and only getting paid for only half of it, and the code is still something I wouldn't put my name on.

The problem is that management goes by the Microsoft philosophy of software design. Get something that sort-of works to market, and fix the bugs perpetually. If they just budgeted enough in the beginning to do the job right, they could rely on it for years. But instead they shoot themselves in the foot every time.

The same is true if they don't give you the means for additional drives and backup hardware... one day the systems will crash and they'll lose money for days or weeks, or worse. And, of course, they'll blame you. Instead they could prevent such problems by laying out a hundred bucks here and there before there's a problem.

Here's an idea. Purposely shut down the email system one day for an hour or so and say that this is a drill for the day when it happens for real!
Sincerely,

Tom Anderson
CEO, Order amid Chaos, Inc.

http://www.oac-design.com

 

[CajunCenturion]

tanderso - you actually advocate the following: "Purposely shut down the email system one day for an hour or so and say that this is a drill for the day when it happens for real!"

You signature line indicates that you are the CEO of your company. If your IT manager followed your own advice, and you missed/delayed some very important email(s), perhaps costing the company some money -- be honest - how would you react and deal with your IT manager?

I am astonished that a CEO would actually advocate such a "terrorist" activity to prove a point.

As far as you spaghetti-coder story - you agreed to the contract. You delivered the goods and services and whether you want to put your name on it or not - your name IS on it, and you were paid for it (maybe not as much as you think you should, but probably more in line with what its worth), but you were paid for it nonetheless. You delivered an unprofessional piece of work to begin with, and if that cost you on the back side, well, IMHO, you got what you deserved.

As IT professionals we all have the obligation to present the facts, put the issues on the table, but we must do so in a professional manner. Put it in writing and be able to back up your claims with facts. You cannot force management to do what you think is right, but you can make sure that they are presented all of the pertinent data upon which to make their decision. As pointed out by others, the manager often has other issues in play that IT is not aware of.

Griffyn's suggestion of collaboration is a good one, but also one that can be overused. If you play that card too many times, the boss could start thinking, "Why am I paying you when you always go to Kevin". You're not going to earn trust and respect if you don't, on your own, do things worthy of earning trust and respect. Again, some collaboration is good, just don't overplay that hand.

Above all, no matter what you do or how you do it

BE PROFESSIONAL Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Klari]

Hello people

I am happy to see that much response!

The situation hasn't changed much... I sent an archiving procedure to all my users so they could store big but uninportant mails (such as pictures and movie clips) on their hard disks.... That takes out the risk of mail server crashing down hard, but the problem remains.
I had a good talk with my boss (at least I tried to) and I concluded it is a question of trust. At first, he said 'I just don't feel like changing the drive' (when I am supposed to do this kind of things), then he began rambling on another problem that was 'far more important'. I solved that particular problem and proved it was done right and problem was solved. I told him that, and he said he didn't believe the problem was solved. At that moment I just stayed calm and pointed one more time on my report that proves it all... Then he said he would think about it (about the hard drive).... Translated in non-boss language it gives "I won't give it another thought or word untill you start the subject again".
This little conversation proves he has no confidence in me at all... So now I'm working on getting his confidence, and I hope that later he will listen to me. It's a difficult situation, because I am very young (that means not much experience) and no-one who could show me the right thing to do. I have to build all my knowledge on my own (Of course I learned some things at school but it doesn't cover it all).
So I think it would be a very good idea to turn to someone my boss already trusts, but there is no-one here I can turn to.
Inside I hope that one day the crash will happen and I could tell him 'told you so' but this is absolutely not the right solution (and would put me in a lot of stress). Shutting down the mail-server for one hour is also totally not my way of doing things, but I have to admit I sometimes think about it.

Greetz

Klari

 

[tanderso]

If I were being really bone-headed about something and one of my guys gave me an unannounced demonstration to prove a point, I wouldn't be terribly upset. However, it wouldn't be a way to earn trust if you don't already have it. I wouldn't call it terrorist though. More along the lines of a fire drill.

As for the programming... I present clients with an estimate before accepting a contract. If the client chooses to strike out portions of the contract and only asks for the bare essentials, then I'm not going to reject the contract on the grounds that their code is going to be rushed and unfinished... that's their problem. When they try to squeeze back in the stuff they struck out under contrived reasons and say it is part of the original contract, that's what pisses me off. It's less of a hassle and promotes better business to give them a little more than they paid for than to send it to a collection agency, but of course there is a limit.
Sincerely,

Tom Anderson
CEO, Order amid Chaos, Inc.

http://www.oac-design.com

 

[MasterRacker]

Frank Hayes just wrote a column in Computerworld (

http://www.computerworld.com/managementtopics/roi/story/0,10801,77446,00.html

) that's related to this topic. Management makes decisions for their won reasons, that you're not always going to know about. As CajunCenturion stated, you make the best case you can and that's all you can do.

I think Tom is an unusally easy-going CEO and he also has technical epertise or he wouldn't be here at Tek-Tips. This is not the normal situation. I think in most environments, someone who staged a fire drill on their own to make a point would be drilled then fired.
Jeff
If your mind is too open your brains will fall out...

 

[tanderso]

Well, yeah, that's true. My company is very small (and still relatively young at four and a half years)... hardly enough to warrant a full slate of officers let alone multiple tiers of management. I guess that's how many consultancies start out (sort of like doctors and lawyers practices). I'm actually a programmer forced into management (by myself and market conditions), and I do the client interaction, much of the design, part of the development, and most of the management. I've also previously been in the situation of being managed, and I know when managers are being bone-headed about stuff they shouldn't be. The problems stem from when managers think they know everything, when they're really the least informed of the lot. Sometimes sysadmins don't understand the whole picture, but they are generally competent enough to know that crashing a vital system (for real) is going to affect the bottom line, so ignoring them when they say something is absolutely needed right away is not a good idea. If you trust someone enough to maintain your systems, you ought to trust them enough to tell you when they need to purchase something to do so effectively.

As I said, I don't advocate doing the "drill" if you're not on good terms with your managers, but rather it is just an "idea" to contemplate. Still, not having email for an hour would only be a slight (albeit eye-opening) inconvenience, not a profit-plundering faux pas. In fact, unless you point it out, it's quite possible nobody would even notice. As an "idea", however, you might pose the question to your manager about what they would think if the email system went down for a few days when a drive inevitably crashes at some point (possibly very soon), and a new drive isn't ordered until the old one is toast. At least get them thinking about how vital the system is to them, and how dangerous the status quo actually is.
Sincerely,

Tom Anderson
CEO, Order amid Chaos, Inc.

http://www.oac-design.com