Question for professional programmers

[dullard]

I've got a VB6 code which I've done 95% of the work. I am not a trained programmer, but I think I have a fairly decent code. I've used plenty of comments and kept the code well organized into fairly short subroutines.

Altogether there are maybe 8000 lines (5000 or so lines if you skip the comments). The code accesses two third party drivers for various reasons and does some complex math calculations.

If you had to do a rough time estimate, how much time would a professional programmer require to do the following tasks:
1) Increase robustness against crashes (mostly due to the third party drivers) and user errors.
2) Increase efficiency. Some portions of what we programmed may be quite inefficient as it wasn't written by professional programmers.
3) Improve timing and have precise/consistant results with a wide variety of computer speeds.
4) Improve user interface. Make it easier for the user, add additional features, and reorganize the layout.
5) Get more out of the 3rd party drivers. Features are briefly described in the manuals to those equipment that we cannot figure out how to implement.
6) To get the best utilization of the drivers, the code may need to be rewritten in a flavor of C.
7) Keep the code easy to be read by amature programmers like me, so I can continue to develop it.

I'd assume #6 would be quite time consuming. Would you have any rough time estimates for these tasks? Obviously without the code at hand, these estimates may be difficult to make, but just assume the code is moderately complex.

 

[Ausm]

My Brother could do it but he charges I think around 175-300 /hr


Ausm

 

[dullard]

Originally posted by: Ausm
My Brother could do it but he charges I think around 175-300 /hr

Thanks for replying. I know many people who could do it. But I'm just wondering if I'm looking at 100 hours of work or 1000 hours. That'll play a big role in who we can afford.

 

[EagleKeeper]

1) Increase robustness against crashes (mostly due to the third party drivers) and user errors.
Figure 15 minutes per user entry area and driver interface to understand what is involved.
The time to enhance is variable, depending on what already is in place and what the parameters involved are.

2) Increase efficiency. Some portions of what we programmed may be quite inefficient as it wasn't written by professional programmers.
This depends of the perceived ROI. Some clients are willig to pay for correction of (from their view point) of incompentence. Depends on how the initial project was presented and the corrections identified.

3) Improve timing and have precise/consistant results with a wide variety of computer speeds.
IF the timing (speed) is not critical to the operation it falls under the percieved ROI.

4) Improve user interface. Make it easier for the user, add additional features, and reorganize the layout.
I have always used a guideline of 1-2 hours per UI change. 4-5 hours for new UI areas.

5) Get more out of the 3rd party drivers. Features are briefly described in the manuals to those equipment that we cannot figure out how to implement.
Again this is based on the percieved ROI. If features are needed, you are the only one who knows your skills and have the relevant documentation.

6) To get the best utilization of the drivers, the code may need to be rewritten in a flavor of C.
Depending on the quality of documentation ,code and the rewriter, it could take from 25 -> 75% as long as it took to develop the package in the first place. Again this is based on the percieved ROI.

The complete application may not need to be looked at being re-written. Just the interface to the drivers.
Then the VB code could call the C modules that interface with the drivers.

7) Keep the code easy to be read by amature programmers like me, so I can continue to develop it.
This should always be a given and part of the project requirements. Code documented and project/test plans/manuals documented and kept updated.

 

[torpid]

Impossible to say. These requirements are WAYYY too vague. Where they aren't too vague, it depends on the application. However, if all of these are required, 100 hours is absolutely too small. 1000 hours may be too small as well. Some of these items are monumental tasks if done properly... like converting the app to C. Improving user interface is such a vague thing. If you do it right, it will take a lot of time.

Sorry to say, I think this is a pandora's box of requirements. I would try to stick to ONE of those, do a release, wait for the initial bugs, fix those, then work on another item.

 

[dullard]

Well I was hoping someone would be brave enough to wager a very rough estimate. But I'm not surprized that I'm too vague. EagleKeeper and Torpid, thanks for your replies. EagleKeeper, I'll keep your responses to #1 and #4 in mind for my own estimates.

Is there a better way of approaching an outside contract on this? Having never done such a thing, I have no idea of where to begin.

I pretty much want someone to glance over the code and see if there are any glaring problems. For example if I opened a file and didn't do 1,000 (exaggeration) error checks to make sure the file exists, isn't already open, etc. I want someone to look at my code and say, "hey that is a bad way of doing it" and change a few lines to much better ways of doing the same thing. The code works as it is, it just needs a good polish by someone who knows what he/she is doing.

I'm pretty sure I'll have no say in who does the work (boss's old friend wants to do it). I assume the work will be charged hourly. So, it is difficult to know if this person is slacking or working his butt off. I don't want to pay someone for 1000 hours of work that most people would think would take 10 hours to do.

Or instead of paying hourly, we could contract it out for one lump sum. But then is a sum of $X or 10*$X appropriate? How am I to know I'm not getting screwed? How is this normally handled?

I like Torpid's idea of doing one at a time, so that if I feel we were screwed on one part then we don't have to continue down the road. And it gives an incentive for the programmer to be honest to get more work.

 

[torpid]

I think you can get to a point where you can make estimates, but it is going to take some time on your part. For me the most important points would be #1 and #4, then #7 after those two. The UI one may not be as important as I am making it out to be, it's just a rule of thumb for me that the UI is one of the most important parts of a program.

If you want to get a better idea of #1, you need to rethink the requirements and then see where the app does / doesn't meet them.

e.g. for each field, what is the acceptable input? what will cause an error? what will cause corrupt data? if an exception occurs, what should the user see? what will the programmer need to know to fix it?

For me the answer to the last question is... as much as possible. What we do here is try to get a pseudo stack trace by having on error goto errorhandler, then re-raise the error with additional stack information. We also put line numbers in our code and reference the ERL property to see which line the error occurred on. There are some free tools that can automatically insert line numbers.

Also, as for validating user input, you need to think about how you will convey the error to the user, and whether your app makes it easy.

For #4, you could start with findind a few users who are decent representatives of people who will use the app. Ask them to use the app and talk aloud about what they are thinking when using it. Write down any mistakes they make, and anything they think aloud which is not correct. Once you have a general idea of what's wrong with the UI, you can then think about estimates. If it's just re-arranging buttons, labels, etc. it's not too bad. If it's more fundamental like too many windows / not enough windows / wanting things docked in tabs, it could take longer.

 

[EagleKeeper]

As the pseudo project manager (PM), you will need to get a grasp on the scope of the work.

Start a Project file (Spreadsheet or MS Project for example) and label each of the 7 items you stated in the original post. Then create/identify each sub-area that you discover in your attempt to get a grasp.
Dependencies between areas should be identified if possible.

A Fixed Price contract deliverable will require an analysis by the implementer of the work.
Your project tasks will be a start for them to figure out a reference of what you are looking for.
The scope of the work will need to be defined upfront.

A Time/Materials contract should require deliverables to be met for each item on the project chart.

All deliverables should have incremental releases to allow for customer/end-user evaluation and testing.
when a deliverable is released, there should be a fixed time stated for feedback. After that point, unless agreed on, the deliverable is accepted. This goes for documentation and well as code.

Each deliverable should be identified and documented.
First by the PM.
The contractor should have an independent document containing an explanation of what was changed, why the change was done, a test plan and the results of testing. Changes made within the code should be commented.

These guideline/requirements should be identified in the contract itself, with the option for the customer to relax (not waive) some items at the customer's discretion.

Without these protections, the quality of work and responsibility can be disputed.

Modification of the project items after the fact can become expensive in terms of time and $$$ when add-ons and out of scope items are included.