hi. another great column. the more i read of your management writing, the more i'm being deprogrammed of the classic engineer mentality that to become a manager is to give up interesting work. in a lot of ways, it seems a lot more challenging than coding.

here's a screwed situation you didn't mention that i'd be interested in hearing your take on.

feature X is holding up shipping the software. an engineer is working on feature X and panicking because he can't get it working. all of a sudden. he gets some advice from another coworker and proclaims to all and sundry than feature X is working. we take his word for it, because we don't have a test plan or acceptance criteria and all of that fun stuff in place. yet.

fast forward to 2 months later, and a maintenance release is being prepared. as we are no longer under a shipping deadline, we write a test plan and spend a few days testing the software. we shake out a lot of bugs and spend a month or so fixing them. in the process we discover feature X doesn't work, and couldn't have possibly worked in the original release either.

obviously we know 2 things : the engineeer who worked on feature X either didn't really test it or lied, and that nobody is using feature X.

what do you see as the screwedness of the situation ?

i'm torn between thinking High because we shipped with a non working feature, and a lower screwedness.. i suppose really it's Low right now because nobody is using the feature, but as soon as someone does and submits a support request, we go to ScrewedCon 1.