Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking the IDE for the 2020s

movingfulcrum.com

Post reply on HN
Print view View original

61–64 of 64 posts

Re: Rethinking the IDE for the 2020s

#61

Post by closeparen »

jayd16 wrote: post #60
closeparen wrote: post #56

Earlier quoted context omitted.

In general a new feature should have its home in one service and make calls to the existing network APIs of other services. If you’re regularly having to change the innards of those services to support new use cases, you have serious architecture debt.

You're being overly zealous. Every service has callers. Sometimes you want to work on the caller concurrently with the callee. Sometimes even the same person can work on the feature end to end. There is no reason that making that easy to do will cause tech debt. You already have other means to your services cleanly versioned and compatible, such as tests. Making things environments easy to run locally doesn't change…

A caller and caller that you want to change at the same time for the same reason belong in the same service.

Re: Rethinking the IDE for the 2020s

#62

Post by jayd16 »

closeparen wrote: post #61
jayd16 wrote: post #60

Earlier quoted context omitted.

You're being overly zealous. Every service has callers. Sometimes you want to work on the caller concurrently with the callee. Sometimes even the same person can work on the feature end to end. There is no reason that making that easy to do will cause tech debt. You already have other means to your services cleanly versioned and compatible, such as tests. Making things environments easy to run locally doesn't change…

A caller and caller that you want to change at the same time for the same reason belong in the same service.

If I want to add a piece of data and a visualization of that data the UI and the data store should be in the same service, no exceptions?

You're saying that a desire for when something gets worked on should trump any other design decision? "Want at the same time" informs separation of concerns?

You make services in an vacuum without considering the stakeholder/consumer of your service? You've never planned for a service in your org you consume to gain functionality because doing so would mean you should implement that functionality yourself in a service you own?

Re: Rethinking the IDE for the 2020s

#63

Post by closeparen »

jayd16 wrote: post #62
closeparen wrote: post #61

Earlier quoted context omitted.

A caller and caller that you want to change at the same time for the same reason belong in the same service.

If I want to add a piece of data and a visualization of that data the UI and the data store should be in the same service, no exceptions? You're saying that a desire for when something gets worked on should trump any other design decision? "Want at the same time" informs separation of concerns? You make services in an vacuum without considering the stakeholder/consumer of your service? You've never planned for a serv…

Teams that call themselves "platforms" are very often tempted to operate in a mode where they add a lot of one-off endpoints tailored to the specific use cases of particular callers. This skips the whole economic value of "platform" and makes them consultancies instead. My company has this problem in a big way, there are CTO-level efforts towards reusable abstractions and generic extension points instead of all this deep cross-team cross-service coupling. It is frequently the way I can add the most value in a design review: help the team come up with abstractions based on their domain model that are sufficient for their callers, instead of building to the letter of current callers' requirements (and signing themselves up to keep doing that for each new caller).

"How often will we need to change this and what will that be like?" is usually my top design consideration after "will it work?" So yes on that one.

Re: Rethinking the IDE for the 2020s

#64

Post by laurentlb »

jupp0r wrote: post #31

I completely disagree with the article (but I realize that this is only my opinion and IDE choice is something that comes down to personal preference): Here is what I think IDEs need to do different in the 2020s: - configuration needs to be in human-readable configuration files, not obscure XML configs that can realistically only be edited through UIs. - how to build the project needs to be completely decoupled from…

> how to build the project needs to be completely decoupled from the IDE

See also https://build-server-protocol.github.io (but it doesn't seem to get much traction yet)

Post reply on HN