Each developer would tell different stories. I thought I'd tell mine a bit. In my office, we're embarking a series of cleaning up the code because it's a big pile of band-aids. People were told to read "Working Effectively With Legacy Code".
While the book has been godsend, people's mentality is a different issue. Developers are an interesting bunch; they complain a lot when the code is full of band-aids but they will also back-off when management give a full-blessing to start cleaning up pieces by pieces. The only motivated people to do the task are mostly the new hire.
The software is a typical client-server that utilizes a standard/minimum WebService (WS is not as bad as you thought it would be). But here's the weird part: the server is a dumb component. Let me explain via ascii art:
Client(GUI, heavy BiznezLogic, heavy Validation) -> WebService (dumb) -> Data Access Layer (dumb) -> Stored Procedure (complex logic and validation).
Sort of good separation isn't it? Except it's hard to write unit/integration tests around heavy GUI based software and around Store Procedures. (Of course one could still write integration tests on top of the DAL layer, but we'll never achieve unit-test since we can't test per Stored Procedure).
The thing is: we can't drop everything completely and start refactoring (even if it's just a component). The train must continue.
I used to dislike consulting, but these days I've been starting to look at that direction. An added benefit of consulting is that you can meet clients and start networking: something that a maintenance developer can't do, cause he's stuck either fixing bugs or refactoring code until late night (and adding more unit-tests).
Unfortunately, most jobs are maintaining other people's code unless you're working for a startup or your own project. When you work in a startup, quality usually get pushed. Eventually when you hit year 2.5, you will deal with the same issue again and again. This vicious cycle keeps repeating over and over.
PS: Don't get me wrong, I love the whole idea of automated testing (unit and integration). I think developer should be accountable for the mess they created. I also think the business people should sit next to the developer once in a while.
Comments
Each developer would tell different stories. I thought I'd tell mine a bit. In my office, we're embarking a series of cleaning up the code because it's a big pile of band-aids. People were told to read "Working Effectively With Legacy Code".
While the book has been godsend, people's mentality is a different issue. Developers are an interesting bunch; they complain a lot when the code is full of band-aids but they will also back-off when management give a full-blessing to start cleaning up pieces by pieces. The only motivated people to do the task are mostly the new hire.
The software is a typical client-server that utilizes a standard/minimum WebService (WS is not as bad as you thought it would be). But here's the weird part: the server is a dumb component. Let me explain via ascii art:
Client(GUI, heavy BiznezLogic, heavy Validation) -> WebService (dumb) -> Data Access Layer (dumb) -> Stored Procedure (complex logic and validation).
Sort of good separation isn't it? Except it's hard to write unit/integration tests around heavy GUI based software and around Store Procedures. (Of course one could still write integration tests on top of the DAL layer, but we'll never achieve unit-test since we can't test per Stored Procedure).
The thing is: we can't drop everything completely and start refactoring (even if it's just a component). The train must continue.
I used to dislike consulting, but these days I've been starting to look at that direction. An added benefit of consulting is that you can meet clients and start networking: something that a maintenance developer can't do, cause he's stuck either fixing bugs or refactoring code until late night (and adding more unit-tests).
Unfortunately, most jobs are maintaining other people's code unless you're working for a startup or your own project. When you work in a startup, quality usually get pushed. Eventually when you hit year 2.5, you will deal with the same issue again and again. This vicious cycle keeps repeating over and over.
PS: Don't get me wrong, I love the whole idea of automated testing (unit and integration). I think developer should be accountable for the mess they created. I also think the business people should sit next to the developer once in a while.