Jim Conigliaro

Understanding the health of a project is often a challenging prospect.  A project has a number of moving parts - tasks, budgets, people, documents, etc.  Using all of these moving parts to figure determine the health of your project is not really that easy.   You may have all of your project plans, task lists, defect tracking systems and budgeting spreadsheets all lined up and in order.  You may be tracking every little detail of the project.  Now you get the phone call from the CEO … “How does project XYZ stand?” How do you respond?  “Fine?”  “Great?” “In Trouble?”  How do you know?  A lot of us use milestones to measure a project, but they tend to be widely spaced.  So, let me ask this again, right now, as of this moment, how do you know how healthy your project is?  A lot of my colleagues tend to go with their gut.  Based on everything they know about their projects, they will tell you how they feel the project is going.  It is

Speaking as someone who has been working on small to medium sized software development projects in small to medium sized organizations for the better part of the last ten years, I can tell you that Microsoft Project has been the bane of my existence.  I’m not saying the product is bad.  As software products go, it is a beautifully constructed application.  The problem is with how it is being used.

I've seen an alarming rise in a rather dangerous design pattern - one class per table.  Here's the gist of the pattern.  You have data driven application - database - business logic - presentation layer (3-tier) architecture.  So far so good.  Now, your designing your business logic classes and you choose to auto generate your classes in the business logic layer to have a one-to-one correspondence with the tables in your database.  This makes creating and maintaining your business logic layer remarkably efficient ... right?  wrong.

One of my software engineers just showed be some of the scariest code I've ever seen.  No, he didn't write it.  He was asked to help one of our clients identify a performance problem.  What should have been a relatively simple function was pegging the CPU on a remarkably powerful machine for 10 minutes solid.  After a little bit of detective work, he found this gem (well, something like it, I refactored to protect the guilty):

// DANGER - bad code!
public string StreamToString(Stream s)
{
    string output = string.Empty;
    byte b;
    while ((b=s.ReadByte()) != -1)
    {
        output += Convert.ToChar(b);
    }
    return output;
}

I've seen a tendancy to shy away from creating custom web controls.  User controls (.ascx), sure, I've sen plenty of those, but when it comes down to true, custom, web control, I see very few.

Part of the problem is that there is a misconception that they are difficult to write.  I'd like to dispell that myth with the following example.  I wanted to play around with flash, so I created a flash sub-title for my site.  To add the flash movie to my page, I justed needed the following HTML: