3 ms·

The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" ev

The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.

swader999 5y ago
Which then devolves into five ways of doing things after a few more iterations. Kitchen sink architecture.
danuker 5y ago
The "new way of doing things" is risky and might not turn out so good after all. If you treat the new way as an experiment, and only gradually convert the rest of the code, you're in for a smoother ride.
- Spivak 5y ago
  Please no, this is how you end up with 20 different experiments and zero consistency in everything. Gradual migrations are fine because it makes project managers happy but it requires a commitment to actually follow through with it. If there's a chance that you won't actually have dev time to finish the migration then just don't do it. It can't be that important then. It's totally fine to try out an experiment in a branch and deploy to QA but don't deploy it to prod until you're sure.
  - CTmystery 5y ago
    > Please no, this is how you end up with 20 different experiments and zero consistency in everything. This comes from a lack of discipline in the org, not from the parent's (IMO) correct guidance that an org should undertake architectural changes with pilots in isolated parts of the code base.
Cthulhu_ 5y ago
The pitfall there - and I myself am guilty of this - is that you only apply it halfway, so instead of fixing the problem (if there even is one), you're left with two different approaches to the same problem, meaning you added a second problem as well as a lot of overhead because you're not maintaining two different solutions.
emaginniss 5y ago
That's essentially the lava flow anti-pattern. You have remnants of old architect/tools/philosophy left in the old code while the new code is being built with the new hotness. Invariably everyone has to learn the old stuff to maintain the system as well as learn the new stuff to keep building.

swader999 5y ago

Which then devolves into five ways of doing things after a few more iterations. Kitchen sink architecture.

danuker 5y ago

The "new way of doing things" is risky and might not turn out so good after all. If you treat the new way as an experiment, and only gradually convert the rest of the code, you're in for a smoother ride.

Spivak 5y ago
Please no, this is how you end up with 20 different experiments and zero consistency in everything. Gradual migrations are fine because it makes project managers happy but it requires a commitment to actually follow through with it. If there's a chance that you won't actually have dev time to finish the migration then just don't do it. It can't be that important then. It's totally fine to try out an experiment in a branch and deploy to QA but don't deploy it to prod until you're sure.
- CTmystery 5y ago
  > Please no, this is how you end up with 20 different experiments and zero consistency in everything. This comes from a lack of discipline in the org, not from the parent's (IMO) correct guidance that an org should undertake architectural changes with pilots in isolated parts of the code base.

Cthulhu_ 5y ago

The pitfall there - and I myself am guilty of this - is that you only apply it halfway, so instead of fixing the problem (if there even is one), you're left with two different approaches to the same problem, meaning you added a second problem as well as a lot of overhead because you're not maintaining two different solutions.

emaginniss 5y ago

That's essentially the lava flow anti-pattern. You have remnants of old architect/tools/philosophy left in the old code while the new code is being built with the new hotness. Invariably everyone has to learn the old stuff to maintain the system as well as learn the new stuff to keep building.