Is it familiar for you?
-
http://www.commitstrip.com/en/2014/11/25/west-side-project-story/[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
http://www.commitstrip.com/en/2014/11/25/west-side-project-story/[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Only in the sense of being brought in as a consultant to fix the mess. :sigh: Marc
Imperative to Functional Programming Succinctly Higher Order Programming
-
Only in the sense of being brought in as a consultant to fix the mess. :sigh: Marc
Imperative to Functional Programming Succinctly Higher Order Programming
At least you got payed for (I hope so!)... :-D
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
At least you got payed for (I hope so!)... :-D
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
At least you got payed for (I hope so!)
Yes quite, but it's interesting how frustrating the process can be, working with crappy code. To give you an example, I took one function with 20 or so property "setters" all hand-coded against a database table and replaced the whole thing with one line of Linq and some reflection. Now, imagine dozens of these functions, because there are dozens of these tables, each of which was hand-coded, and all of which, comprising thousands and thousands of lines of code, could be reduced to my one line general purpose function. And no, performance is not an issue, using reflection is just fine, etc. And this code was written by someone (around Jan of 2014) claiming to have 20 years of experience and degrees in Computer Science. Argh. It's really strange, but I can actually "hear" the code screaming, like a deformed baby from some horror movie. It sure needs a lot of healing. :sigh: Marc
Imperative to Functional Programming Succinctly Higher Order Programming
-
Kornfeld Eliyahu Peter wrote:
At least you got payed for (I hope so!)
Yes quite, but it's interesting how frustrating the process can be, working with crappy code. To give you an example, I took one function with 20 or so property "setters" all hand-coded against a database table and replaced the whole thing with one line of Linq and some reflection. Now, imagine dozens of these functions, because there are dozens of these tables, each of which was hand-coded, and all of which, comprising thousands and thousands of lines of code, could be reduced to my one line general purpose function. And no, performance is not an issue, using reflection is just fine, etc. And this code was written by someone (around Jan of 2014) claiming to have 20 years of experience and degrees in Computer Science. Argh. It's really strange, but I can actually "hear" the code screaming, like a deformed baby from some horror movie. It sure needs a lot of healing. :sigh: Marc
Imperative to Functional Programming Succinctly Higher Order Programming
Marc Clifton wrote:
And no, performance is not an issue, using reflection is just fine, etc.
Not sure how that it relevant since of course performance would be mostly impacted by the database call itself and of course the overall architecture.
Marc Clifton wrote:
And this code was written by someone (around Jan of 2014) claiming to have 20 years of experience and degrees in Computer Science.
Did the code work? Was it laid out in a consistent manner? Was the code that was created by the one individual consistent between different entities? If the answer to all of those is no then it was crappy code. If the answer is yes then of course you are discussing a preference which has nothing to do with the actual quality of the code.
-
Marc Clifton wrote:
And no, performance is not an issue, using reflection is just fine, etc.
Not sure how that it relevant since of course performance would be mostly impacted by the database call itself and of course the overall architecture.
Marc Clifton wrote:
And this code was written by someone (around Jan of 2014) claiming to have 20 years of experience and degrees in Computer Science.
Did the code work? Was it laid out in a consistent manner? Was the code that was created by the one individual consistent between different entities? If the answer to all of those is no then it was crappy code. If the answer is yes then of course you are discussing a preference which has nothing to do with the actual quality of the code.
Yes, yes, and yes.
jschell wrote:
If the answer is yes then of course you are discussing a preference which has nothing to do with the actual quality of the code.
Not really. It's costly to maintain because to make a change (like adding a column to the DB) requires: Add a field Adding the get/set property Updating the query method Updating the insert method Updating the update method Updating the method that copies the DB field to the properties Updating the method that copies the properties to the DB fields. What should take one minute ends up taking about 30, not to mention that none of the code is abstracted enough to mock the DB and write unit tests, so the only way to test the changes is to actually run the app, which is a web service, so that requires a bunch of complex hoops on the client side to even get to the point where you can access the changed functions. That's all factual issues, not opinion. Marc
Imperative to Functional Programming Succinctly Higher Order Programming
-
http://www.commitstrip.com/en/2014/11/25/west-side-project-story/[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Once saw a new years resolution to "finish more projects than I start" :)
____________________________________________________________ Be brave little warrior, be VERY brave
-
Kornfeld Eliyahu Peter wrote:
At least you got payed for (I hope so!)
Yes quite, but it's interesting how frustrating the process can be, working with crappy code. To give you an example, I took one function with 20 or so property "setters" all hand-coded against a database table and replaced the whole thing with one line of Linq and some reflection. Now, imagine dozens of these functions, because there are dozens of these tables, each of which was hand-coded, and all of which, comprising thousands and thousands of lines of code, could be reduced to my one line general purpose function. And no, performance is not an issue, using reflection is just fine, etc. And this code was written by someone (around Jan of 2014) claiming to have 20 years of experience and degrees in Computer Science. Argh. It's really strange, but I can actually "hear" the code screaming, like a deformed baby from some horror movie. It sure needs a lot of healing. :sigh: Marc
Imperative to Functional Programming Succinctly Higher Order Programming
Marc Clifton wrote:
claiming to have 20 years of experience and degrees in Computer Science.
Programming was a lot different back then. Having 20 years of experience is not the same as having 20 years of knowledge :D I know people with many years of experience who still code like they're in VB1 (yes, really!).
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Once saw a new years resolution to "finish more projects than I start" :)
____________________________________________________________ Be brave little warrior, be VERY brave
Yeah, there are also times that I start a new side project after putting the first brick only.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Yes, yes, and yes.
jschell wrote:
If the answer is yes then of course you are discussing a preference which has nothing to do with the actual quality of the code.
Not really. It's costly to maintain because to make a change (like adding a column to the DB) requires: Add a field Adding the get/set property Updating the query method Updating the insert method Updating the update method Updating the method that copies the DB field to the properties Updating the method that copies the properties to the DB fields. What should take one minute ends up taking about 30, not to mention that none of the code is abstracted enough to mock the DB and write unit tests, so the only way to test the changes is to actually run the app, which is a web service, so that requires a bunch of complex hoops on the client side to even get to the point where you can access the changed functions. That's all factual issues, not opinion. Marc
Imperative to Functional Programming Succinctly Higher Order Programming
Marc Clifton wrote:
It's costly to maintain because to make a change (like adding a column to the DB) requires:...
Err...no it doesn't. To add a column to a field should be a business decision and as such it will have an end to end impact on one or more systems. The cost of making this simple change to one system, presuming that the database layer is laid out using some consistent methodology is trivial because it is so straightforward. The impacts to the other parts of the system(s), one would hope should also be as easy but that depends on whether each level was also using a consistent methodology. Unfortunately what is much more likely to happen is that some layer uses several methodologies. Or is basically just an example of chaos. And thus the cost goes up because of this. As well one must ignore other issues such as prioritization of improvements/bugs versus the tradeoffs of whatever expertise exists currently within the development staff along with delivery times which also have an impact on real and perceived costs.
Marc Clifton wrote:
What should take one minute ends up taking about 30
Perhaps we work in different environments but I work with teams and methodologies which have the following constraints. - Estimates are not less than an hour and often four. - Code must be unit tested, and adding unit tests even for a new column is going to take more than one minute regardless of what it takes to actually add the column. This doesn't include things like building, running unit tests, checking in code and taking care of the ticket(s) that initiated the change in the first place. Not to mention of course that before all of this occurs reviewing why the change was needed in the first place would take time.
Marc Clifton wrote:
so that requires a bunch of complex hoops on the client side to even get to the point where you can access the changed functions.
If that is relevant than it suggests something either wrong with the design/architecture or it has nothing at all to do with how the database layer is implemented.
