Comment by dahart | Hacker News Reader

Comment by dahart | Hacker News Reader

Parent Full thread

I love the opening sections of this article, but the end left me feeling wanting.

> the best teams both create much less cruft but also remove enough of the cruft they do create that they can continue to add features quickly. [...] They refactor frequently so that they can remove cruft before it builds up enough to get in the way.

In my experience in several large teams over 20 years, this is not a great summary of what actually happens. What actually happens is accumulation of customer requirements. We build new features and the old features that don’t fit easily with the new ones are not allowed to be removed. Everyone on the team wants the old features removed, and at the same time, the team reaches consensus that doing so would alienate loyal customers and lose business.

The decision is to avoid financial risk, not to drop software quality. The new features are also required, and so compromises and complications arise from supporting both. This is the main source of what is being called “cruft” here. I’ve seen truly great engineering teams, I’ve never seen engineering teams good enough to withstand conflicting requirements between old and new features. I don’t know what the solutions are, but I’m suspecting the thinking on solving this these days is planning a year or two ahead, publishing the deprecation schedule of old features. This takes a certain kind of management that is willing to sacrifice a few dollars today for the bigger picture, it isn’t easy to find.

That’s true. A lot of people think that being customer centric means to exactly do what the customer says. But sometimes you have to say “no” or propose different ways to achieve their goals so you can keep the software architecture halfways clean. Unfortunately it doesn’t help that often engineering is not allowed to or doesn’t want to talk to the customer directly so a lot of these trade offs never get to the customer.

> achieve their goals so you can keep the software architecture halfways clean

That sounds... like a bad decision. We create compromised software solutions to support the business, we don't compromise the business to support the software (unless it involves the safety of others).

You have to have a balance or you will reach a point where the software is so compromised it can’t support the business.

I've rarely seen that happen, but I have seen the inverse (over-engineering) hurt businesses considerably more. I'll stick with the devil I know.

I’ve never seen engineering teams good enough to withstand conflicting requirements between old and new features. I don’t know what the solutions are, but I’m suspecting the thinking on solving this these days is planning a year or two ahead, publishing the deprecation schedule of old features.

For a balance of practicality and loyalty, I still like the old-fashioned way of doing things. You release version 1, 2, 3, ... of your product. Old versions are supported for a relevant period of time and get essential updates for security and the like, but each major version is its own offering with its own set of functionality, which potentially includes new features, breaking changes, or even removing something.

Users can then move to a new version if and when they want to. Ideally you have a system that migrates their data automatically, including converting to the new way of doing things as needed and warning if there is anything lossy in that process. However, if the user is happy with their old version, they can keep using it without unwanted changes.

Meanwhile, you minimise development costs for ongoing support of older versions. In general, there is no obligation or expectation to backport new functionality. You just release security and compatibility updates as appropriate. You probably also update your migration system regularly, to track whatever you're doing in your newer versions and keep the upgrade path open.

I don't see any inherent reason that the same approach can't be employed even if you're doing the whole cloud-hosted SaaS thing. You just keep the lights on for your existing customers, but direct new prospects to your latest and greatest. IIRC, Basecamp is one business that does something a lot like this.

Basecamp doesn't have terabytes of data that would need to be available and consistent for every user on every version of the platform.

Perhaps, but then a lot of other software doesn't either. For software that does, obviously a strategy of maintaining multiple versions with potentially conflicting data models isn't going to work.

It's kind of a fractalized representation of a dynamic that happens to businesses at every scale: they get good at one thing, so now the organization pushes back against changing that thing when conditions change. The business coasts along for some indefinite period, still profitable because of momentum, and then collapses when its market advantage has sufficiently eroded.

The success stories generally come with a combination of top-down strong leadership and bottom-up skunkworks teams and units that are given the leniency to take a chance on something new. Sometimes acquisitions take on this role(e.g. Instagram as Facebook's replacement product).

If we take the old Microsoftism of "It only gets good at version 3" and extend it with, say, "it starts getting worse after version 7", then every software product should have its prospective replacement start shipping alongside version 4.

Actually doing this takes attention to detail and finding an unaddressed niche that would support a different product, though. Compromising and letting too much be reused or too many old requirements pour into the new thing usually causes the effort to fail. It has to be really different, like the IBM team in Boca Raton that came up with the PC design by dispensing with the normal IBM checklist of the time and cludging together some commodity parts and third-party software instead. Most such ideas get squashed by political machinery when put into the context of existing products and teams, which is why the skunkworks approach has to be fastidious.

There’s a book about this called “Sacred cows make the best burgers”. I haven’t read it, but it was recommended to me by a colleague after I was complaining to him about having to support a legacy system because of a few “important” clients.

Where possible, I've found it effective to keep system components small and reusuable (each component should have one purpose and do that thing very well) instead of building monolothic objects. Complexity of system components increases exponentially with size. Keeping components small increases the resilience of the system. Also, from an OO perspective, shoehorning components into a strict hierarchy can lead to unnecessary coupling and rework. In practice, it may be better to fork a small component. YMMV

Reply on news.ycombinator.com