The unexpected complications of minor features (2020) | Hacker News Reader

The unexpected complications of minor features (2020)

construct.net

68 pointsAshleysBrain11 comments

Tell me about it, but this is nothing new. I am constantly being asked to make "just a little" change. In most cases, the cost is easy to see, but every now and then, I get a sneaky one, like the first example.

This is the biggest issue that I encounter:

> We run in to a complicated bug associated with what we're trying to do - so then we have to deal with the bug to get it done

Very often the "little tweak" executes a line of code that has always had a bug (AKA "Tech Debt"), but was never found, as there was no code path.

That's why code coverage tools are important (but they tend to be hard to find).

A lot of what I write are reusable tools, SDKs and APIs. I tend to write a lot of code paths that will only be of interest to certain clients. It's incumbent upon me to test them all, but I often miss one or two.

I'm embarrassed to admit that I didn't know about code coverage tools until about Year 10 of my career, mostly embedded C and C++ where things seem to move slowly with regards to adapting modern best practices.

There is actually code coverage support built into GCC, called gcov. It works really well for C and C++ projects (and theoretically any language with a GCC frontend?)

I work in Swift (mostly). I think some tools are starting to coalesce (LLVM helps).

I think this is a case where watchmakers have superior terminology. They use a different, more honest name for "features". They call them "complications."

My (least) favorite example of a complicated minor feature is method overloading. This seems like it's a small feature, it isn't heavily used or discussed, but it had huge implementation implications in the JVM language I used to work on:

- it makes parameter-position based inference harder

- it makes generics harder

- it ends up bleeding into bytecode, since methods can't be uniquely identified by just a name

I would say that 15-20% of the total compiler complexity arose from this one, seemingly minor language feature. All the more unfortunate that there are other, better language features that can handle the problems that method overloading addresses, but we had to be compatible w/ Java.

In this case, it is the interaction of the minor feature with other features that is the killer.

> seemingly minor language feature

This is not at all a "minor" language feature. Allowing different functions with the same name is an obvious atrocity that necessarily leaches to the whole language. For every function call you need to find all instances where its name is defined, not just one. Imagine allowing variables with the same name but different types; the actual variable to be determined according to the context. Wouldn't that make interpreting the language much more difficult? The same thing happens with overloaded functions or methods.

The examples listed sound like the status quo, even when staying lean in your feature set.

The two minor features mentioned simply prompted work that should probably have happened anyway in an active software project.

One feature triggered dependency housekeeping (Cordova upgrade), another a refactor that will save time and bugs in the long run (consolidating m many inconsistent form control types).

The last example, large amounts of effort to maintain backwards compatibility across major versions, is the one instance of a feature itself leading to what could be considered unexpected work. It's no minor feature though, and it's something I personally wish was considered a hard requirement, but it's understandably sacrificed a lot of the time.

Backwards compatibility, when doing major rebuilds, can be the source of some really nasty spikes in work. Every little decision you made in the past is now up for revision, as it comes up against future changes and requirements you didn't even know you needed to account for in your design.

A good peek into software maintenance for the uninitiated, though was hoping for a piece about frivolous features causing combinatorial explosions of complexity based on the title.

For me, often the unaccounted for work is after shipping. Sure, we can ship the new minor feature, but then we have to make sure it is documented, it is one more thing for users to ask about, one more thing for sales to ask about (and ask us to enhance for this one important customer). None of this is programming or development work, but it imposes a drag on the team's productivity.

The worst kind of ‘minor features’ are the one which make your service more confusing and harder to use. Yeah, that can be just one check box - but that check box might cause a lot of confusion.

Awesome, I love hearing you're alive and kicking with Construct. I'm bornemix from the old days.

Same, it's a blast from the past! I used to be an avid user of the first version of Construct which I remember was open source. I think I gradually lost interest after they decided to make the subsequent versions commercial, though perhaps that was the right decision by Ashley/Tom in hindsight.

I've spent an ungodly amount of time on the their forums, writing documentation/tutorials, helping others and generally shooting shit with other members. It has been more than a decade but I still remember some of the users ahaha.

Reply on news.ycombinator.com