3 ms·

The problem is is that outside of startups, anything that works even halfway is going to have a long shelf life. I have seen exactly zero instances where a soft

The problem is is that outside of startups, anything that works even halfway is going to have a long shelf life. I have seen exactly zero instances where a software solution was end of lifed earlier or at the time it was predicted to be in the enterprise (if an EOL was even defined beyond the implicit one developers set of "if it breaks after I'm gone it ain't my problem"); every single instance either had not hit its predicted end of life time yet, or was well, well passed it. Even stuff that -doesn't work at all- will be funded for refactoring rather than a rewrite. Given that, it makes sense to, in that environment, default to "let's do this thing correctly". But that's not actually long, right, and rigid. It's often shorter than one might think, and far more flexible, as it usually means "let's do the minimum amount of features that we need, but what ones we do, let's make sure we do well, working with the user to define them, and get feedback/iterate, writing lots of test, documentation, etc along the way". The problem is that businesses tend to prioritize exactly the opposite; give us features, now now now, that have only been defined at a very high level and not actually thought about by anyone, and any time not spent on implementing features is wasted. And with that mentality, using an existing solution seems to make sense. It's only afterwards that you realize that solution brings a lot of unnecessary complexity, doesn't give you the level of control you want, didn't instill the necessary domain knowledge in the developers for proper maintenance and modifications etc, possibly didn't even solve the problem(s), but by then it's too late, you're just told to make it work.

kbenson 10y ago
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.

kbenson 10y ago

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.