My disgust at the quality of the code on a project I joined in March came to a head a few weeks back. I remember when I started, looking at some really crappy code. I thought, "Wow - this is a real opportunity to do some good, cleaning up this mess!" I didn't realize that after 18 years in this business I could still be naive!
I had heard the almost apologetic comments from some people on other projects who had been around for a while... the original developers were hired right out of school, and their designer didn't pay much attention to them because that person was involved in a few projects, etc., etc. However, what gradually bothered me to the point of blowing was that not only did the original developers have nary a clue about O-O development, but later, more experienced people just exacerbated the problem.
I can't remember ever seeing code as tangled as this is. I would like to use the term Big Ball of Mud to describe the code, but that would be unfair to mud. Coupling doesn't begin to describe it either, and code reuse was strictly through copy and paste (there was a lot of "code reuse"!). A transaction from a business perspective could consist of several different interactions with the database, each of which using it's own Connection, and some with autoCommit set to true! This created many situations in which data was left in an inconsistent state that was, at times, impossible to fix.
In one case, we detected a logic error in some code that determined if a database insert or update should occur. I fixed that error and suddenly 3 more cropped up. Other code had been written that assumed the error was there!! AAAAAAAAGGGGGGGHHHHHH!!! My early naivete was quickly overcome by the pressing need to just keep the system afloat so that the Customer could do their job. As a result, many relatively straightforward but "deep" refactorings kept being pushed back owing to more pressing work.
The data access was all pure JDBC, with no abstractions to simplify the code. I found several instances where PreparedStatements and ResultSets were being created and accessed within loops, but only closed outside the loop. I'm not a really deep bit-twiddler, but that just stinks to high heaven of a memory leak! On top of that, the DAO's consisted entirely of static methods, meaning I couldn't just pull out an interface and use a mock for testing.
Two weeks ago, another developer joined the team. He had been working on another project at this client and sat close by, so I knew him a bit and knew that he seemed like a decent developer. After he saw the code for the first time, he said he was kind of excited because it looked like a real opportunity to do some refactoring. The first thing he was going to do was change the DAO's to no longer use static methods, extract an interface and start using mocks to allow testing. :) Two weeks later, he now understands my frustration!
My real frustration, though, is that people were paid to produce this shit. I'm sorry for the expletive, but that's what it is. I even sent off the link to Uncle Bob's We Will Not Ship Shit article on Artima to the rest of the team. The people who worked on this system were supposed to be professionals. However, they didn't have a bloody clue about the principles of object oriented development. OK, so the original developers were young and inexperienced. I guess they skipped a few too many classes during the OO lectures, or whatever school they attended didn't venture much further beyond Hello World in the labs. However, those developers were replaced with experienced people. Those people should have known better. When I see work such as this system, even I start to believe that the software development aspect of the IT industry needs some sort of accreditation system that requires an apprenticeship period in addition to education.
After about a month on the project, I sat down for a chat with the team's manager. I talked about the state of the code, and how in terms of technical debt this was way beyond the Hired Goons stage. There was a full-fledged hit out for this piece of crap. He asked what I thought about re-writing the application, and I immediately agreed that it was about the only way to make progress. Fortunately, that's about to begin in the next few weeks. Unfortunately, I'm leaving that contract at the end of August. Maybe the other developers will be more productive after I leave because they won't have to listen to my incredulous remarks from my cubicle, "Oh my... what the... what the hell were they thinking?!!" I'd like to put a smiley beside that last sentence, but I do that almost every day.
Ironically, in the Customer's eyes the members of the development team are gods! They've been dealing with a dysfunctional system for so long that any improvement is seen as a breakthrough. I can just see it now... once the properly rewritten system is in place and has few if any production defects, the developers will be mere mortals again and will be in the dog house if even a single bug is found!! Remember, you heard it here first. :)
I had heard the almost apologetic comments from some people on other projects who had been around for a while... the original developers were hired right out of school, and their designer didn't pay much attention to them because that person was involved in a few projects, etc., etc. However, what gradually bothered me to the point of blowing was that not only did the original developers have nary a clue about O-O development, but later, more experienced people just exacerbated the problem.
I can't remember ever seeing code as tangled as this is. I would like to use the term Big Ball of Mud to describe the code, but that would be unfair to mud. Coupling doesn't begin to describe it either, and code reuse was strictly through copy and paste (there was a lot of "code reuse"!). A transaction from a business perspective could consist of several different interactions with the database, each of which using it's own Connection, and some with autoCommit set to true! This created many situations in which data was left in an inconsistent state that was, at times, impossible to fix.
In one case, we detected a logic error in some code that determined if a database insert or update should occur. I fixed that error and suddenly 3 more cropped up. Other code had been written that assumed the error was there!! AAAAAAAAGGGGGGGHHHHHH!!! My early naivete was quickly overcome by the pressing need to just keep the system afloat so that the Customer could do their job. As a result, many relatively straightforward but "deep" refactorings kept being pushed back owing to more pressing work.
The data access was all pure JDBC, with no abstractions to simplify the code. I found several instances where PreparedStatements and ResultSets were being created and accessed within loops, but only closed outside the loop. I'm not a really deep bit-twiddler, but that just stinks to high heaven of a memory leak! On top of that, the DAO's consisted entirely of static methods, meaning I couldn't just pull out an interface and use a mock for testing.
Two weeks ago, another developer joined the team. He had been working on another project at this client and sat close by, so I knew him a bit and knew that he seemed like a decent developer. After he saw the code for the first time, he said he was kind of excited because it looked like a real opportunity to do some refactoring. The first thing he was going to do was change the DAO's to no longer use static methods, extract an interface and start using mocks to allow testing. :) Two weeks later, he now understands my frustration!
My real frustration, though, is that people were paid to produce this shit. I'm sorry for the expletive, but that's what it is. I even sent off the link to Uncle Bob's We Will Not Ship Shit article on Artima to the rest of the team. The people who worked on this system were supposed to be professionals. However, they didn't have a bloody clue about the principles of object oriented development. OK, so the original developers were young and inexperienced. I guess they skipped a few too many classes during the OO lectures, or whatever school they attended didn't venture much further beyond Hello World in the labs. However, those developers were replaced with experienced people. Those people should have known better. When I see work such as this system, even I start to believe that the software development aspect of the IT industry needs some sort of accreditation system that requires an apprenticeship period in addition to education.
After about a month on the project, I sat down for a chat with the team's manager. I talked about the state of the code, and how in terms of technical debt this was way beyond the Hired Goons stage. There was a full-fledged hit out for this piece of crap. He asked what I thought about re-writing the application, and I immediately agreed that it was about the only way to make progress. Fortunately, that's about to begin in the next few weeks. Unfortunately, I'm leaving that contract at the end of August. Maybe the other developers will be more productive after I leave because they won't have to listen to my incredulous remarks from my cubicle, "Oh my... what the... what the hell were they thinking?!!" I'd like to put a smiley beside that last sentence, but I do that almost every day.
Ironically, in the Customer's eyes the members of the development team are gods! They've been dealing with a dysfunctional system for so long that any improvement is seen as a breakthrough. I can just see it now... once the properly rewritten system is in place and has few if any production defects, the developers will be mere mortals again and will be in the dog house if even a single bug is found!! Remember, you heard it here first. :)