I’m curious. Does anyone else out there among us developers run into this all the time?
I’m working on a “team” of 15 to 20 developers. Some are older, many are newer. The application has existed for quite awhile now.
Over the years I have managed to get good control of the component (which is pretty low-level). I have developed a routine of development that involves not only compiling the code before checking it in but of unit testing it for functionality. When I check in code it has an excellent shot of being right the first time – and it usually is. I’d say I get, maybe, 2% of my issues sent back due to a test that showed something I might have forgotten.
However, it’s obvious that I’m in the minority when it comes to really being careful about what I check in. I would say about 90% of the time when I get the latest version of the code I find myself fixing problems (often critical) that occur in the application “on the way” to an issue I’m trying to work with. Many many times the problem is because someone just changed the code, stored procedure or database and didn’t consider anything about what it could affect. I’d say I spend 30 to 40 percent of my development time sorting out and fixing OTHER PEOPLE’s problems before I can get back to working on my areas because of this slop.
Anyone else running into this? What ever happened to quality-mindedness when developing software? Maybe the idea is just a fantasy of mine. Is it expecting too much for developers to TEST the stuff they work on before checking it in for others to crash on? ARRGGG!!!
Sorry for the rant … some days I think I should look for a job somewhere else where they do it the way I’d like – but in the 30 years I’ve been doing this I haven’t found one yet!
-CB