Hacker News Reader

Comment by yourapostasy | Hacker News Reader

Generally, systems are almost never explicitly designed with an exit plan in place. A way to get the data out, inventory the integration points, enumerate the site-specific user procedures oriented towards business teams that need to be re-oriented towards a new system, a central location of customizations (containers are slightly helping here, with their notion of a centralized location of persistent configuration data across builds), how to test, and so on, is nearly always left to the team tasked years and sometimes decades down the road to figure out, instead of the team that originally stood up the system and has the information fresher in their minds.

This generally isn't done because no one wants to budget for those activities; they don't show up as revenue-positive. It will take a cultural change to adopt across the board, like leadership who controls the budgets now more commonly accept the overhead of version control.

View on HN

Re: systems are almost never explicitly designed with an exit plan in place.

How do you plan for the future when nobody can accurately predict the future? I remember where it was claimed that OOP UI api's could "last forever" because they were an abstract interface rather than implementation. However, they couldn't handle the stateless-ness of the web because OOP is inherently stateful. It's almost like having a printer API that assumes a color printer, and suddenly it's being asked to translate into black and white. You'll lose output meaning without reworking everything. Abstraction usually has to make assumptions, and these assumptions may turn out wrong down the road.

Re: no one wants to budget for those activities

True. That's one thing an org can and should plan for: money to pay for upgrading. In other words, you cannot predict future technology, but you can safely predict that adjusting to the future requires resources the vast majority of the time.

Next question: how many resources?

Re: How do you plan for the future when nobody can accurately predict the future?

It isn't so much 'planning for the future' as it is documenting the present. What are the things that you are doing _today_ which haven't been documented. Processes and procedures are often left undocumented because, well, ask Bob he knows how to do it.

... when Bob goes to retire it becomes a whole different discussion.

Ye I have noticed this bullshit antidocumentation attitude everywhere. It is like something people make up as comfort since secretaries and technical writers were sacked in the distant past and people are not even trying to keep things in order anymore.

It has got way worse becouse of Scrum and constant churn living in the now and not planning two sprints ahead.

Isn't this largely confirmation bias though?

I know a lot of systems which used standardised structures as a migration pattern, but those are the things that were basically painless to replace; and those that weren't painless stuck around.

Ironically those systems which had easy exit paths are often replaced by things which don't.

>Ironically those systems which had easy exit paths are often replaced by things which don't.

Sad but logical - stuff get's upgraded until it's no longer easy to do so. Often the opposite of what is needed!

Sustrik's law:

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

> In a long-lived project, components are being replaced. Nice reusable components are easy to replace and so they are. Ugly non-reusable components are pain to replace and each replacement means both a considerable risk and considerable cost. Thus, more often then not, they are not replaced. As the years go by, reusable components pass away and only the hairy ones remain. In the end the project turns into a monolithic cluster of ugly components melted one into another.

http://250bpm.com/blog:49

Moving to the cloud has changed this mindset somewhat - now there's no longer perpetual licenses, and we can't expect that the application will last forever, there's some consideration given to how application data can be repatriated.

Having cloud apps come with APIs as the only customisation points helps with our business users - we tell them that they need to chose a product that does what they want, as we won't be able to bend things around for them like we used to.

Reply on news.ycombinator.com