The value of writing better code.
Consistency isn't my thing. It is one of the worst things I can say about myself as a developer. The flip-side of that statement is that I only deviate from an earlier approach for a better one (or at least one I perceive to be better, things can't always go as planned).
So what is the cost and gain of this? I don't know. I can't imagine trying to support an application of any real size where every screen/control/pattern conforms to the design that started it all. I know that there is value in consistency as it makes the system more predictable, easier to support and easier to maintain. But, as an example, one of the ways in which I deviate from earlier designs is that I eventually stumble across new ways to code the same thing that uses fewer lines of code... so I may 2 different implementations, but the new is actually "easier" to maintain in and of itself. Another thing I often do is generalize an existing solution when I find I'm reusing it often. I may not reduce the amount of code, for the sake of argument, lets says this always results in more code... but, by virtue of generalizing I'm not able to have just one class or method where alternatively I would need a new one for each implementation. Here, in and of itself, the solution may be more complex, but any change here can improve/fix the design in every implementation, so time is saved.
I don't have anything against consistency. In fact sometimes I think it would be nice if my brain would just stop analyzing things long enough for me to finish something using a single approach and to achieve that consistency.
I meant to start this post heading in a different direction. I suppose I'm trying to make a point. I would say that there is an ultimate solution. And that is generalization. As mentioned above, if you can generalize your solutions into a single entity that is re-used in many places, time spent refactoring and improving on that design provides the ultimate bang for your buck. But, when you aren't doing that, or it may not apply, that there isn't always a clear decision between being consistent and striving for something better. Maybe, I'm just trying to justify my own short comings.
To illustrate, when I was writing the code to post a payment against a work order, I spent a lot of time working with the default CRUD methods I had built into my service layer. The problem here is twofold. I always need to update 2 things at a time. I need to create a new Payment record in the database and I also need to create a new log entry. Using the basic CRUD methods this is 2 distinct operations and 2 distinct transactions, which means one can fail and the other can succeed thus leaving inconsistencies in the data. This also lead to a rather bloated chunk of code handling things. I'm not really concerned that one or the other will ever fail. The log table has no dependencies and no unique key other than a Guid column, so after the Payment is created I SHOULDN'T ever hit an issue.
When I started on applying for Purchase Orders I instead wrote a separate method in my service layer to handle it. This one method creates both entries in a single call and in a single transaction. Thus, one cannot succeed unless they both succeed. The code in the service layer was quick and simple and so was the code in the code behind of the UI.
In this case I really will need to go back and change the other code. I will never feel happy with code that can explode. It is a different thing entirely than having 5 lines of code versus 50 when I know they do the exact same thing. I can leave that sort of thing be.
At the end of the day, the best solution aside from the advice to generalize is probably to do another thing I'm terrible at, but for different reasons. Invest more time upfront in coming up with a better solution. I'm bad at this because the places I end refactoring multiple times are either scenarios I didn't anticipate at all and need a solution on the fly, or they are in areas that I thought would be less prominent than originally anticipated so I wouldn't budget much time for a quality solution anyway. The last reason this happens is because a project goes on long enough that I find a better way I didn't even know existed after the fact. I do a lot of coding both at work and on the side, so in most cases if a project takes more than a week I'll stumble upon some great new technology or means of solving the problem which hadn't occurred to me earlier.
Anyway, update: Getting VERY close to done with the "rough" version. Honestly, at this point, once I finish up the PO report I would say that the system can handle everything it needs to at a VERY basic level. There is more I want to clean up and do more than that, but getting close to the point where anything else that might be on my list is either refactoring old code, or adding just a few lines here and there, it is the exciting point in my projects. After that I can focus on UI. This project has been of immense help for me and will dictate a lot of what will end up in the next version of the Veronica's software.
Happy Holidays!
So what is the cost and gain of this? I don't know. I can't imagine trying to support an application of any real size where every screen/control/pattern conforms to the design that started it all. I know that there is value in consistency as it makes the system more predictable, easier to support and easier to maintain. But, as an example, one of the ways in which I deviate from earlier designs is that I eventually stumble across new ways to code the same thing that uses fewer lines of code... so I may 2 different implementations, but the new is actually "easier" to maintain in and of itself. Another thing I often do is generalize an existing solution when I find I'm reusing it often. I may not reduce the amount of code, for the sake of argument, lets says this always results in more code... but, by virtue of generalizing I'm not able to have just one class or method where alternatively I would need a new one for each implementation. Here, in and of itself, the solution may be more complex, but any change here can improve/fix the design in every implementation, so time is saved.
I don't have anything against consistency. In fact sometimes I think it would be nice if my brain would just stop analyzing things long enough for me to finish something using a single approach and to achieve that consistency.
I meant to start this post heading in a different direction. I suppose I'm trying to make a point. I would say that there is an ultimate solution. And that is generalization. As mentioned above, if you can generalize your solutions into a single entity that is re-used in many places, time spent refactoring and improving on that design provides the ultimate bang for your buck. But, when you aren't doing that, or it may not apply, that there isn't always a clear decision between being consistent and striving for something better. Maybe, I'm just trying to justify my own short comings.
To illustrate, when I was writing the code to post a payment against a work order, I spent a lot of time working with the default CRUD methods I had built into my service layer. The problem here is twofold. I always need to update 2 things at a time. I need to create a new Payment record in the database and I also need to create a new log entry. Using the basic CRUD methods this is 2 distinct operations and 2 distinct transactions, which means one can fail and the other can succeed thus leaving inconsistencies in the data. This also lead to a rather bloated chunk of code handling things. I'm not really concerned that one or the other will ever fail. The log table has no dependencies and no unique key other than a Guid column, so after the Payment is created I SHOULDN'T ever hit an issue.
When I started on applying for Purchase Orders I instead wrote a separate method in my service layer to handle it. This one method creates both entries in a single call and in a single transaction. Thus, one cannot succeed unless they both succeed. The code in the service layer was quick and simple and so was the code in the code behind of the UI.
In this case I really will need to go back and change the other code. I will never feel happy with code that can explode. It is a different thing entirely than having 5 lines of code versus 50 when I know they do the exact same thing. I can leave that sort of thing be.
At the end of the day, the best solution aside from the advice to generalize is probably to do another thing I'm terrible at, but for different reasons. Invest more time upfront in coming up with a better solution. I'm bad at this because the places I end refactoring multiple times are either scenarios I didn't anticipate at all and need a solution on the fly, or they are in areas that I thought would be less prominent than originally anticipated so I wouldn't budget much time for a quality solution anyway. The last reason this happens is because a project goes on long enough that I find a better way I didn't even know existed after the fact. I do a lot of coding both at work and on the side, so in most cases if a project takes more than a week I'll stumble upon some great new technology or means of solving the problem which hadn't occurred to me earlier.
Anyway, update: Getting VERY close to done with the "rough" version. Honestly, at this point, once I finish up the PO report I would say that the system can handle everything it needs to at a VERY basic level. There is more I want to clean up and do more than that, but getting close to the point where anything else that might be on my list is either refactoring old code, or adding just a few lines here and there, it is the exciting point in my projects. After that I can focus on UI. This project has been of immense help for me and will dictate a lot of what will end up in the next version of the Veronica's software.
Happy Holidays!
Comments
Post a Comment