In my opinion, having a reasonably clean architecture is all that matters.
Not that bad: the implementation of an individual function is counterintuitive and undocumented--as long as an intuitive implementation of the function would interface with the rest of your software just the same way.
Actually pretty bad: the function has side effects that would be better off somewhere else. If this is the case, fixing this function is likely to break something, which may break something else, and so-on.
The ideal case is one where even though your code base is messy, you can easily see how you could achieve a clean code base through a series of short, discrete steps, where each step begins and ends with working code.
Kind of like how if you've got a string attached to something at the entrance of a cave, it doesn't matter much how deep in to the cave you get--all you have to do is follow your string back.
Of course I'm just a 19-year-old kid. Someone who's worked on a large software project should tell me if they like my theory or not.
Of course I'm just a 19-year-old kid. Someone who's worked on a large software project should tell me if they like my theory or not.
Your post would be just fine if you left that line off. It was well-stated, agrees reasonably with my experience, and provides concrete points that can easily be addressed by anyone who disagrees.
My next suggestion would be to try it yourself: join a large software project.
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
In my opinion, having a reasonably clean architecture is all that matters.
Not that bad: the implementation of an individual function is counterintuitive and undocumented--as long as an intuitive implementation of the function would interface with the rest of your software just the same way.
Actually pretty bad: the function has side effects that would be better off somewhere else. If this is the case, fixing this function is likely to break something, which may break something else, and so-on.
The ideal case is one where even though your code base is messy, you can easily see how you could achieve a clean code base through a series of short, discrete steps, where each step begins and ends with working code.
Kind of like how if you've got a string attached to something at the entrance of a cave, it doesn't matter much how deep in to the cave you get--all you have to do is follow your string back.
Of course I'm just a 19-year-old kid. Someone who's worked on a large software project should tell me if they like my theory or not.
Of course I'm just a 19-year-old kid. Someone who's worked on a large software project should tell me if they like my theory or not.
Your post would be just fine if you left that line off. It was well-stated, agrees reasonably with my experience, and provides concrete points that can easily be addressed by anyone who disagrees.
My next suggestion would be to try it yourself: join a large software project.
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.