Resource Allocation

I’m going to talk about resource allocation.  This is where you (as an IT manager/CIO decide which people to combine into your team).  When I started designing software I used to estimate the software, define a deadline and then divide it by a 8 hour work day to determine how many programmers I needed.  Over the years, I’ve learned a few things.  One important issue to understand is that a mixture of different expertise can be a cheaper way to build software.

The reason why this is true is based on the fact that people must wear different hats to perform all the tasks it takes to run a software shop.  Especially if you are also attempting to provide services for existing software.  I’m going to start with a very simple example.  This is, of course, an example that I made up and it might not work in your situation.  I’ll show you how to build the numbers to determine if a different mix of people will help your projects bottom line.

Here’s what I’m starting with:

What I’ve done is setup a project that requires about 1000 man-hours of labor to complete (the total coding hours is shown as 930 above).  The total time it will take the three programmers is 600 hours (they’re all working 600 hours in parallel).  Or about 4 months (OK, it’s 3.75 months, but I’m trying to keep the numbers even).

If you’re looking at all the daily tasks listed, you’ll immediately notice that these three programmers are spending a lot of time on help desk, paper work and debugging.  So my question for this simulation is “what would happen if we replaced one programmer with a help desk/debugger guy?”

Help desk is taking about 240 man hours away from coding and debugging is taking 450 man hours.  That’s a really large chunk of production time.  Plus, it’s a little more than the 600 hours that the extra programmer is taking over-all.  I’m going to ignore the paperwork time and assume that 10% is normal for all employees of this particular department.

Here’s the new spreadsheet:


OK, so I re-tasked all the help desk calls to the new help desk/programmer and I allocated some of the debugging.  In reality, this person might not be as efficient at finding and fixing bugs as the programmers, but the numbers should still hold up.  Notice how the programmers have been able to do 1020 man-hours of coding in a 600 hour time-frame.  That’s better than the mix of people above.

There is also one more consideration here.  You will want to sink your money into some really good programmers and possibly hire an intern or maybe someone straight out of college for the help desk/debugger position.  This will be cheaper than hiring three expensive programmers.  Your project will still be delivered on time.  Also, the moral of your programmers will be high because they don’t have to deal with help-desk calls. 

Conclusion

OK, so I’ve shown a really simple example.  In more complex examples it’s possible to separate programmers by specialty.  If you can get a mix of programmers that have strengths in different fields, say interface design, business code, database design and mix them in a team where each can focus on their skilled area.  You can benefit from the strengths of all of them combined. 

Also, you might be asking yourself, “where did you get all those numbers for that spread sheet?”  I got the numbers from metrics.  Each person will enter their time into a time tracking system (computerized or on paper), then I roll up their times per week to get their average percentage.  I do this all the time for my employees so I see where their time is being allocated.  These percentages are then used to estimate how long it will take for my development team to complete a project.  It’s not as easy as saying “160 man hours / 2 people = 80 hours, errr, 2 weeks!”  You have to account for percentage of time allocated to the actual task.  The rest is what I consider waste.

 

Software Development Disasters

If you’ve designed and built software for as long as I have (more than 20 years), you’ll have a whole lot of experience dealing with disasters.  I’ve had a couple in my lifetime that could have been expensive disasters if not for my knowledge of trading stocks.

You see, there’s this little secret to trading stocks, and it’s the one technique that separates the chaff from the wheat.  Knowing when to cut your loss.  That’s right.  You’re going to run into something some day when you’ll just have to know when to quit.  If you can see the disaster coming early enough, you can avoid the cost of the disaster.  Sort of like seeing a tornado far enough in advanced to jump out of the way.  In the case of stock trading, you need to cut your loss before you lose too much money.  In the case of software, you need to cut your loss as soon as it starts to look like a loser.

Enough of the metaphors, time to get serious.  The number one thing you need to do when designing and estimating is break your software project into the smallest pieces possible.  Then estimate the tiny pieces and roll it all up.  If you have a chunk of software that is kind of gray in your head, you’ll need to focus on that piece and maybe do some mock-ups or a small and cheap demo.  When you have your numbers, your resources are in place, you’re authorized to start the project, then you need to actively track your progress.  By the time you’re 5% into your project, you should start to see a pattern emerge.  Is it behind schedule?  Is it really behind schedule (more than 20%)?  How do the tasks that are currently completed compare with the tasks left to do?  If the remaining tasks are comparable to the tasks that have been completed, then you’ll never finish within your budget.

Let me clarify what I’m talking about here.  I’m not talking about meeting a scheduled deadline.  If your company needs this software and is willing to just throw more money at resources, then you should attempt to throw in more resources early on to get ahead.  However, most companies base their software development on ROI.  Than means cost.  So being behind means that either you have to work your current programmers more hours and pay them more, or you have to work more programmers which costs more (I know, that’s really obvious, except “programmers” don’t think that way).

So you’re already behind schedule and it appears that the project is going to go into ugly territory.  In other words, it looks like the whole thing will probably cost 1.5 to 2 times as much as originally estimated.  What do you do? 

The first thing to look at is the features that this software will contain.  Are there any features that have questionable value for the customer?  Maybe you can trim back on those and make up the difference.  The ROI will come out the same if the value of the overall software package is perceived as the same.  Maybe the software you are developing has only 5 primary features and all other features are secondary in nature.  It’s possible that you could defer these features to a future version of this software, say, after the profits start rolling in.

Let’s say that your software is cut to the bone.  It’s lean and mean and any feature left out will reduce it’s value as a package.  Like leaving out the accounts payable section of an accounting package.  Just can’t do that.  Now what do you do?  This is the point where I usually think about cutting my loss.  I would build my supporting evidence, show my projection of how much this project will cost to the people who authorized the funding.  Then give my recommendation.  Maybe they will think it’s worth the extra money.  Maybe budgets are tight and the funding will not be available to complete the project.  If that happens, then it’s ALL STOP! 

Fortunately, you’ve put a stop to potential loss.  Now you can re-evaluate the project and possibly use a different technology.  Maybe the interface is not worth the effort and an easier to build interface could do the trick.  Maybe a different programming technique can be used to make things easier.  Programming tools?  Different mix of programmers?  There are so many options at this point.  Fortunately, you’re not bleeding money while you’re re-analyzing the project.

Cutting your losses is not necessarily a good thing.  Sometimes you have to go with your gut, grit your teeth and push through.  If the remaining tasks in your project appear to be easier than the tasks that were completed, you can probably pull it out of the fire (assuming you’re not too far behind).  Don’t be too averse to risk or you’ll never finish a project.  I’m just telling you that you should be aware of your situation at all times and never ride a disaster into the ground.

 

Spam

Spam – Sheesh, Are They Kidding?

I get spam every now and then.  I used to get a lot but we have a really good spam filter (Barracuda, by the way).  But I’ve been receiving spam since I signed up for email back in the early 90’s.  I’m so familiar with the social engineering tricks that the “spammers” use that I can smell a spam message the instant I view it (many times I only have to see the title).  They’re pretty clever, but not real clever.

This spam message I just had to blog about.  Why?  Because it cracked me up.  OK, here’s a screenshot of the email:

 

Oh yeah, they had me fooled up until I realized that I didn’t book a flight (sure they did).  I started to crack up, since the dominant airline in my area is Delta, and I haven’t flown since last Fall and I have not plans to fly any time soon.  Anyway, I was curious, how this was setup, so what I normally do is hover my cursor over the “download it” link.  That’s obviously, where they’re going to execute a Trojan horse and make my life miserable (so I’m not going to click on it).  Here’s what I got:

 
So the address goes to gentedecente.com.br.  Which is a Brazilian domain name.  The “.com” part in the middle is clever, to kind of distract the eye from noticing that it’s NOT a dot com address.  So I decided to check if anybody else is receiving this particular spam and I typed “airline ticket email spam” into Google and it looks like it’s so common that there are different variations and American Airlines is already aware of the problem.  AA has a webpage describing the scams and that you need to be cautious.
 


One other thing I did to see why this got past the spam filter, is check the return address.  It was from ticketlesstravel.com.  Which happens to go to a web hosting company, but no site.  That’s a dead-giveaway.  They could have at least bought a fake site or linked it back to a real site.  Maybe, I shouldn’t give pointers here…

 

Accessing the Clipboard from Javascript

Accessing the clipboard from JavaScript,
or how to implement copy and paste of a web page

I almost forgot about this feature until the other day when I was consolidating data records.  I scratched my head and said “gee, wouldn’t it be nice to just hit a copy button, navigate to another record and press the paste button and have all the text fields filled with the data.”  Then I remembered that I’ve used the system clipboard before.  So I dug around my code and came up with this little gem:

function CopyToClipboard()
{

    if (window.clipboardData && clipboardData.setData)
    {

        var laFields = Array(‘txtName’, ‘txtAddress1’, ‘txtCity’);
        var lsResult = ”;
        for (var i = 0; i < laFields.length; i++)
        {
            var lsFieldData = document.getElementById(laFields[i]).value;

            if (lsResult != ”)
                lsResult += ‘|’;

            lsResult += lsFieldData;
        }

        clipboardData.setData(“Text”, lsResult);
    }
}


function PasteFromClipboard()
{
    if (window.clipboardData && clipboardData.getData)
    {
        var lsData = clipboardData.getData(“Text”);
        lsData = lsData.replace(/(rn|n|r)/gm, “”);
        var laData = lsData.split(‘|’);

        if (laData.length > 0)
        {
            var laFields = Array(‘txtName’, ‘txtAddress1’, ‘txtCity’);

            for (var i = 0; i < laData.length; i++)
            {
                document.getElementById(laFields[i]).value = laData[i];
            }
        }
    }
}

The code here is obviously JavaScript.  The “CopyToClipboard()” function should be called by the onclick event of the copy button and the “PasteFromClipboard()” function should be called from the onclick event of the paste button.

This sample is looking for three fields (The actual routine copies a dozen fields, I cut them down for this sample).  The fields are named “txtName”, “txtAddress1” and “txtCity”.  You can also implement this by using a document.getElementsByName() call and iterate through all the input objects.  In my case, I simplified by specifying the id names of the input boxes I want to explicitly copy.

I used the pipe “|” symbol to separate values since there is the possibility that the data might contain commas or dashes.  Pipes are rarely used in text entry fields.

When you use this code you can click on the copy button and then open MS Word (or textpad) and paste into an empty sheet.  You’ll see your data separated by pipe symbols in one line of text.  You can edit this text and copy it back to the clipboard and then paste into your form.

There are some complications with various versions of browsers.  I noticed that this does not work for opera, firefox or chrome.  I’m still looking into the details of how to fix this problem, but for now I use this in IE (our customers are in-house people using IE 9).

For a more detailed discussion of accessing the clipboard from JavaScript, I would recommend this article: