4 ms·

> There's another important idea here - when designing a new application you should design it in such a way as to make it easier for it to be strangled in the f

by cle 8y ago

> There's another important idea here - when designing a new application you should design it in such a way as to make it easier for it to be strangled in the future. Let's face it, all we are doing is writing tomorrow's legacy software today. By making it easy to be strangled in the future, you are enabling the graceful fading away of today's work. This is a very important point that I've been harping on for years. If the nature of your business requires quickly adapting to new business needs--then make your software and systems easy to delete! Chances are good that they'll be obsolete/outdated in a few years, and everyone will be much happier if the system is easy to remove and replace. How to implement that is very dependent on the nature of your systems, how you deploy, your company's tech and operational culture, etc. But it's very much worth thinking about: "If this project were to fail in the long run, how hard would it be to get rid of?" In large companies, lingering legacy systems can make or break an entire organization.

yingw787 8y ago
I can't agree with this more. One company I worked at did proof-of-concept sales to enterprise customers, and as engineers we supported the sales team by adding additional features the customer may demand before making the sell. Sometimes the sale does not go through, and the implemented feature is of no use to the other enterprise customers we have. It's still there in the codebase as technical debt, and it's difficult to delete since there's no clear boundaries between the useless code and the more frequently used paths. As lines of code increase development velocity decreases. Using a strangler pattern may make this process less painful.
- xkcd-sucks 8y ago
  >and the implemented feature is of no use to the other enterprise customers we have >As lines of code increase development velocity decreases. How do you make this clear to the CEO......................
- bobwaycott 8y ago
  Would this be mitigated by setting up custom demos with quickly mocked features on separate branches that can be easily spun up and deleted? I’ve helped clients with similar needs, and it’s so much easier to make a rough working feature branch for something that helps the sales process for a large customer, temporarily run it on a subdomain for demo purposes, and then get rid of it. It still hangs around for a time in a branch, but it only gets merged in when there’s a definitive need for it to be part of the live product. Edit: This doesn’t solve the problem of wasted team effort, obviously. This kind of effort ought to only be taken when you can’t get a potential customer to agree to signing a contract before doing some work on a new feature. But that can be difficult to do sometimes. Marrying sales and development is its own challenge.
rumcajz 8y ago
OTOH: "Well-designed components are easy to replace. Eventually, they will be replaced by ones that are not so easy to replace."
- james_s_tayler 8y ago
  hahahah oh man. That's such a trap. Good point.
- cle 8y ago
  Not sure what your point is? Should we give up on well-designed components? A cynical quip like Sustrik’s Law is meaningless to me without a deeper analysis. What mechanisms or conditions make this “law” true? And what are its actionable takeaways?
  - jplayer01 8y ago
    I think it drives at an important point: Your job isn't done just because you've somehow managed to design and implement the perfect component that's absolutely reusable. There are plenty of internal and external forces that will turn that component into something imperfect and flawed, if not replace it outright with something that is far less usable, reusable, appropriate, etc. It requires constant vigilance and maintenance to maintain that state.
csours 8y ago
Legacy Software: any software that exists before I joined the organization, no matter how recent or up to date. - Alternatively - Legacy Software: any software that has been deployed. --- Even if the workflows are not outdated, the software libraries will likely be outdated. In manufacturing, don't be surprised to see Windows 2000 boxes on the plant floor; also expect new hires to complain about AngularJS apps.
- cle 8y ago
  In this context, I’m not using those cynical definitions of “legacy”. The definition is right there: software that doesn’t have any business value anymore.

by cle 8y ago

yingw787 8y ago

I can't agree with this more. One company I worked at did proof-of-concept sales to enterprise customers, and as engineers we supported the sales team by adding additional features the customer may demand before making the sell. Sometimes the sale does not go through, and the implemented feature is of no use to the other enterprise customers we have. It's still there in the codebase as technical debt, and it's difficult to delete since there's no clear boundaries between the useless code and the more frequently used paths. As lines of code increase development velocity decreases. Using a strangler pattern may make this process less painful.

xkcd-sucks 8y ago
>and the implemented feature is of no use to the other enterprise customers we have >As lines of code increase development velocity decreases. How do you make this clear to the CEO......................
bobwaycott 8y ago
Would this be mitigated by setting up custom demos with quickly mocked features on separate branches that can be easily spun up and deleted? I’ve helped clients with similar needs, and it’s so much easier to make a rough working feature branch for something that helps the sales process for a large customer, temporarily run it on a subdomain for demo purposes, and then get rid of it. It still hangs around for a time in a branch, but it only gets merged in when there’s a definitive need for it to be part of the live product. Edit: This doesn’t solve the problem of wasted team effort, obviously. This kind of effort ought to only be taken when you can’t get a potential customer to agree to signing a contract before doing some work on a new feature. But that can be difficult to do sometimes. Marrying sales and development is its own challenge.

rumcajz 8y ago

OTOH: "Well-designed components are easy to replace. Eventually, they will be replaced by ones that are not so easy to replace."

james_s_tayler 8y ago
hahahah oh man. That's such a trap. Good point.
cle 8y ago
Not sure what your point is? Should we give up on well-designed components? A cynical quip like Sustrik’s Law is meaningless to me without a deeper analysis. What mechanisms or conditions make this “law” true? And what are its actionable takeaways?
- jplayer01 8y ago
  I think it drives at an important point: Your job isn't done just because you've somehow managed to design and implement the perfect component that's absolutely reusable. There are plenty of internal and external forces that will turn that component into something imperfect and flawed, if not replace it outright with something that is far less usable, reusable, appropriate, etc. It requires constant vigilance and maintenance to maintain that state.

csours 8y ago

Legacy Software: any software that exists before I joined the organization, no matter how recent or up to date. - Alternatively - Legacy Software: any software that has been deployed. --- Even if the workflows are not outdated, the software libraries will likely be outdated. In manufacturing, don't be surprised to see Windows 2000 boxes on the plant floor; also expect new hires to complain about AngularJS apps.

cle 8y ago
In this context, I’m not using those cynical definitions of “legacy”. The definition is right there: software that doesn’t have any business value anymore.