Re:Three ways to solve hard programming problems
by kbenson on Sunday May 29, 2016 @04:00PM
(#11797951)
I think an important aspect that is often overlooked is how likely are the original developer(s), or people that really understand the purpose, going to be around later if it needs more work or a rewrite.
For example, I often take the approach that my first implementation, which likely will end up in production, is used for learning the interface, service or business need. It satisfies the problem as it currently exists and was defined, and generally has a few hacky parts as the needs were explained in more detail or changed halfway or more through the project. The next time anything more than a bug fix or trivial feature is required, I'll rewrite the most problematic behavior in a more extensible and cleaner way, since I now have a much better understanding of the problem. This is generally quick, as I can re-purpose portions of the original that are perfectly usable, and I have a reference implementation (the original) to compare against to find any bugs in the new version.
I can rely on this because the chances that I will be around at this company in the future are extremely high. This would not be a good approach for a company that sees domain expertise leave, or move to different departments that aren't easily approached for information. I've been on projects where you come in to rewrite on someone else's old code because nobody really understands it well, with little or no information besides the code itself and included comments as to the original design decisions. It's easy to identify the portions of the code that look like they were stupid decisions, and you would definitely never do that. You start writing code, and soon you run into unexpected conditions that require you to make the same or equivalent hacky choices, and you understand a little of the original developer's prior choices. You'll end up with the code rewritten, and possibly a little better and cleaner, but if someone comes along in a few years, they'll have the same problems you did. These are the situations you want to avoid by spending more time up front to make the solution better in the beginning, or at the bare minimum, documenting in the code the hacky abstractions you've been forced to make.
For example, I often take the approach that my first implementation, which likely will end up in production, is used for learning the interface, service or business need. It satisfies the problem as it currently exists and was defined, and generally has a few hacky parts as the needs were explained in more detail or changed halfway or more through the project. The next time anything more than a bug fix or trivial feature is required, I'll rewrite the most problematic behavior in a more extensible and cleaner way, since I now have a much better understanding of the problem. This is generally quick, as I can re-purpose portions of the original that are perfectly usable, and I have a reference implementation (the original) to compare against to find any bugs in the new version.
I can rely on this because the chances that I will be around at this company in the future are extremely high. This would not be a good approach for a company that sees domain expertise leave, or move to different departments that aren't easily approached for information. I've been on projects where you come in to rewrite on someone else's old code because nobody really understands it well, with little or no information besides the code itself and included comments as to the original design decisions. It's easy to identify the portions of the code that look like they were stupid decisions, and you would definitely never do that. You start writing code, and soon you run into unexpected conditions that require you to make the same or equivalent hacky choices, and you understand a little of the original developer's prior choices. You'll end up with the code rewritten, and possibly a little better and cleaner, but if someone comes along in a few years, they'll have the same problems you did. These are the situations you want to avoid by spending more time up front to make the solution better in the beginning, or at the bare minimum, documenting in the code the hacky abstractions you've been forced to make.