Google Calendar

Google Calendar is just another example of why that company blows my mind. When every peice of software you develop is perfect, even investors dont care that your entire revenue stream is ad-driven.

Why Programmers Usually Make Bad Project Managers

or
Thinking like a business sponsor

I think it's a fairly well established fact that engineering types in general, and software developers in particular, don't make very good project managers (with the notable exception of many of my Finetix coworkers). This especially holds true for the types of projects that they excel in from an engineering perspective- complex problems involving lots of variables and esoteric mathematical requirements.

I am going to go out on a limb here and suggest that the biggest mistake that techies make is that they tend to operate solely at the machine level. Project management requires you to forget about the immediate technical hurdle, turn off your computer, get up out of your chair, walk around, and talk to the people who use your software. It works better if you bring them a picture of how you currently envision the software's architecture/user interface/whatever (thanks John).

Solving software problems is different than solving people problems. Software problems are nice tidy little things, with elegant solutions that you can squeeze into a 64K ROM chip. Human solutions are never that simple- especially in software, when you are very likely eliminating someone's job by making it automatic, or making it so easy that a high school intern can do it. Also, in project management you sometimes have to cut corners and get the easy wins, even if your engineer's instinct for elegance cringes.

Earlier, I make a special distinction for software developers. The reason for this is that software is so easy to change- you don't have a physical product whose shape, or electrical requirements, or weight you have to take into consideration. Its the rare software these days that cant run on basically every desktop machine out there, so if you want to use that fancy new framework that takes up 20 MB of RAM on top of your application, go ahead. This flexibility tends to make software developers (the better ones, anyway) perfectionists about their code, but that same instinct will kill you when you need to ship a product. Unless you work for NASA, where your code literally has lives at stake, it will benefit your users more to have a product that works 90% of the time than a product that works 100% of the time 6 months or a year later.

After all, that how Windows came to be ;-)

In keeping with my blog's title...

Chris Taylor blogs on string comparison methods. Coming from a VB.NET background, I dont usually think about things like value comparison versus reference comparison- in VB.NET they are very different things (implemented with the Is/IsNot versus = operators respectively- see This Guy's Blog for more info on why this came to be). C#/Java folks take a harder look at this sort of this however, and today John and I got into the discussion of why the following works in C#:

/*
Commented out in response to a correct, if rude, commenter.
If you cant make your criticism politely, please keep it to yourself. I wont publish it.

if ("a" == "a") //Always true
*/

if (string1 == string2) //Assuming these two are equal
{
...
}

Apparently, the C# compiler turns the == operator between strings into the string instance op_Equality method. Whats more interesting is that apparently op_Equality is implemented very differently than String.Equals (Instance Method), and String.Equals (Shared/Static method), reulting in a significantly different response time between the three. I'll have to break out Reflector and examine this further once I get some free time...

First Day

Today is my first day at *the client*. 3 monitors, 2 cpus, and best of all, a real aeron chair. :-) Plus the cafeteria is amazing.

More to come.

The Devil's Advocate

Kathy Sierra, Author of "Creating Passionate Users", blogs on The Devil's Advocate

On Workflow

Workflow is king. That would be my prediction for software development in 2006. Business workflow software is a logical extension of the SOA paradigm that has taken hold in the modern business software development world, due to the following driving forces:

1. Increased interoperability of services on different platforms.
   
2. Management/operations pressure for centralized management and automation of services.
3. Legal requirements for centralized logging and auditing of software applications.

Workflow software is situated in a unique role to solve all of these problems. Web services (generally) communicate via the SOAP/XML protocol stack and therefore tend to allow for serialized state which can be captured and parsed by a workflow engine which in turn makes decisions about what other services need to be called next (think BizTalk in the MS stack). This idea has already taken hold under a different name: Enterprise Service Bus (ESB). Googling this term yeilds over 34 million results, including hundreds of vendors vying for this product space. The general concept of an ESB is a centralized peice of software which allows for management/orchestration of all of the various web services in an organization. This in theory allows developers to work in isolation on their various projects, allowing a central team of architects and business analysts to peice together the assorted services into logical applications, or workflows.

In all organizations, the IT department needs a window into the day to day operations of various applications at many levels. This allows for operations support, usage reporting, scalability and hardware planning, and change impact analysis. In silo applications, this insight is provided on a per-app basis using whatever monitoring tools are provided by the developer (for better or worse). The workflow software on the other hand can be closely integrated with both the application stack as well as the platform itself, and since it is a shrinkwrapped piece of software the assumption is that a reliable vendor will provide a comprehensive reporting platform that provides information on both the health and the usage of the applications that integrate into the engine as well as the platform it runs on.

Finally, Sarbanes-Oxley legislation now requires that all public companies undergo a rigorous auditing process that requires they examine and log all activities. In IT, this means a major headache in terms of change management, logging and instrumentation of legacy systems, storage complications, and additional reliability testing. A well-designed workflow application can provide a single location for many if not all of these, including a repository for change management or workflows themselves. Each transaction can be tagged and recorded without changing existing business logic, and future changes to legislation should not have as great an effect on IT infrastructure.

More to come...

Undocumented SP's in SQL 2000... These are definately not suggested for production app use, but for DB admins they are crucial:

http://www.mssqlcity.com/Articles/Undoc/SQL2000UndocSP.htm

.NET Network Connections (or Banging My Head Against the Wall for 6 Hours)

All .NET Applications (including ASP.NET) that initiate external network connections are constrained to a limited number of simultaneous connections, defined in the connectionManagement element of the machine.config file. This section, by default, allows 2 (that's right, 2) simultaneous outbound connections. This does not refer to ASP.NET inbound connections, but it does apply to the following:

1. Outbound Web Service calls
2. Outbound SMTP calls
3. Outbound TCP/IP socket connections

For anyone writing a multithreaded, high speed application, particularly windows services to handle message queues or to send email (my situation), keep this limit in mind. If I find any way around it short of changing the machine.config, I'll post it.