Log in

No account? Create an account

Previous Entry | Next Entry


weather: cloudy
outside: 9°C
mood: meh
This kind of thing happens All. The. Time. In software development.

So, the non-technical Project Manager on the client side was freaking out at the end of last week. We vaguely had the idea that he was very concerned about our bug count, but we couldn't really understand why he was all of a sudden so distraught over issues we had known about that we were making good headway in fixing. None of them were show-stoppers or anything.

It turns out they had run a code diagnostic tool on all the components of this project, ours and theirs. This is the type of tool that goes through the source code and detects potential memory leaks, potential problems caused by unhandled cases, unhandled states, etc. It's generally a good thing to have done on your source code, I don't deny that.

The tool generated a whole pile of things and logged each one as a separate bug. So, now our bug count has gone through the roof and that's why their PM was shitting bricks.

These are under-the-hood engineering issues. Most of these "issues" are actually quite harmless in that the chances of them happening is slim to none. We're not checking for this state? Well, no, because we'd never get to that state, the world would end before it gets there. We, as humans, know that; but the diagnostic tool that is not a human, is set to flag those as "OMGWTF". To fix it and check for the extra state is fine and dandy, makes for cleaner code, but it would make absolutely no difference in the way the application runs.

It's not that we're balking at having to do piddly cleanup work. It's that there are a lot of these and to fix them all would mean carving out time in our already compressed schedule to fix something that is not visible and won't matter. It would also mean doing a full regression pass because it touches so much stuff. Historically, they've been jumpy about being able to see results from us.

It would have been wonderful if these bugs had come in during a Bug Fix Phase of development earlier this year, not at the home stretch of Major Feature Implementation Phase. <sarcasm>But, that would have, like, made sense and we just don't do that.</sarcasm>

It's not a big deal. It's going to take time and PR to placate the non-technical Project Manager. And, really, if this is the worst thing that he's shitting bricks over, we're doing really well.


( 16 comments — Leave a comment )
Mar. 15th, 2004 12:01 pm (UTC)
It would have been wonderful if these bugs had come in during a Bug Fix Phase of development earlier this year, not at the home stretch of Major Feature Implementation Phase. But, that would have, like, made sense and we just don't do that.

Ohmigosh, do I ever feel for you. I'm a stickler for good planning before the project starts, my company however, isn't. So find myself constantly stomping my feet and getting really pissed off when my projects are consistently made to do 180's in the middle of the project. Or when I'm almost done, and someone says "Oh, but can we change this?" GAAAAAAHHHH!!!

I'm working on this fairly large project now, and I made them come up with a super detailed and comprehensive requirements document, and said that if they were going to make any super huge changes they needed to do it before I started coding, AND if they had any super huge changes later, we could call that Version 2 and do it later. Heh.
Mar. 15th, 2004 12:06 pm (UTC)
Absolutely. And the reality of it is, non-technical people really have no way of telling what is an easy, trivial change and what is a major architectural re-work. Usually, they get better at guessing as the project progresses, but generally, they just have to throw everything at you and hope it's easy.

What I do is I get them to log it to the issue tracking database so that I can write it into the notes that "this will take me _this_ long to do, would you like to extend my deadline or postpone this for Version 2?" or "this is easy and can be done by tomorrow".
Mar. 15th, 2004 12:06 pm (UTC)
Well... except in all fairness that's the sort of thing the devs who wrote non-y2k-safe code said too, Oh, this code'll NEVER get past 1999, they'll have rewritten it years before then. That sort of thing.

Not that I'm saying you guys are doing that, but it IS better to just clean up those things rather than leave them even if it is impossible that it ever reach those states in a reasonable universe... mainly because the universe is anything but reasonable and users are alternately stupid and malicious and if you don't actively work to combat them, they'll break your stuff. :)

But I know, I'm lecturing to someone who doesn't need it, I just can't help since I'm on the team that gets paged when (other) developers say stuff like that and then, despite the odds, it happens and stuff breaks. So having been burned by "impossibilities" before I tend to be paranoid. ;)
Mar. 15th, 2004 12:10 pm (UTC)
I know exactly where you're coming from and I _am_ the proverbial choir =) I did 24 hour technical support too and I've been hauled out of bed at all ungodly Pacific hours for a client on Eastern time.

It's a matter of "would you like to extend my deadline?" or "what features would you like to cut from the implementation list so that these issues can be resolved?". =)
Mar. 15th, 2004 12:57 pm (UTC)
You have nmy sympathy. It's amazing what happens when the lay people, who have to know what is going on, actual learn what's going on. But of course, they only think they know what's happening because they've heard the vocabulary before.

Have you ever heard of or used the Extreme Programming Method? This is the kind of problem that Extreme Programming eliminates.
Mar. 15th, 2004 01:11 pm (UTC)
I have heard of Extreme Programming. My impression is that some of it is insane, but some of it makes sense. We do use some elements of it here but only in that it's convenient and it actually helps. So, according to their definition, we're not doing it right. =)

Client expectation management is something that has to happen on an ongoing basis. I'm not sure how anything is going to eliminate that.
Apr. 7th, 2004 12:21 pm (UTC)
Oh, Extremem Programming handles client expectations quite well. that's built right into it.
Mar. 15th, 2004 04:49 pm (UTC)
our project is undergoing security audit.....looks like they might make us make do major architectural re-work. and it's already in production. lol.

Mar. 15th, 2004 05:16 pm (UTC)
Mar. 15th, 2004 10:34 pm (UTC)
Interesting. There is always one person who seems to hit the *panic button* one time too often. =P.

But what can you do. =P --Ray
Mar. 15th, 2004 10:35 pm (UTC)
But what can you do.

*sigh* Exactly =P But, he'll learn. Eventually. =}
Mar. 16th, 2004 12:13 am (UTC)
Reminds me of the story of the *boy who cried wolf*. Ironically, it occurs more often than not. But I think in many ways, panic and worrying too much is better than not worrying at all, if we talk about the extremes.

But then again, there's no price for experience. --Ray
Mar. 16th, 2004 06:43 am (UTC)
I have never been able to figure out why people are given the job of manager(project or otherwise) when they do not have the understanding of how the jobs work. It used to be that my manager could do anything in my job description. Now managers seem to be chosen by how much they can kiss up to their superiors with no thought given to having them be able to the do the jobs of the people they manage.

Hope you do not kill your project manager before your job is done!
Mar. 16th, 2004 07:56 am (UTC)
Re: managers
A lot of the time, our Project Managers are responsible for managing resources (people, tracking project hours for billing, putting together the on-fire presentations to convince the Board of Directors that the project is worthwhile, will make millions, need funding, etc.) Most of the time, they're not technical.

You get people with varying technical ability because they can come from either a Sales/Marketing background and discover they have a knack for technical issues or they're a technical person with a knack for resource management and people ability.

The senior technical person is usually the Development Lead.
Mar. 16th, 2004 03:57 pm (UTC)
Welcome to what I have to deal with on a weekly basis.

Ben (http://concept.blogspot.com)
Mar. 16th, 2004 04:38 pm (UTC)
*sigh* You have my sympathies =) Actually, no, you don't. Will does. And I get an earful every night on the way home. So, in fact, _I_ have my sympathies =D
( 16 comments — Leave a comment )


The Bride of the First House

Latest Month

March 2015