Friday, August 29, 2014

Dexterity open form return to is not causing the change script to run in the returned to field

Problem
I have two forms: Batch and MassAddTransactions. Batch has a button called Mass Add Transactions. This calls open form MassAddTransactions return to '(L) ProcessReturnFromMassAdd'. Then in MassAddTransactions the "Done" button does return true; The purpose of this is to signal the Batch window to fire the ProcessReturnFromMassAdd change script.

The problem is the change script is not firing!

Solution
My (L) ProcessReturnFromMassAdd field was a boolean. Changing this field to a Long Int, and then returning 0 to it caused the change script to run as expected.

This must be an undocumented requirement for using the open form return to statement, or perhaps it's a bug.

Tuesday, August 19, 2014

Get first on table returning results when it shouldn't be

Problem
I have a global script that is setting a range on a table then calling get first. This script is called multiple times during a transaction. The first time it's called it works as expected. The second, and subsequent, calls it produces strange results. The get first should not be returning anything, but it is.

Solution
Before setting the range call range clear table


Monday, August 4, 2014

Installshield prerequisite 32-bit vs 64-bit environment

For 32 bit

1. A registry entry has a certain value
2. Registry key name = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
3. Value Name = PROCESSOR_ARCHITECTURE
4. Value data = x86
5. Contains

For 64 bit

1. A registry entry has a certain value
2. Registry key name = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
3. Value Name = PROCESSOR_ARCHITECTURE
4. Value data = 64
5. Contains

Sunday, August 3, 2014

Project schedule and estimates

I started reading Joel on Software (the book, made from the website) a few months ago and just picked it up again recently. I left off on a chapter about specs, which I skipped over (which is probably why specs are so underused), and came upon the chapter on scheduling.

I like the simple, pragmatic method for creating a project schedule. Basically in a spreadsheet write down columns Feature | Task | Priority | Orig Est | Cur Est | Elapsed | Remaining

First, each feature needs to be broken down into tasks. Next, estimates should be given in hours. The more precise the unit of measure the more the programmer has to think about how they're going to accomplish a task. This naturally leads to developing a design. Tasks might even need to be broken down even more until they are no longer vague. This will naturally follow from precise estimates because it's easier to give estimates for concrete tasks.

So now we have each feature broken down into concrete tasks with estimates and a well thought out design. Who would've thought precise estimates could result in a well organized project?

In Pragmatic Programmer they said to use higher units of measure when giving estimates because "2 months" is alot more flexible than "50 days". When you say "50 days" they really, really expect you to be close to done in 50 days. Conversely, when you say "2 months" you can be off by a few weeks in either direction and it's fine.

Here's how I'm going to give both precise estimate and higher units of measure.
1) Use the simple spreadsheet method and break down features into tasks, giving very precise estimates in hours.

2) When it comes time to give my estimates to managers I will roll up the estimates from the spreadsheet for each feature and then translate it into a less precise unit of measure.

Let's say I am given a new project with 3 features. The first thing I'm going to do is write these 3 features into the spreadsheet in the format mentioned above. Then I'm going to go through each feature one at a time and figure out the steps needed to complete this feature. While doing that I'm going to write down the estimates. If I can't give a good estimate for one of the tasks then I need to break that task down further. As a boring example:
Feature 1 has 4 tasks for a total of 36 hours
Feature 2 has 10 tasks for a total of 60 hours
Feature 3 has 2 tasks for a total of 8 hours

I wouldn't present those numbers to a manager. First, i would translate it into a less precise unit of measure.
And remember, 1 day = 8 hours. 1 week = 5 days = 40 hours. Don't estimate with overtime taken into consideration, because then you're going to be expected to work overtime!

36 hours is roughly 1 week. 60 hours is 1.5 weeks. And 8 hours is 1 day. Those are the times I would give to a manager. Now the manager has good information for deciding what to tell the customer, and ultimately for deciding which features to keep and which to cut.

So that's how I'm going to use the precise project schedule estimates and also give the less precise estimates to managers.


There was an error in this gadget