Is the workload that the company I work for gives me normal?

[jeffstl]

We are a staff of 3 IT people. 2 of us handle all internal operations, and 1 handles the www application.

We have end to end control from SQL Server 2008, Windows server, up to the .NET application that runs the entire company such as Sales, Marketing, HR, Finance, Order Processing, Inventory, Reports, etc.

We manage approximately 1550+ Stored procedures, easily 500 or so tables, and off shoot side applications as well. We manage users machines, security cards, printers, documentation, etc.

We work hard, but we have very little time for testing. Our business is seasonal based as well so often times testing particular conditions is very tough.

What I am wondering is if my situation would be considered a normal one? Our head IT person tends to estimate projects such as say adding several new columns to a complex system that has over-reaching dependencies across 6-7 tables and 2-3 different screen processes in our application at TWELVE to TWENTY hours!.....Corr ect me if I am wrong but isn't that a bit low? And this is including testing, etc everything....( i.e pushed to live in that timeframe)..

We always have problems and like I stated before testing is difficult unless you've been in this system for 4-5 years and know all the ins and outs of it. I have been here for 2 years and I am starting to feel incredibly overwhelmed.

Just wondering if this is the norm and I should start looking for a new career because I keep making mistakes that my colleague says should be avoidable, but WOW....difficul t for me to always see everything....

[MMcCarthy]

Personally I don't work in that kind of environment these days. But from what I remember this does seem like a pretty heavy workload.

I can say that the scenario you described of 12 to 20 hours for that kind of change to a database is not something I would suggest to a client. I know from experience that dealing with dependencies on structural changes is a nightmare and without extensive testing you will inevitably miss something.

Only you can decide if you need to move on from your current position. However, I would advise testing the water before making any decisions. Might be an idea to make appointments to see a couple of the bigger recruitment agencies and see what the market is like first.

[jeffstl]

My biggest issue is the lack of testing. The general response is that "I" should test it but my knowledge of the typical flow of some of these processes is limited at best, and some of these stored procedures are thousands of lines long performing demand calculation, inventory allocation, and dividing up inventory among various profit centers within the company.

I bring these up in particular because it was something I just worked on for the first time and I had 16-20 or so hours to do it, and left a trail of issues that caused some impact.

And the main reason for that is because I had no solid test plan, nothing was provided to me, and I was very unfamiliar with even the meanings of certain columns (no documentation and very little comments)

In the big scheme of things I guess I am just looking for a little justification of my feelings that the expectation of something like that being done without problems is pretty high....like cutting edge best programmers in the world high :/

[MMcCarthy]

The reality is the "Best" programmers don't operate without sufficient testing. That's one of the things that make them the best. As a developer you can do system testing but user testing is called that for a reason.

Although it's been a few years the last time I worked in this kind of environment the company demanded not just system and user testing of any changes but full documentation. It's the only efficient way to operate.

[NeoPa]

It's always hard to get a good feel for the intracacies of someone's working environment, but I would say what you describe certainly sounds unreasonable. At the end of the day though, the proof of the pudding is in the eating of it. If it's not workable then it won't work in the long term, and problems will come into play. It's rare for people to stay lucky forever.

[Banfa]

I for one would never estimate any piece of work in hours (except may be the most trivial) I would always use days (a day being 7 1/2 hours for me). Estimating in hours suggests to me the the estimate is too tight, i.e. the estimator is using a unit of time that lets them shave off an hour to supposedly get a more accurate estimate and crowbar more work into the day but actually when you leave no wriggle room in the estimates it is just too easy for them to be too low.

That isn't to say I don't consider how long in hours aspects of a job will be. Even estimating in days it is easy to get it wrong.

It is hard to say exactly if the estimate you give is good due to lack of detail because adding a column can effect, indexes, conditions store procedures and other database objects.

For me I would say that adding a column that had a handful of indexes and conditions, without considering knock on effects to store procedures and without testing would take 1/4 - 1 hour.

So adding a few (say 4) columns to 6 tables is 6 - 24 hours or 1 - 3 days.

I would normally leave 1/2 - 1 day for every user interface change (except for the cosmetic such as correcting spelling) so 2-3 interfaces is 1 - 2 days.

On topic of that there are the business logic changes (store procedures et al). That is impossible for me to generalise on. A good well documented and commented system will be faster to change than one that is not. Also the complexity of the change, are the procedures actually just passing the new data through to the interface or do they have some new logic that depends on the new data?

For the sake of argument let us say 2 days for logic changes (simple changes across a few stored procedures).

For a total of (1 to 3) + (1 to 2) + 2 = 4 to 7 days or 1 to 1 1/2 weeks.

So yes 12 to 20 hours seems a little low to me.

And I would then want to add 20% - 50% for testing.


If you college says you have made an avoidable mistake ask them how it is avoidable. It is possible they are using information you don't have or it is also possible that they have been working in the environment for so long that the lack of comments/documentation is less of a hindrance to them because they just know.

I system with out documentation and comments where the programmers operate because "they just know" is the worst and has the steepest learning curve for a newly joining team member and makes those new members more prone to mistakes because they don't "just know".


Strictly the work flows (the normal ones at the very least) should be recorded so you can follow them and put them into test procedures. Our company always follows the same basic testing procedure.

1. Testing by the programmers/test team to pre-written test specs made from user supplied work flows.
2. Testing by the users normally by a test team of a few senior users.
3. General release to the rest all users

Missing out testing just promotes bad feeling (when things don't work correctly) and emergency fixing generally takes longer than fixing during testing.

[jeffstl]

Without getting into details the changes to the SP's were heavily involved in understanding the various units of measure things were stored in, and the various divisions of inventory based on the status of that inventory, and determining the total counts, demand, and allocation as part of a regular automated process, and funneling said inventory counts through a process to determine which divisions of the company would get what based on various pecking orders.

This was the meat of the change, and the rest were updates to various other dependant stored procedures and views, some of which interacted with the several main processes described above.

In the end I just need to accept the responsibility I have and simply admit my limitations in terms of the ability to get something like that done within 2-3 working days of time.

Instead I will just have to make testing and ensuring as few mistakes as possible, a higher priority then any estimate given to me by someone who may just be trying to set the bar high. If it turns out to be too high for me I will just have to move on ;)

[myusernotyours]

I feel you on this.

Been working myself on a huge application written most parts in C and symbol names in a language I don't speak. It's a mess. No documentation, hundreds of tables and the devs who know it all after years of trying are not willing to assist. They know the ins and outs and they want for some reason to keep it that way. It's very DARK.

The good part for me is I don't have to deal with tight deadlines and I normally give my own estimations on how long it takes to do something. That's a plus and if you can, you should insist on that.

Maybe you should indicate clearly why it's not reasonable to allocate so little time to a task. Mostly, task allocators are not the best people to estimate completion times.

If you are good and persistent, you can read the code and understand the workflow from there. Good Luck!

Regards.