[HN Gopher] The unexpected complications of minor features (2020)
___________________________________________________________________
The unexpected complications of minor features (2020)
Author : AshleysBrain
Score : 64 points
Date : 2021-07-04 11:29 UTC (11 hours ago)
(HTM) web link (www.construct.net)
(TXT) w3m dump (www.construct.net)
| ChrisMarshallNY wrote:
| 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.
| castratikron wrote:
| 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?)
| ChrisMarshallNY wrote:
| I work in Swift (mostly). I think some tools are starting to
| coalesce (LLVM helps).
| tlogan wrote:
| 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.
| aliswe wrote:
| Awesome, I love hearing you're alive and kicking with Construct.
| I'm bornemix from the old days.
| as1mov wrote:
| 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.
| kqr wrote:
| I think this is a case where watchmakers have superior
| terminology. They use a different, more honest name for
| "features". They call them "complications."
| [deleted]
| rickspencer3 wrote:
| 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.
| recursivedoubts wrote:
| 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.
| enriquto wrote:
| > 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.
| npd wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-04 23:01 UTC)