I find it helpful to use a range of descriptors. A "simple" task is easy and can be done quickly. A "straightforward" task is easy but may be larger in scope. A "tricky" task needs study to determine where it falls. A "hard" task has known complexity and is just plain hard.
I agree with this. I also like to divide things into "this requires research/invention" and "this does not require research/invention, just work".
Anything requiring invention by definition is not straightforward because its potential timeline may be functionally infinite if it cannot be solved with the tools at hand.
A task like changing all APIs to accept a different set of parameters might take 6 months, but is straightforward.
"Easy" is the one line change that has no side effects, and is uncommon in practice. After all, sometimes it is that one line change, but there are ramifications elsewhere in the system that need to be thought through.
I really like your use of "straightforward" here. Not a word I would have thought to use, but does a great job describing the nuance of something that's well-understood, but may not be quick to do.
