The panic started about nine o'clock this morning, with an impromptu meeting at my cube. Several members of the Qual team suddenly appeared, their faces adorned with what can only be termed as 'concerned' looks.
"Is there anything we can do?" they asked earnestly.
I resisted the urge to tell them to go away, which was the best thing they could have done. But their concern was genuine and heartfelt and overriding, and completely trumping any intelligent thoughts that might have been going through their heads.
"No, no, I've got it all under control," I lied. Please go away, I intoned under my breath. Go away and leave me alone before I start screaming.
With these and other words, I placated them for the moment, and they left, and then I was able to put my thoughts back in order so as to continue my task - which was to produce, by Friday, a successful run of the software on the target hardware. We've never gotten the software to run completely without failing something. That's the trouble with this complicated system. There are too many ways to fail, and we haven't found nearly enough of them.
The code itself is a nightmare. It was kludged together by a disparate team of uncooperative developers under extreme schedule limitations nearly a year ago, and then it languished in limbo when the budget was slashed; then it was resurrected four or five months ago by a new team in an attempt to update it for the current requirements (which were a major departure from the previous ones). But instead of cleaning up the mess, the new team merely tacked on new functionality, which made it even more complicated.
And then I was brought on board because the Person In Charge was overwhelmed. Imagine that!
So now it's Crunch Time, and everyone wants to help by getting in the way. That's the main problem with software development managers. They think that the best solution to any schedule problem is to throw more people at it. {"If one woman can produce a baby every nine months, then nine women can produce one baby every month..."} Notwithstanding the Learning Curve. It took me three months to get familiar enough with the software that I didn't break something every time I made a change - and I'm still not as familiar with it as I should be.
This week's panic is due to the fact that the ATP (Automated Test Procedure) has to be done by Friday, or else we cannot start manufacturing and testing (and therefore "selling") these units. And the ATP is dependent on this sofware. And this software isn't done yet.
Not by a long shot.
More caffeine, please.
Wednesday, May 30, 2007
Tuesday, May 29, 2007
Memorial Day
It turned out to be a gloriously beautiful Memorial Day.
The sky was blue, no clouds in sight, the temperature was just right for an afternoon trip to the pool.
And I spent the major part of the day at work.
Nothing was accomplished, of course, other than digging a software hole so deep that it will be difficult to climb back out of it. The part of the software that was broken, is so deeply embedded in the core that all attempts to fix it cause the entire structure to come tumbling down.
It was giving me a fierce headache.
So I took a break in the afternoon to go to the pool with the girls, our first venture into the neighborhood pool for the summer.
Thus the best part of the day was spent at the pool, watching the girls in their new skirted swimsuits splashing and diving in the clear-blue (over-chlorinated) water; and the boys cavorting like dolphins.
A perfect break from an otherwise unproductive day.
The sky was blue, no clouds in sight, the temperature was just right for an afternoon trip to the pool.
And I spent the major part of the day at work.
Nothing was accomplished, of course, other than digging a software hole so deep that it will be difficult to climb back out of it. The part of the software that was broken, is so deeply embedded in the core that all attempts to fix it cause the entire structure to come tumbling down.
It was giving me a fierce headache.
So I took a break in the afternoon to go to the pool with the girls, our first venture into the neighborhood pool for the summer.
Thus the best part of the day was spent at the pool, watching the girls in their new skirted swimsuits splashing and diving in the clear-blue (over-chlorinated) water; and the boys cavorting like dolphins.
A perfect break from an otherwise unproductive day.
Sunday, May 27, 2007
The Rain has Stopped
It's a glorious blue-sky day outside, and I'm sitting at my desk trying to get things to work.
Yesterday's attempts were futile. The new kernel didn't boot. The debugger wouldn't attach. The software wouldn't talk over the Ethernet.
Today's attempts will focus on getting everything else working, and perhaps tomorrow there will be time to worry about the new kernel again.
But I'd rather be home watching an old movie. Or at the theater, watching a new movie. Or in bed, sleeping.
Yesterday's attempts were futile. The new kernel didn't boot. The debugger wouldn't attach. The software wouldn't talk over the Ethernet.
Today's attempts will focus on getting everything else working, and perhaps tomorrow there will be time to worry about the new kernel again.
But I'd rather be home watching an old movie. Or at the theater, watching a new movie. Or in bed, sleeping.
Saturday, May 26, 2007
While the cat's away...
I just returned from another trip out to the West Coast, this time for a far more pleasant reason than the last - a (re)marriage celebration instead of a funeral.
In my absence, a certain software release was supposed to take place back here at the office. This software release was supposed to establish for us a major baseline, a "stable" set of code that would allow our customer to begin their testing and thus gain confidence in our product.
I had hoped that the release would go well, that the baseline would be stable, that the testing could begin. I was sadly mistaken.
In my absence, the person on whose head I laid the responsibility to build and test and thereafter release the aforementioned software, failed to do so. That is, he built the software, tested the software, and released the software, but owing to his inability to fully comprehend what he was doing - and lacking any initiative to try and figure out what he was doing - the release was not as functional as it needed to be.
Thus when I returned, there were (almost literally) a swarm of people hanging around my desk, waiting for me to arrive.
In other circumstances, this would be enjoyable. They were looking forward to my presence. They awaited my return with eager anticipation. They recognized my value to the team.
But ... my value to the team is not supposed to be based upon what I can do to fix the problems; it is supposed to be based on my ability to lead others to find and implement the solutions. And my inherent distrust in the abilities and motivations of others led me to attempt to solve all the problems myself instead of taking the time and energy to train them to do it instead.
Admittedly, we are understaffed, overworked, badly scheduled, poorly funded, miserably managed, and completely unmotivated; and my current staff is mysteriously uninterested in transitioning from the pure software world into the mixed-bag environment of real-time systems, where a desire to play with the hardware is an imperative. Yet there is still a huge feeling of guilt hanging over me for my lack of ability to motivate them towards that area.
I had hoped to find in my staff some kernel of curiosity that would pull them toward the Dark Side of wires and switches and circuits and processors; we had spent several hours in the lab prior to my departure, reviewing the procedures and practicing the mechanical actions which were required to perform the tests.
But the fact remains that some people prefer the virtual world of the pure computer programmer rather than the dirty world of the practicing engineer, and, left to their own devices, will spend the majority of their time trying to find syntactic errors in their code rather than going to the hardware and discovering that (for example) a wire is not connected properly.
I cannot imagine a life as a "pure" software engineer with no understanding of the hardware upon which it runs. That is like knowing how to drive a car but having no ability to figure out what's wrong when the engine doesn't start.
But that goes back to my original problem. I don't like depending on people. I don't trust that they will get the job done. I want to be able to do everything myself so that I don't owe anyone anything, and I don't have to wait on them to finish, and don't have to fix what they screw up.
Unfortunately, that's what society is based upon - learning to depend on others, trusting that they will do what they are tasked to do, and being extremely patient with them when they are slower than one would prefer (just as one would hope for some patience from others when the roles are reversed!).
Things didn't work out this time, and as a result, I'm spending the Memorial Day weekend here at work, trying to fix all the things that didn't get fixed in my absence.
Oh, well. At least it's raining outside, and it doesn't hurt so much to be inside.
In my absence, a certain software release was supposed to take place back here at the office. This software release was supposed to establish for us a major baseline, a "stable" set of code that would allow our customer to begin their testing and thus gain confidence in our product.
I had hoped that the release would go well, that the baseline would be stable, that the testing could begin. I was sadly mistaken.
In my absence, the person on whose head I laid the responsibility to build and test and thereafter release the aforementioned software, failed to do so. That is, he built the software, tested the software, and released the software, but owing to his inability to fully comprehend what he was doing - and lacking any initiative to try and figure out what he was doing - the release was not as functional as it needed to be.
Thus when I returned, there were (almost literally) a swarm of people hanging around my desk, waiting for me to arrive.
In other circumstances, this would be enjoyable. They were looking forward to my presence. They awaited my return with eager anticipation. They recognized my value to the team.
But ... my value to the team is not supposed to be based upon what I can do to fix the problems; it is supposed to be based on my ability to lead others to find and implement the solutions. And my inherent distrust in the abilities and motivations of others led me to attempt to solve all the problems myself instead of taking the time and energy to train them to do it instead.
Admittedly, we are understaffed, overworked, badly scheduled, poorly funded, miserably managed, and completely unmotivated; and my current staff is mysteriously uninterested in transitioning from the pure software world into the mixed-bag environment of real-time systems, where a desire to play with the hardware is an imperative. Yet there is still a huge feeling of guilt hanging over me for my lack of ability to motivate them towards that area.
I had hoped to find in my staff some kernel of curiosity that would pull them toward the Dark Side of wires and switches and circuits and processors; we had spent several hours in the lab prior to my departure, reviewing the procedures and practicing the mechanical actions which were required to perform the tests.
But the fact remains that some people prefer the virtual world of the pure computer programmer rather than the dirty world of the practicing engineer, and, left to their own devices, will spend the majority of their time trying to find syntactic errors in their code rather than going to the hardware and discovering that (for example) a wire is not connected properly.
I cannot imagine a life as a "pure" software engineer with no understanding of the hardware upon which it runs. That is like knowing how to drive a car but having no ability to figure out what's wrong when the engine doesn't start.
But that goes back to my original problem. I don't like depending on people. I don't trust that they will get the job done. I want to be able to do everything myself so that I don't owe anyone anything, and I don't have to wait on them to finish, and don't have to fix what they screw up.
Unfortunately, that's what society is based upon - learning to depend on others, trusting that they will do what they are tasked to do, and being extremely patient with them when they are slower than one would prefer (just as one would hope for some patience from others when the roles are reversed!).
Things didn't work out this time, and as a result, I'm spending the Memorial Day weekend here at work, trying to fix all the things that didn't get fixed in my absence.
Oh, well. At least it's raining outside, and it doesn't hurt so much to be inside.
Wednesday, May 09, 2007
End of One Era, Beginning of Another
I don't like to think of myself as a work-obsessed person, but it is becoming more and more apparent that the possibility exists, especially when that work has some measure of enjoyment attached to it. My current work assignment has just such an enjoyable aspect, that of writing some really cool code and making it work with some really complex hardware. I could do this forever and not get bored.
But ...
I took on this job because someone else was overloaded and couldn't get it done. And the job was not given to me with the intent of forcing me to spend countless hours writing code. In fact, I was given a team of six people to do that part of the job. My task was to manage these people, to push the project forward from its stalled position, and get it done in the allotted time. (It was already way past budget.)
And I'm proud to say that this is nearly accomplished. We have made our milestones. The product is functional, and nearly complete.
But ...
I can't stop going back and cleaning up the code. It was a hack to begin with, and I can't stand hacked-up code. I want it to be beautiful, elegant, orderly, concise. So every night, here and there when I get the chance, I review, rewrite, recompile, and repeat. After spending all day long trying to get it to work correctly on the hardware, my evenings are spent making it read correctly.
It isn't in my job description, but it's what I love to do. And it has helped the product become better, tighter, more manageable, more maintainable.
I would even say that it has helped us to get the job done faster, on schedule.
But ...
Someone upstairs (and I don't mean that in a spiritual sense) noticed that we (my team and I) had actually done what we set out to do, and this started them thinking that perhaps we could do it again. Perhaps we could take on another project which is way over budget and way behind schedule and way understaffed, and make it work. And perhaps I could lead that team as well.
Well, that's not bad, is it? Management responsibility again? Leading a team to victory?
Except that the person whom I would replace is the same person who was overloaded before, who was supposed to be able to do the job after having had the load reduced, who has apparently been unable to motivate his team to accomplish their objectives, who has not been able to make a plan and stick with it.
This upcoming assignment is similar to the one I am in the process of completing, only multiplied by a factor of four or five. It's huge. And it involves certification of both hardware and software. Lots of documentation. Lots of testing. Lots of financial and management meetings. Lots of Project Planning. Lots of customer oversight.
Lots of overtime.
I'm not thrilled. I just want to be a happy programmer, writing and testing my code on little platforms, writing the best, the tightest, the most efficient code in the universe, complete with documentation that can be read and understood by the most ardent techno-phobe.
Managers don't have any fun. They sit in boring meetings. They make unrealistic plans and goals. They whine and complain about money, and have to go up the chain, begging for more. They are not seen as real engineers anymore. And, worst of all, they don't get to play with the toys.
But ...
The job has to get done.
But ...
I took on this job because someone else was overloaded and couldn't get it done. And the job was not given to me with the intent of forcing me to spend countless hours writing code. In fact, I was given a team of six people to do that part of the job. My task was to manage these people, to push the project forward from its stalled position, and get it done in the allotted time. (It was already way past budget.)
And I'm proud to say that this is nearly accomplished. We have made our milestones. The product is functional, and nearly complete.
But ...
I can't stop going back and cleaning up the code. It was a hack to begin with, and I can't stand hacked-up code. I want it to be beautiful, elegant, orderly, concise. So every night, here and there when I get the chance, I review, rewrite, recompile, and repeat. After spending all day long trying to get it to work correctly on the hardware, my evenings are spent making it read correctly.
It isn't in my job description, but it's what I love to do. And it has helped the product become better, tighter, more manageable, more maintainable.
I would even say that it has helped us to get the job done faster, on schedule.
But ...
Someone upstairs (and I don't mean that in a spiritual sense) noticed that we (my team and I) had actually done what we set out to do, and this started them thinking that perhaps we could do it again. Perhaps we could take on another project which is way over budget and way behind schedule and way understaffed, and make it work. And perhaps I could lead that team as well.
Well, that's not bad, is it? Management responsibility again? Leading a team to victory?
Except that the person whom I would replace is the same person who was overloaded before, who was supposed to be able to do the job after having had the load reduced, who has apparently been unable to motivate his team to accomplish their objectives, who has not been able to make a plan and stick with it.
This upcoming assignment is similar to the one I am in the process of completing, only multiplied by a factor of four or five. It's huge. And it involves certification of both hardware and software. Lots of documentation. Lots of testing. Lots of financial and management meetings. Lots of Project Planning. Lots of customer oversight.
Lots of overtime.
I'm not thrilled. I just want to be a happy programmer, writing and testing my code on little platforms, writing the best, the tightest, the most efficient code in the universe, complete with documentation that can be read and understood by the most ardent techno-phobe.
Managers don't have any fun. They sit in boring meetings. They make unrealistic plans and goals. They whine and complain about money, and have to go up the chain, begging for more. They are not seen as real engineers anymore. And, worst of all, they don't get to play with the toys.
But ...
The job has to get done.
Friday, May 04, 2007
Subscribe to:
Posts (Atom)