Amateurs! (Pretty techy)
Jun. 12th, 2003 10:24 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cyberspiceI've just wasted the last two days at work. I've been working on some code for a new product. I've been using an old product which supports remote debugging and the like and so I can step through the code using my PC while it executes on the product. My code is generally pretty close to the final thing first time anyway this time it took me a day to implement a protocol, test it and check it in to the code base.
Then on Tuesday I tried it out on the new product and it crashed. I couldn't believe it. The new product doesn't support remote debugging or debugging of any kind other than printf() statements. Madness. Especially when you consider I'm trying to debug a protocol that uses the same output. Gradually, doing a kind of quick search, using a slow and labourious turn off sections of code, add debug output, compile and flash, routine it's taken me two days to find out that it's a build problem.
There is nothing wrong with my code. It's fine. It's just that the build system worked it's dependencies out properly and so it was using incompatable object files. I found this when I added some debug to a driver. It fixed the problem by forcing the driver to be rebuilt. The lesson here is that this product also has a broken build system and had it had proper debugging support it would have taken maybe an hour or two to discover the problem.
I wasted two days last week due to a partially implemented driver on one product ("we don't need to do any more as it will do" - then you need to use some functionality that isn't there) and a badly implemented driver on another. I'm now a week behind because of incompetance. I'm glad I'm on the team I'm on as it allows me to sort out this sort of amateurish behaviour.
Anyway I've got it working on the new product which is great. The project manager will be happy and I have a nice piece of reuseable code that means this particular subsystem need never be written again.
Then on Tuesday I tried it out on the new product and it crashed. I couldn't believe it. The new product doesn't support remote debugging or debugging of any kind other than printf() statements. Madness. Especially when you consider I'm trying to debug a protocol that uses the same output. Gradually, doing a kind of quick search, using a slow and labourious turn off sections of code, add debug output, compile and flash, routine it's taken me two days to find out that it's a build problem.
There is nothing wrong with my code. It's fine. It's just that the build system worked it's dependencies out properly and so it was using incompatable object files. I found this when I added some debug to a driver. It fixed the problem by forcing the driver to be rebuilt. The lesson here is that this product also has a broken build system and had it had proper debugging support it would have taken maybe an hour or two to discover the problem.
I wasted two days last week due to a partially implemented driver on one product ("we don't need to do any more as it will do" - then you need to use some functionality that isn't there) and a badly implemented driver on another. I'm now a week behind because of incompetance. I'm glad I'm on the team I'm on as it allows me to sort out this sort of amateurish behaviour.
Anyway I've got it working on the new product which is great. The project manager will be happy and I have a nice piece of reuseable code that means this particular subsystem need never be written again.
