Types of dates

Just a brief note on the types of dates I have to deal with in software estimation.

Start date: Actually not as simple as it sounds. If you estimate something will take ten days, which ten days? I have seen a lot of arguing about when projects actually start.

Earliest date by which it can't be proven that it won't be done: DeMarco claims this is the easiest date to estimate, and the one most commonly used in scheduling. Frightening stuff.

Estimated completion date: Could be the product of some kind of parametric/statisical estimation, or engineered guess, etc. I think the pyschological effects of the estimated date are often underestimated. If the date seems unreasonably short or long, the behavior of the team will be affected. Often it is a huge mistake to express this as a single day, when the correct way of expressing the statistical truth is a probability range. Whenever I am asked for a 100% date, "when will we be guaranteed to get this set of scope delivered?", I just try to say something funny. The 100% date is meaningless, when so many projects are not completed.

Target or Goal Date: Usually a meaningless date created by management to inspire hard work, particularly if the previously mentioned estimated date is not good enough. Or, the date by which they will get whatever is done at that point in time. If you are going to attempt that strategy, you should begin doing timeboxed development from the start, so people know what to expect.

Date by which the project will be cancelled: Should be approximately equal to the day before the last date on which the project will still be able to have return on future investment- more ROFI than a replacement would (even if net ROI would be negative.) I like to ask the stakeholders for this one- and how many times have I heard that a crucial project that we are being asked to evaluate "can't be cancelled"? That kind of thinking is the kind of thinking that gets crucial projects cancelled!

Feature complete: The date by which the software has all of the features, but none of them actually work yet.

Actual completion date: Seldom reached. In development, is one ever really done? Even shrink-wrapped and shipped software usually has a patch or two ready to go before the first product hits the shelf.

This is why I prefer fixed increment, timeboxed development. It is so much easier to deal with scope slippages than time slippages. Scope estimation is the only way to go for the kind of projects I deal with.

Service Oriented Gridlock: Start with Stovepipes

Second in a series on Service Oriented Gridlock (SOG)...

If stovepipes are so terrible, why are there so many of them? Where did they come from? Well, the basic scenario is, the business wants some function, they call up the local Java, Excel VBA or Lotus Notes hacker and get it delivered to them. This can be a remarkably efficient way of getting things done. Someone wants something that is going to help them make more money, or accomplish their mission, and someone delivers it to them. The user is the primary focus of the development. Contrast this to the average enterprise project which spends a year gathering requirements, getting consensus from different groups about what priorities to do first, fighting about design and approved technologies among various senior architects, and then maybe delivers something that does about 50% of what the business need was, in a semi-usable form, and they probably don't even need it anymore. If I am a user, I want a stovepipe! I want a development project dedicated to me.

Service Oriented Gridlock: Introduction

While you will find person after person who complains about the existence of stovepipes, applications that deliver function directly to the user and are not integrated with other systems, there is also a danger in becoming overly coupled to existing systems. Service Oriented Architecture (SOA) is touted as a way of ensuring that the coupling between systems is as loose as possible. However, moving from stovepipes to coupled systems, even relatively loosely coupled systems, represents a move from independent projects to dependent projects, and introduces a great deal of schedule risk into projects that are under development. A move from stovepipes to SOA can introduce what I refer to as Service Oriented Gridlock (SOG) to an enterprise, where no application can be deployed without affecting other applications, resulting in a dependency chain that greatly diminishes the ability of capabilities to be delivered to end users (the thing which stovepipes excel at doing).

This post will serve as the first of a series where I delve into factors that lead to SOG, explain a better process by which stovepipe applications can extended to provide services, and show how SOA can be achieved while still retaining the benefits of stovepipes.

Google Desktop 2 (beta)

Okay, Google Desktop is back in the lead over Yahoo! Desktop Search.

Yahoo! had the advantage when they basically made x2 available for free, but now Google has the Outlook toolbar and the amazing sidebar. The sidebar is kind of a competitor to another Yahoo! buy, Konfabulator, with the panes a sort of less curvy version of the widgets. Downloaded the API, but I haven't checked it out yet. Maybe after I finish up with the Code Jam.

Servers, 64bit, dual core, AMD, and Dell

Not too far removed from the Apple switch to Intel from IBM/PowerPC, Intel really seems to be trailing AMD in the server market. The 64 bit Opteron is selling far better than Itanium. AMD has beaten Intel to market by months with dual core server CPUs. It's gotten to the point where Dell is selling the desktop dual core chip, the Pentium D, in its server models, since the Xeon dual core doesn't seem to exist yet. Even more telling, server software vendors are advertising Opteron 64 bit compatibility.

The most entertaining thing about dual core is how it effects the licensing of software products that are licensed per processor. IBM has started to relent, probably because they want to sell the dual core AMD machines while Dell waits for Intel. Oracle on the other hand, still wants double the cash for letting you use an upgraded processor capability that required no changes to their code.

So, I've got to buy a new server this weekend. Dual Core 64...
--------------------------
Sent from my BlackBerry Wireless Handheld

port blocking

I find the port blocking of my ISP, Cox Communications, to be a little confusing. Why do they block port 80, but not 443? And the claim not to block port 81, but I can't get to port 81...why? It's so difficult to debug when they have an unclear policy.

Still it's better than the old days.

C#, why?

There is something fundamentally weird about the existence of c#. According to monster.com and book sales, it's not popular. I think those numbers are skewed a bit because it a lot of HR and hiring managers just ask for “.net”. I don't know how someone could have skills related to the VM in general, but I suppose there are a few bytecode hackers out there that could write “.net”.

As I understand it, no one wanted them to fork Java, like they tried with J#, so they had one of the programming language greats whip up something similar with a different name.

Why does microsoft want a VM anyway? Won't c++ run faster? Were they actually counting on mono to provide write once, run (or crash) anywhere support? I think there are better ways of doing managed code.

So, my days of COM hacking are getting behind me enough that iUnknown is becoming I unknow. (Ugh) Still, I have fondness for the power of the monoculture approach. Why no one has written a javac for the .net vm is interesting...maybe I need to google that before I say it's true.

C# just isn't worth it. If you are a duffer you do vb.net and that's great. If you know what you are doing, you do c++. If your boss won't let you use java, you use c#.
If I had to choose between the three, I'd go for one that will be here in 10 years.
--------------------------
Sent from my BlackBerry Wireless Handheld

O'Reilly Connection

I signed up for the O'Reilly Connection site. I am hoping it will be a way to connect with some top developers. Unfortunately, we have some rather severe requirements for people that want to work on some of our jobs, so my guess is that there will be only a few people who will be eligible. I don't know if sites like this work that well. I also tried Yahoo!360, but that seemed too general. Why would I bother putting content there when it is so difficult to access, but not targeted to any specific group? I think once the content is identified as being for a particular target market, it does make sense to limit access. Limiting access gives people the freedom to reveal a little bit more about themselves, without opening the door to people who would use it against them. Well, I guess it actually does leave the door open, but if someone is being bad, at least the door can be closed to them.

Comparing Google Maps API and Yahoo! Maps API

Hari Gottipati's article for O'Reillys xml.com offers up a brief comparison of the two mapping APIs, as part of a tutorial on Google Maps that really doesn't add much to what google offers. I have to say that I prefer the Google approach, simply because you aren't putting in an iframe to a yahoo site. (Then again, what is that JavaScript doing to the DOM of my page? I haven't looked into it.) The JavaScript GMap class is nice container, and provides a nice black box to handle server communications and click events. I'd really rather rely on the JavaScript expertise of Lars' team over my own...somewhat dubious skill level with the language.

Over time I have been moving much further that I ever thought I would away from a purist OO mentality. The difficulty of programmatically generating code to run in web browsers has been a big source of that. I think it really has a lot to do with the heterogenous programming toolset need to do anything remotely interesting in a web application. Generating DHMTL from XSLT or JSP, as referenced by Java code is just a messy endeavor. Scripty hacks are a necessity.

Moblog test

The capability to post to things like this from a mobile device is a real improvement. After years of not being able to carry a wireless device due to workplace policies, constant connectivity is still new to me. I am liking it.
--------------------------
Sent from my BlackBerry Wireless Handheld

When does work become work?

014_11
Originally uploaded by mcknight.

So many people wonder about this...common answer: when it stops being fun. I am waiting for the day when my daughter doesn't want to vacuum. As it is now, she won't let me vacuum because she has so much fun trying to do it. How long does it remain fun for her? What happens when work makes the things that you used to find fun not fun anymore? All of a sudden you can end up in a place where nothing is fun. And that's no fun.

Maybe it's not so great to find vacuuming fun for long. I think people who are in the position where the things that they find fun are their work. But vacuuming is definitely going to the robots. Not a growth field over the next 30 years.

Focused Try

I am making a another focused attempt to be more productive. 5 short project plans due in the next 6 days. It will be an interesting test to see if I can do a reasonable job on those, and handle spending some time on the things that I really want to do.

Keeping Up

It is difficult to keep pace with the ever advancing wave of things other people are doing while trying to do things oneself. Indeed, just reading about all of the other things people are doing makes me wonder where they find the time, they must not be keeping up with what everyone else is doing.... I think there needs to be a shift in the balance in my life towards the doing side, away from the keeping up side.

This was triggered by having feedreader deliver to me a description someone having done a part of what I was trying to do